Outline for how (and why) to make people use this.

Why should we want people to use this plugin? Because:

the plugin opens the gates to a huge, unexplored, territory and we want more people to join in and create cool stuff for us all
it is a big selling point for TW itself and has the potential to attract more people to TW, which is always beneficial

In my view, there are two "keys" to make people use this:

A "killer application" for the plugin
Make the plugin ubiquitous because we can't "market" it and it will not be "advertised" by official channels

For our plugin, I believe there's an obvious killer app and where the ubiquitousness follows incidentally: Everyone has needed a community plugin library forever. TiddlyGoo - even just the SheetsIN part - can easily be modified into a (some kind of) plugin library. And this would incidentally make it ubiquitous because it is one of those things that makes sense to install right away even if you don't need it now because they know they will need plugins eventually.

If these arguments seem reasonable, the question is just what exactly a plugin library would mean in this case. I propose that we discuss this here @Marxsal

For the spreadsheets themselves I believe these limitations, out of all, are the only ones we need to keep in mind:

max 200 sheet-tabs per spreadsheet
max 50 000 chars per cell

TiddlyGoo - even just the SheetsIN part - can easily be modified into a (some kind of) plugin library.

Do we just do it, or ask permission from dozens of authors? Which would take a lot of time. I'm thinking the read-me of each plugin should have a disclaimer at the top -- "This is an adaptation of original code available at http.... and may not reflect the current state or best practices of that plugin."

The idea of a library that lags behind the original is the basis for the distributions that are used every day in Linux. When you run Linux, you typically have a distribution catalog from whence you can, in mere minutes, download hundreds of software products like git, LibreOffice, Firefox, Chromium. The versions of software are often months or years behind the actual product, but people accept that since the alternative would be to search the web, download the software, verify the certificates, install the software, etc.

Still more rambling. There is precedent. When you install Stroll , for instance, you also typically drag and drop nearly a half dozen plugins written by other authors that have been modified to have a shared tag. AFAIK, no one has complained that their plugin is being distributed from someone else's source. Yet it is. There is no guarantee that you're getting the most recent plugin.

max 200 sheet-tabs per spreadsheet

max 50 000 chars per cell

I'm not sure why we should worry about the 200 sheet-tabs limit. Oh wait, are you thinking of putting each plugin on it's own sheet? I see where that would work with the current TG display interface. Might work since there are probably fewer than 200 finished plugins available.

My original thought was that there would be one sheet perhaps called something creative like "plugins" and then each column in the sheet would represent one field in the plugin tiddler. The body would be in the text field, but we would need to work out where the overflow body would be (e.g. text-1, text2). In terms of work-flow, it would be handy if the csvtiddlers Macro could be used. Haven't tried that to see if it breaks with plugins. That would make it possible to semi-automate the process, possibly including splitting the text body.

Hmm, I guess with that scheme we would need a new way to list tiddlers in advance which could problematic. Among other things, even to list tiddlers (rows) takes the same amount of internet overhead as to import all the rows. So maybe one-plugin per sheet is the way to go.

The other issue of security. It's possible to share a google sheet as read-only, right? That would be the most easiest fix. Allowing anyone in the world to mess with the master sheet would lead to problems eventually. Doing the thing where you check for hash numbers would require periodically updating the TG plugin with new hash numbers. The point of all such security is that you have two sites. One contains a listing of products and hash numbers (TG). The other contains the product (the sheet). The idea is that a hacker would have to hack TWO sites under different control in order to alter a product.

TiddlyGoo - even just the SheetsIN part - can easily be modified into a (some kind of) plugin library.

[assembling plugins] would take a lot of time. [...] The idea of a library that lags behind the original is the basis for the distributions that are used every day in Linux. [...] often months or years behind the actual product,

That Linux approach is both interesting and (very) surprising to learn about. My own thoughts was that we should (absolutely) avoid an approach that depends on continued moderation. Maybe it works for a behemoth like Linux but for TW it would basically rely on "you and me" to do this continuously. And as you point out, some plugins depend on other plugins so it would cause problems when one is updated but not the other.

Instead I think we should go with a quasi library approach that provides links to where the respective plugins are hosted. I envision a system where the benefit is not that you "get" the plugin right away but instead where you get the link to it and valuable meta data. How about this idea:

