Common Community Plugin Library?

I would like to revisit the topic of a common community plugin library. I have found these two discussions:

They have been discontinued a long time ago, without any optimal solution. Please let know or move this post if it should have been posted in one of those threads instead.

Sorry for the long wall of text below. I tried to collect every important thought from the above linked threads for anyone new to the topic. Many thanks to all who participated in those threads and offered helpful ideas/solutions!

What I would like

As a user, especially one new to TW, I would expect all community plugins to be available from the plugins menu in control panel. For example, after opening the “Get more plugins” modal, there would be two tabs, the first one with official plugins, and a second one with community plugins. Or alternatively, have a link somewhere in plugins menu that links to a searchable collection of community plugins.

How to do it

These are just my assumptions, I don’t know the underlying mechanism good enough to say if these are good solutions.

For plugins with existing libraries

Some plugin creators maintain their own plugin libraries. Shouldn’t it be possible to collect URLs of those libraries, pull data from them, and generate one common library? I imagine a similar scenario to how works: collects data from given URLs, restructures them, and presents in an easy-to-use way.

For plugins without existing libraries

Some plugin creators do not maintain their own plugin libraries, but they almost always have a demo wiki with their plugins. These plugins in the demo wiki contained structured data. Would it be possible to construct a library, knowing the URL of the demo and the creator’s username (the one that comes after $:/plugins/)? In this case, anyone, not only the plugin creator, could add the URL/creator to the database, to have these plugins listed in the community library.

Additional thoughts

What is preventing us from having such an integrated community plugin library?

Are there security concerns to such an approach? Would it be less secure than the current model of security through obscurity (you won’t install a malicious plugin if you don’t know it exists)? The step of adding a library or demo wiki to the database would need approval, just as it is with, at least that’s something.

