Silverbullet-collection: awesome SilverBullet resources like scripts, styles, templates

zef · March 1, 2024, 2:38pm

malys · December 31, 2024, 8:32am

@zef @gorootde
I’m a new user of SB.
Quickly, I want to custom SB integrating plugins, widget…
Many times there are awesome existing stuffs in community.
In SB Plub page, there is a list of plugs but I think a awesome list is something more visible, open, collaborative …
It could be very interesting to split GitHub - gorootde/silverbullet-collection: Collection of awesome silverbullet.md stuff.

To move links list to https://github.com/silverbulletmd/awesome-silverbullet following awesome/awesome.md at main · sindresorhus/awesome · GitHub

What do you think?

zef · January 7, 2025, 7:13pm

I see a few options:

Use Plugs as a respository (every plug gets a page there, and plugs can be added by issuing a PR to the main silverbullet github repo in the website folder). This was my original idea, but I’ve been doing a very poor job keeping that list up to date.
Indeed create an awesome-silverbullet repo as you suggest, I’m ok with this too, but it would be really nice if somebody else would own/maintain this repo.
Use a category on this community site for this purpose: people are already doing this: posting their plugs here, perhaps we can just make that the official way.

Thoughts?

Maarrk · January 7, 2025, 9:40pm

TL;DR: IMO do a mix of all 123

Forum

I think that having a Plugs area on the forum would be a good option for inclusive discussion with all the users, not just the ones who know their way around GitHub. Regarding current situation, I feel that after Showcase renamed toTricks & Techniques it’s not obvious to look for Plugs there. But I agree the new name fits most of the other content there really nicely.

Maybe the new category should even have a specific rule to only have one thread per Plug, so it serves as a mix between an index of active plugs, and persistent chatrooms? Amount of posts and reactions in specific threads could serve as a guide for a new user which ones to look into first based on popularity, instead of a single person’s judgement or just alphabetic sorting.

Repositories

Regarding the repositories - getting the Plug from an index on silverbullet.md in my opinion gives the app a feeling of a nice ecosystem. What I would do to lower the maintenance burden, would be to separate the plug index into a git submodule. This way it can be part of the main site the same way, but I imagine these benefits:

Writing a Plug can (should?) be separate from touching the main application or its documentation, and we can reflect that
Plug authors can have a smaller repo with a README and a list of past PRs very relevant to their work
When a maintainer gets a notification about a new PR, I’d imagine a thought “oh it’s just a new Plug, let me have a look” versus “what kind of deeply hidden demons are they messing with this time, I don’t have time to test this”
I do believe there should be at least a minimal review process, to filter obvious malware, which PRs seem appropriate for. Having a separate repository for content that needs curation would allow to nominate more maintainers, without giving away control over the main application

The idea of a separate repository isn’t even mine, I’ll allow myself to quote @mjf from an issue in my Plug repository:

I therefore think we should raise some discussion to establish another way of distributing the built plugs… Perhaps a separate repository trusted by the SB community, for example github.com/silverbulletmd/plugs-repo, where new builds of plugs could be pushed into after Zef’s (or other dedicated maintainer) and the plug author’s acknowledgement of the PR and that could be exposed as repo.silverbullet.md/plugs or something like that?

While we disagree a bit on the details of distribution, this is another voice for a separate repository with plugs, and a nice structured way of browsing them.

Why care about index on silverbullet.md so much?

