The links site is the only official community plugin store that we have. Could its listing somehow be presented directly in ones TW?
It links.tiddlywiki does not really store the plugins just links to plugin sources.
- Also remember the plugin library is the main way to publish plugins see my list of libraries here https://plugins.tiddlyhost.com/
A method I have employed previously is iframes to other wikis (must be permitted) from which you can drag tiddlers or links into the wiki the iframe is within.
Right, but showing that list of links would still lead the user to the plugin they need.
links.tw is the only official “plugin list” that we have but my impression is that it is not used (because there is no discussion about it) and the site is overall stagnant. Showing it in the “More plugins” section, it would both draw attention to it and be useful in itself.
I actually tried to provide “constructive criticism” about links.tiddlywiki which although it may technically store what we need it is in my view in need of a substantial rewrite. Over time I have developed many ways to improve tiddlywikis from a design and usability perspective and many of these are not used.
- Unfortunately I triggered a bun fight and undue admonishment.
I spent a lot to time looking at rebuilding the site to demonstrate how much better it could be but was faced with a lot of problems because of the weakness in the original design, and felt I would only be further criticized, if my demo was not perfect. So I abandoned the work.
Regardless of potential for improvements, the links.tw site is evidently considered good enough to be the communitys official plugin store. My proposal here is to make it more accessible and thereby likely more used.
@jeremyruston - this is obviously only up to you. What are your thoughts on this? Again, the idea is not to serve the community-developed plugins themselves.
GitHub - tiddly-gittly/TiddlyWiki-CPL: TiddlyWiki5 Plugin Library for TiddlyWiki Global Communities use same technology as link website, it crawl registered wiki website, and extract tiddler (plugin tiddler).
This technology make CPL (and possibly link website?) fat. Now it gradually takes longer to load.
A mature CMS should load everything lazily, even the list. Like this talk forum, it won’t load “skinny tiddlers” all at once, it only load a batch on scroll, or on search. While this is not solved, links and CPL site are equally not good enough to work as plugin center.
[CPL Plugin Library] use same technology as link website, it crawl registered wiki website, and extract tiddler (plugin tiddler).
Good to know, and that is an impressive website. The problem is the same all the time though: There are only TWO real channels to end users:
- TW itself, i.e the users own wiki
- tiddlywiki.‍com
IMO those are the only common denominators for all users. The links site, even though it is “featured” on tiddlywiki.‍com, is still a bit “away” - it is presented among loads of other info and it requires seveal clicks to actually get to the plugins, which is why I’m proposing the OP. It would bring the information about the different plugins into the users own wiki, and at a time/place where he is actually searching for it!
Now, my impression is that Jeremy wants it to be a bit difficult to access community created plugins for security reasons, hence not serving the plugins that directly (right, @jeremyruston ?) But, obviously, the community needs access to community plugins, hence the links site was created. Again, though, my impression is that people are barely aware of it, hence the OP here.
Regarding slow loading, the “More plugins” section could probably load a static version of links.tiddlywiki
I think that, before debating a solution… we should be clear on the requirements for a plugin library that would be the best solution. Note that since this is not in scope for the next major release (i.e v5.4)- there is time to really consider and address what is needed… Here are some thoughts to get there:
As a end user i want to be able to:
- Search (!) all the available plugins as one library
- Access reviews or ratings on the plugin from other users to know its good
- Know which plugins have been “vetted” for security or are experimental etc
- Do so from my TW instance via an improved plugin dialog
As a developer of a plugin I want to be able to:
5. Publish my plugin to the community through a reasonably easy and well documented process
6. Have options for the plugin to be installed via browser or for node.js (any other platforms ?)
7. Optionally have my plugin “vetted” by other developers
8. Have any tools needed that assist in developing and publishing a plugin - available in TW (eg. like kookma’s Gatha Studio plugin)
9. Those tools should include version control of the source tiddlers
What do others think ? any other must have requirements ?
Cheers
CB
2 Likes
I think we need to resolove the idea that Plugin libraries point to the source owned by the plugin author;
- This is nessasary for ensuring currency or version control so features and bug features are automaticaly discovered.
- However we need to be carful as this may permit a bad actor to introduse malware via a “supply chain” hack.
- It seems the idea of vetted plugins thus makes sense but I think this should be implemented through the library mechanisium eg Get new plugins, and will need an online file repository, and maintenence.
Thanks @TW_Tones - I’ve added the need for version control of the source tiddlers as a requirement in my post.
Regarding “bad actors” & malware - I think that is possible today to some extent through startup libraries or such. However the impact of any rogue code would be limited to the data within the wiki (as browsers lock down access to much else) and the #1 rule of TW applies (backup regularly) … but a whitelisting vetting process or blacklisting removal from a library is possibly key
Right.
Regarding your OP. I think it a good idea.
Not least because doing that will immediately highlight TW’s interesting balancing act between …
-
I Did It plugins (enthusiast gives away their precious innovation, unvetted and without long-term guarantees) = the exciting variable majority;
-
Central plugins in a controlled repository (fully vetted compatibility guaranteed) = the excellence minority
Also, for your aim, achieving the OP would …
- … likely clarify ways the (excellent, though ageing, Links) might be better structured.
Just thoughts, TT.
cc: @Mark_S
When you load up the links page, you have the entire collection of links. So anyone who was interested would hypothetically have all the tools they needed to create a demo. Whether “links” could live alongside “plugins” is probably a political decision.
Keep in mind that not all the links lead to plugins. Some links lead to discussions or reference material. Even some links marked as “plugin” lead to entire TW files because addressing by tiddler wasn’t available in the early TiddlyWiki days.
The term “plugins” is used in conjunction with many different products, and people bring their expectations from those other products to TiddlyWiki. Many of those plugins in other are brittle, easily breaking depending on product version or platform. My experience is that has not been the case for the vast majority of TiddlyWiki plugins. So vetting isn’t as essential in TW as it is with other products.
Vetting would be extremely hard. Even just link-checking was hard (because broken links usually take you to a working page – just not the page you actually want). And now that we are on the cusp of changes to TiddlyWiki that might break backwards compatibility, it might not be the most auspicious time to do that kind of work.
You can immediately see that vetting might require vetting by TiddlyWiki version. Ouch.
Also there’s the possibility that two plugins might conflict. It’s pretty rare, but it could happen. Yet each would be fine on its own.
Popularity could be a proxy for vetting. The original idea behind the links project was based on del.licio.us . In that model, people could submit their favourite links, thus creating a kind of vetting by popularity. This hasn’t worked out this way for the links, mostly because there’s no easy one-click way to add links. So instead we have plugin authors who have submitted their own products, and we have historical links.
If more people participated, then that approach might work.
Things like ratings for plugins are hard because it requires a dynamic interface, which in these times means a complicated, secure login and authorisation process.
Maybe we could have a poll of “favourite plugins” in this forum, and then the results of that ongoing process could be periodically applied to links.