Would the current plugin library mechanism be inefficient for a big library collecting all community plugins? This could be addressed by linking to a searchable catalogue of community plugins (possibly

There were attempts to address this problem, e.g. the thread by @Mohammad linked above or by @TW_Tones attempting to collect existing plugin libraries in one place, and while they are very helpful, I think this is still not quite what we should aim for.

Another discussed partial solution was to somehow include the library link in the plugin itself (so that installing one plugin also adds this creator’s library). That could help in some aspects, but it’s not a complete solution to the problem.

Using was discussed a lot. It’s already great and improves finding plugins a lot. It obviously cannot solve the lack of a library (to track updates and install directly in TW), but at least helps finding the existing ones. I think that it needs more exposure in the context of plugins (on, maybe a link in the plugins menu in TW itself?), because it is the best solution we have right now. Maybe adding plugins to it could be somehow simplified/automated, since the existing libraries and demo pages already contain structured data?


when i was starting out a few years ago, i found the dynlist to be very helpful - although many of the listed plugins don’t work (due to the linked site / file not existing, etc), it was still a great source (and still is).
perhaps the contents of some of the plugin libraries you’ve shared could be compiled into a list like that one? it would have to be maintained but would be a great source for browsing.

1 Like

What do you mean? In what way is links “discontinued”??? There are recently added links to it so I absolutely don’t think it is “discontinued” and - in fact - I’d say this is the exact source you’re looking for, but there ought to be a naitive plugin connecting to it.

Now, two things;

For a plugin to appear there, it does require that people add it. (I’m definitely guilty of not doing so)

Second, the development of links seems to have stalled.

…and while we’re at it; I have a really hard time with the trippy colours on that site, even to the degree that I feel reluctant to go there and be exposed to them. I assumed it was a just temporary for testing stuff when setting it up, but I guess not no… :confused:

i’ll second that is hard to look at and therefore looks somewhat WIP/temporary. i would rather use a less complete source than navigate that site.

Thanks for the suggestion, I’ll check Dynalist out. But that’s part of the problem I’m describing, there is no central place/ gold standard for where to share plugins, every existing one has some quirks, and none is complete.

Maybe I wrote it unclear, I meant merely that the discussion in the linked Talk TW threads has been discontinued without much conclusion. I know that the links are in use, even if less popular than they should be.

This is why I was thinking of a more automated way of adding plugins to links (since the plugins are already structured in a way), so that it would be easier for the creator or anyone else to add it to links, and have it updated automatically.

I second that. I like the functionality of the links very much (except for it being not as plugin-friendly as it hopefully could be), but not the design.

The problem with the library is that you would need to get permission from dozens of plugin authors, some who feel very proprietary about their code, and some who no longer walk among us.

I know it can be done, because the Obisidian project does it. Plugin authors submit their code on branches to the central Obsidian community plugins project. The developers vet the code - ONCE - and then merge it into the community project. I’m not sure of the details, but authors seem to be able to make updates pretty easily.

The links project is basically just a few specialised tiddlers running on a TiddlyWiki platform. It is a case of, as I think Mat once said, “Eating our own dog food.” If someone wants to change the palette, they could post a request on the links github page. You could of course change the palette yourself whenever you use it, if the colors are deterring you. I know I often switch TiddlyWiki dot com to a dark palette when I’m visiting more than a few minutes.

1 Like

Thanks for pointing it out, I haven’t seen it mentioned before. I thought of the plugin libraries as merely a specifically defined collection of links to plugins, I didn’t realize extracting data from them and presenting in another library would be problematic because of this.

Another argument why links seem to be a safe and

I’ll certainly look into improving it, when I find time. I have to admit, I have truly discovered links only recently, after about a year of using TW. I have surely seen it before, but probably didn’t know what to do with it at the time, as I was new to TW, and it seemed overwhelming.
This is why I think it needs more exposure, both on tw dot com (I know its right there in HelloThere, but not so much in context of plugins, palettes, etc.), and perhaps in the core itself.
Editing official docs is getting very easy now with PR maker, so I hope I will be able to help on this point as well.

It’s also at the top of this forum.

The PR Maker is just for TW docs. The links project is a different github repository.

@vilc thanks for bringing this up (again)

I set up to provide all plugin libraries I could find. Please provide any others you know. By message here.

  • libraries permit access from different sites and wikis while retaining a single copy or source of truth.
  • you can presently only search a selected library not all libraries.
  • I appreciate the effort to build links.tiddlywiki but I am quite critical of its usability and presentation. however, I was disappointed at the responce I got when being critical, and backed off.
    • I contemplated building a new links site from the existing site to demonstrate how much better it could be, but found the data structure difficult.
    • I may revisite with the tw features and skills I have developed since then.
  • I have my own collected plugins wiki offline but every time I use it I need to check if updates are needed, now running at 22Mb in a single file wiki.
    • With most plugins licences, I could repubish these plugins but then I would become responcible for updates.
  • Libraries, perhaps with a multi-library, search mechanisum is possibly the best way to go.
    • Unfortunatly the only documentation on generating libraries is how to from the command line. Trying to reverse engineer the process to generate library files to bublish on a website has proven complex, the process and requirements is not documented.

Oh one honorable mention to the CPL resources, however I personaly get very confused with the chinese script and find it too difficult to use. I wish this were not the case, and I could read it.

I would go so far as to say “I love this community” and concider many of you virtual friends, but I think we need to allow polite contructive critisisum where due, and more collaborations, to move forward together.

Hiding from me in plain sight :joy: Well, maybe it’s just me that had ignored all the obvious references for so long.

I know, I had improving TW docs in mind as well. For example the Community tiddler:

was last edited over 2 years ago and it describes the process of moving things from there to links as still not finished. To me, this gives an impression as if links were abandoned or still WIP.

Now this seems like a serious obstacle towards a common plugin library. I guess this is why only some plugin creators have made their libraries.

I was thinking of a process similar to how links are functioning. A process that would get the data from known libraries (just as links collect data from known wikis with links) and reorganize it into a single library. Assuming there are no copyright concerns, of course, but I’m talking about modifying/redistributing references/metadata about plugins, not the plugin code itself (this would be still hosted by the creator).
The undocumented process of creating libraries in the first place might be the biggest problem in this approach.

Edit: Or do I totally misunderstand how plugin libraries are working? I was always thinking they are just a set of plugin metadata, like “I have this Plugin, that does That, the latest version is 1.2.3, you can import it from this URL”. However, if the libraries are an interactive thing, that serves the plugin code on request, then what I proposed above doesn’t make much sense.

I think the underlying problem, which we have to adapt to, as we cannot solve it, is that no one has enough skill, vision, and time (all 3 at once) to make the necessary improvements to bigger things needing some rethinking, like links, or TW landing page. We all agree they need improvements, there are many good ideas floating around and many people with the skill to implement, but it hasn’t moved further yet.

Maybe you could learn about CPL.

Welcome to the ‘’[TiddlyWiki Chinese Community Plugin Source]’’!

This plugin source is maintained by the [[TiddlyWiki Chinese Community]] and is dedicated to collecting all TiddlyWiki5 related plugins on the web, hoping to provide a one-click installation and update plugin experience for TiddlyWiki users in China and around the world.

If you don’t know how to use TiddlyWiki and this source, you are welcome to read the plugins related section in the [[TiddlyWiki Tutorials for Chinese Communities|]]. As mentioned above, both the plugin source and the tutorial are open source projects, you can find them in [[GitHub|]] and participate in contributing! If you like, you can join us through QQ groups and other means, see the Chinese tutorials mentioned above for details.

To add this plugin library to your Wiki, just drag this link with your mouse into your Wiki: <$link to=<>{{!!caption}}</$link>

Note: The source version of this plugin is the ~GitHub Page version, which is faster to update, but may require scientific Internet access. If you are in China and are not sure what GFW is, please use another [[version|$:/config/ChinesePluginLibrary/Netlify]] that is accelerated by, although there is a certain delay in updating, but it is more friendly to domestic users more friendly.

Thats is why I feel we coul;d encorage a little more team work or collaboration. A few people working together.

The site is the first thing I pull up, as a user who knows what I want to add, and just wants to drag over all the library tiddlers in one gesture.

It does seem to me that at least a select set of (up-to-date, active, original-author) libraries ought to be available with any off-the-shelf instance.

If they are included, presumably there should be some caveat (at the Plugins control panel tab, near the “Get More Plugins” button) to the effect that third-party plugins are not part of the core, have generally been tested and updated but are the independent open-source free or donation-ware projects of their developers – or whatever that boilerplate caveat ought to be.

The link is TiddlyWiki toolmap - Dynalist. The project was meant to replace my one-man labor of love toolmap. I know @Mark_S who already replied in this thread put a LOT of work upfront into adding links there, and I see you have been adding a lot recently. Good on you!

I think improving would be the most feasible route.

  1. Distinguish between plugins, tips and solutions, themes, palettes, and webpages with multiple plugins and solutions.
  2. Search results should show full information, without ellipsis cutti…
  3. I will be honest, it is really confusing to click a web url and have it open the tiddler rather than the url. There isn’t even any reason to show the entire url if there is already a button right next to it. I think the idea of it being a “list of links” adversely affected the design of the way the entries are presented. It should be a list of resources - plugins, themes, tips, palettes, etc.

My preferred UI would be:
a. Row 1:
i. Descriptive title, preferably with name of the creator of the site or plugin or theme [e.g., Documenting TW, a list of tips and solutions (Dave Gifford)]
ii. button to go to webpage,
iii. button to view the entry (the tiddler),
iv. button to download.
b. Row 2: a little larger than it is now, a list of the tags.
c. Row 3: At the bottom, in smaller text, Submitted by …
d. Text box below the rows: Any additional information the submitter wants to add.


Maybe you could make a little mock-up?

I was actually working on it right now!

So originally we were told to keep the text down to about 25 words or so. I spent hours honing descriptions to make this possible with my contributions. I think the fear was that the federation process would take too long if the descriptions were too long. However, as it turns out so far, federation is very fast (maybe because there’s not that many contributors). Since the descriptions were (mostly) short, the ellipsis would only occur infrequently.

Then … the policy was reversed. Now there are contributions that are the size of small white papers. So if you don’t use the ellipsis it will be hard to scan through a list of results.