As of Plug Manager rework (PR #1122) currently only on Edge, we can have an install button on the page. But for it to work, people must visit the Plug page on silverbullet.md through Federation from their own space. This is a very specific example why I wouldn’t give up the index on the main instance too easily, but I understand that in the current state it’s additional load on @zef (and personally I don’t mind that more ambitious tasks have had priority if I may comment on that).

```template
{[Plugs: Add|Install now!]("{{uri}}")}
```

It pre-fills the input box of Plugs: Add you’d otherwise paste the URI into, so there’s still a confirmation and communication of what’s going on. I’d say it’s a solid user experience, almost like a low-cost app store

zef · January 8, 2025, 7:24pm

Hah that’s cool. Alright, for now I’ve created a dedicated Plugs category here to at least have an open and easily accessible place for people to post their stuff without needing to fork repositories, and for me to test them because I also kinda feel that if I include them on the silverbullet.md website I need to properly QA them to some degree.

malys · January 10, 2025, 8:43am

I think that we have moreless the same idea.

Technically I will imagine somethings like that:

Silverbullet Registry (SBR)

Create a specific directory github.com/silverbulletmd/plugs-repo
To my mind, I should be only a collection of github repositories links.
The plug developer has to stay owner. Every evolution of plug must be easy for him (contribution must be easy).
On the other side, SBR maintainers (3 people) develops toolings, no daily works.

Plug repository

For stability/security, Force plug owner to release a version to be allow to add his plugs to SBR.
It could be possible to install an unstable plugs from sources but not to add it to SBR.
It’s necessary also to provide a template of project (adding to command line silverbullet plug create => create a git repo from official template

Pull Request to SBR (githactions)

Create a PR template to add a plug like that:

…

{
"name": "awesome plug",
"category": "visualization",
"description":" create awesome stuff",
"repository":"https://github....."
}

On automatic PR validation:

PR

Extract and validate data (check syntax, format…)

plug analysis

static security on fail => create a PR to Plug repository
last version + date of build
checksum

Indexing, create index.json

[
{
“name”: “awesome plug”,
“category”: “visualization”,
“description”:" create awesome stuff",
“repository”:“https://github…”,
“last_check”:“154156465465”,
“checksum”:“fghfhlmkmsdfz:sfùlspdf”,
“version”:“1.0.0”,
“state”:“running|outdated”
}
]

Readme.md generation

Silverbullet registry

Visualization

awesome plug: create awesome stuff [Badge InstallMe if secu OK] [Security status] [Version] [last update date]

Forum

Create a dedicated page in https://community.silverbullet.md/ with tags …

Daily rebuild

full plug analysis

if checksum !=, static security on fail create a PR to Plug repository
last version
checksum

Create a PR template to declare an outdated plug

change state of plug (plug is not compatible with SB anymore)

Silverbullet

Support [InstallMe] link (badge for plug repo)
Autocompletion , Compo … to install plug from SBR (use index.json)

Conclusion

SBR user experience
No pain to maintain SBR (no git submodule, few maintenance)
Plug Owners are free to manage their repo
https://community.silverbullet.md/ to chat

Maarrk · January 10, 2025, 6:44pm

Sorry but I strongly disagree. Apart from “make a separate repository” I don’t see similarities. This looks like a lot of work, and I don’t see where’s the benefit.

Who will be those 3 people? How is this less work? The current solution already needs zero maintenance other that adding things to the list, and it is already not keeping up.

Among the plugs listed on Plugs there is only one that installs from GitHub Releases. It is Grep and I chose to always point to the latest version. I think what we see put there is not aligned with your idea of forcing stricter versioning.

But what is the SBR experience exactly for user? I didn’t find how it would change. The fact that everything has cool GitHub templates actions, PRs and badges doesn’t affect the actual end users
Why is git submodule a pain? I’d maybe understand if it were one extra command required to build the code, but even that doesn’t apply here. What do you mean by few maintenance if your post defined multiple new things for maintainers to do?
But you’re defining additional constraints, how is that relevant to the rest of the post?

Feel free to prove me wrong by implementing an example

malys · January 10, 2025, 7:40pm

it’s not a question who is wrong or right…

Currently, it’s not easy to find plugs and Plugs page is not representative of real state (see quick github. Moreover, it’s a manual process.

The goal of this conversation is to propose a collaborative solution to make easier the use, the integration and the visibility of community plugs.
If @zef and other contributors like you and I find a collaborative proposal. It could be interesting to work together to implement it.
I’m not interesting to convince you and I will not develop the solution alone but I can help, contribute and work punctually with other nice, motivated guys to improve SB

We share the same conclusion about the necessity to “make a separate repository” and improve plugs visibility.
I share an ambicious full automatic proposal with some tasks at the beginning

@zef can’t manage everything.
Creating a new repository, it’s very important to have not only one maintainer. 9 tasks for 3 people it’s only 3 tasks a person …
Currently, the plug list is not updated because it’s a manual process. I try to propose a solution to not depend to the availabilty of a person
3 people = 3 volunteers (contributors)

Only one but he’s right (good practice, common process, stability, security …) The easy is not always the best.
I try to improve software quality.

UX will be improved:

interactive list in SB of plugs to install because SBR
list of trusted and more stable plugs
public collection of plugs in github with security check, description, date of last update
easy way to create plugs with the integration an official template in CLI
…
It seems a big gap for end users and contributors

Good practice: source owners build its plugs
The important it’s to deliver a stable and trustable package.
Maintainers should create an initial issue (PR is not useful) to SBR. Official template will propose to github actions to release automatically.
Not big constraints for maintainers. He has to apply best practice.

I share an overall vision with different iterations to exchange ideas.

If the community and @zef prefer to manage manually plugs list, you could be volunteer to apply your proposal.

I’m aware and opened to help.

PD: See example