A kind of app store that presents the apps (let's refer to them as apps because it is not necessarily only plugins) with community comments and perhaps ratings. The apps are also searchable in a superior way. We can present things in a much prettier UI than the current plugin libraries. More like the common app stores elsewhere, but with links.

It would use a/several built in google forms for users to provide links to new (or old) plugins. Anyone can do this or people that we give editing rights to. And another google form to give user comments about the plugin. Perhaps also a google form for rating plugins. In case the spreadsheet owner abandons the project (run over by truck or joins the NeverTiddlerBrigades) the sheets are easily copied and the connections in the SheetsIN plugin just redirected to some new location.

I'm not sure why we should worry about the 200 sheet-tabs limit. Oh wait, are you thinking of putting each plugin on it's own sheet? I see where that would work with the current TG display interface. Might work since there are probably fewer than 200 finished plugins available.

That's an interesting idea I had not considered. But I think there are well over 200 plugins (ref Dave Giffords list). Plus, as noted, I don't see why we should limit it to plugins specifically.

I was more (vaguely) thinking that maybe sheets could be useful for categorizations. I don't know how we can fine tune SheetsIN - I'm referring to that it currently imports everything from a specific sheet. From a pragmatic point, I guess the user will want to see "all that has to do with math" or "everything from Marxsal", so there could be a sheet for each such category (in this case it might mean two spreadsheets - one for "subjects" and one for "creators" - where sheets in these respective spreadsheets, are categorized into specific subjects and specific creators.) For this, I think 200 is a pretty good number: 200 "types" of apps and 200 "creators" and maybe other comparable segmentations.

...

As you bring up, there are some practical difficulties with providing the actual plugins (the splitting of the plugin text fields, security, ...) beyond the problem in actually assembling the plugins to begin with. And it is likely that some would not want anyone else to serve their plugins.

Assembling mere links can be done very gradually and I really think that people will provide new links if it is simple enough (which, for one, means they have this plugin with a pretty UI directly in their wiki!)

Whaddyasay?

A kind of app store that presents the apps (let's refer to them as apps because it is not necessarily only plugins) with community comments and perhaps ratings. The apps are also searchable in a superior way. We can present things in a much prettier UI than the current plugin libraries. More like the common app stores elsewhere, but with links.

I think you're going to have to come up with a prototype or something. I'm not seeing the benefit over TiddlyWiki Toolmap at the moment. I thought the idea was to provide the plugins themselves, somewhat like the official plugin library -- the convenience of being able within seconds to have a plugin installed and running. I think that kind of convenience would bring people in. The problem with navigating to existing URL's is often the author hasn't even posted an explanatory landing page. There may be more than one plugin, and the plugin the user wants might not even be front-most. So the user has a different experience with each site rather than a unified experience which makes it simple to load and get started.

The argument that I know you're going to make (because you've made it before) that Dave is only one guy is incorrect because I volunteer (thus more than 1 guy), and I'm almost never able to post new items before Dave does -- he's really on top of it. Anyone can make a clone of Dave's work, thus dealing with the autobus problem. Searching is a matter of coming up with the right search terms, a problem you'll have with any catalog system.

So ... I'm not sure if a TiddlyWiki listing library is best "killer app". But I'm listening.

Before going into a lengthier reasoning, I have a question:

You know how it is possible to click on a link to e.g a pdf and there is right away a download window that comes up? Well, do you think it would be possible to click on a link to a plugin and have it download?

it would be possible to click on a link to a plugin and have it download?

I don't think it would be possible to click on a link that leads to the plugin section of an existing TW file and have it downloadable. The easiest way to do that would be to have the plugin as a separate JSON file on a server out there.

So ... I'm not sure if a TiddlyWiki listing library is best "killer app". But I'm listening.

OK; I have now started over more than five times to reply to this because it has several angles:

About serving the actual plugins. You imply that you think this is possible and practically doable. If this is the case then, sure, I'm all for it if it does not mean that any individual has to manually curate this all the time. David is doing an incredible job with his list but nobody should have to do that kind of job for whatever-the-service-is to be great. So, do you see any way to more or less automatically assemble the community plugins? If yes, then let's rock...
...or, let's rock, assuming you have the knowledge how to implement such a solution. My own proposals are very limited to my own skills. Obviously it is theoretically possible with anything but since I hope to actully build this, the rough outline I give above is at least realistic from my point of view. It would only require the very tools we have: wikitext+SheetsIN+Forms+Sheets.
Davids list is great. But it is just a static list. It totally lacks the dynamic slice and dicing that TW offers AND it totally lacks the presentation of such things that is basically expected for anything comparable. I'm referring to "app stores" where each item is presented in a much more meningful way than merely as an item in a list. It is worth considering that, currently, the community only has "links" for community plugins (except the handful that have their own plugin libraries) so I think any improvement would be welcome even if it is only a better presentation of those links.

BUT maybe it is possible to make a combo!? Serve some plugins "directly" and some as "links"! IF the user demands only "direct downloads" then, sure, in a "TWappStore" that's trivial to filter on. I (obviously) wouldn't mind if copies of my plugins were stored in such a sheet and served this way but I'm not sure everyone would like this. If users really demand direct downloads then I guess we (i.e the community) will find out and plugin creators will have to adapt if they want their plugins to be used. And we'd do what we can to simplify the process of prividing them to the sheets.

Further, there's no real reason why this should be limited to serving tiddlers. Other examples can be scripts, CSS, JS snips or even articles that are relevant for TW users but sometimes simply not appropritate to copy-paste into tiddlers. (Of course, if the user only wants "TW plugins" then, thanks to TW, it is only a filter away...) So, there are cases where links are the only reasonable option.

OK, I guess this either has to be a direct download of plugins as you want or it's all a no-go: https://groups.google.com/g/tiddlywiki/c/SLpIpsIvg6Q

Anyway, I say we put this particular library idea in the freezer for now.

Marxsal / TiddlyGoo

Outline for how (and why) to make people use this. #2