Towards SilverBullet 1.0

General
1

I think it’s time to start thinking what a 1.0 of SilverBullet should look like. Yes, version numbers are somewhat arbitrary but still.

Let’s collect items here that you feel need to be either added or resolved to provide a stable 1.0.

5 Likes
2
  1. Library update mechanism. Right now the onboarding intro suggests you import the Core library, but then never updates it again. This needs an answer Brainstorm: Library sharing provides some ideas already.
  2. Probably less major, but I feel we need a (non-editable) implementation of page transclusions. FR: Editable Transclusions · Issue #533 · silverbulletmd/silverbullet · GitHub
  3. There are still some design changes I’d like to make to sharing: Plugs/Share

Other nice to haves:

  • Attachment management
    • Rename
    • Delete
    • Management page as part of core library?
  • Settings registration and self documentation
  • Settings access in expression language
3

Starting to collect some of these here:

Not complete yet obviously

4

I’d like to nominate the command “Editor: Toggle editing” because this is fairly small and would make a huge improvement in mobile usability. Probably worth making it visible by on mobile toolbar in default settings. I was trying to take a crack at this, but got lost, but it’s hopefully trivial for someone who knows how CodeMirror is integrated.

I found recently that an error in one space script can prevent all of them from working, probably should be improved as we focus on libraries.

I have ten other ideas (in a SilverBullet note, of course!), but they don’t feel “core” to the app. For all of them I already have a convenient Plug infrastructure to base myself upon, feels like a good time to put down the big 1.0

5

I’ll have a closer look at that. Another potential thing to consider is merge the PLUGS page into SETTINGS. By making the list of plugs to install simply a setting. Not sure about this one yet.

2 Likes
6

I like the current separation between PLUGS and SETTINGS. Keeps the plug list simple, and I’m able to see what I have there at a glance. Downloading and installing a plug can fail more ways, so I think it’s good that we can’t have “you made a typo in the yaml key” mixed together with them.

But I just had an idea that it would allow to “auto-scope” settings really nicely, and avoid name clashes even more:

plugs:
  - uri: github:silverbulletmd/silverbullet-git/git.plug.js
    autoCommitMinutes: 30
    autoSync: true
7

I would like the excalidraw situation to be sorted. The last idea was to replace the code inside a fenced code block with the exalidraw content. After trying to implement this (which is probably possible but super annoying; I couldn’t get it to properly work, long story blabla…). This would also have some problems:

  • Lines are wrapped; If there is like 3kbs of JSON in there it would be wrapped into oblivion
  • Performance issues with codemirror
  • File formats other than excalidraw, which aren’t text based would probably look weird 53696c76657262756c6c6574206973206120677265617420746f6f6c
  • The saving would need to be “live”, because if a fenced code block gets rendered as text again, the iframe is yeeted and has no time to change the text anymore (save). Live saving isn’t really feasible all the time.

Anyways, my idea would be to add the ability to open attachments file, which would be implemented via plugs. So there is some kind of attachment picker and if there is a registered file viewer (from a plug) for the filetype the file is viewed in it. This viewer would be some iframe, which also has some api to talk to the system. This could also e.g. allow us to let the plug index attachments in some way. A good example would be the csv indexing: This could be a plug with a csv viewer, which just renders the table as some html and also has an indexing function (separate from the iframe, running in the webworker) which could index it. This could exists for archive filetrees, image metadata, rtf/doc files, sqlite db file, etc. (Probably insane amount of ideas here). Another viewer plug could be e.g. pdfjs, with some kind of annotation system. Or an stl viewer for our fellow 3d printer owners. This definitely needs some thinking (How is syncing handled, etc.), but I think this could be something insanely powerful.

(At some point in version silverbullet 69, the standard editing mode could just be a builtin markdown viewer plug)

EDIT: A few more thoughts: Indexing could actually be completely separate from viewing (which should really say viewer/editor). So one could have different plugs for each.
Mobile support could be ugly here, as we have to trust the plug devs.
This is also kinda possible already using panels, so a lot of the infrastructure is already in place.
I could see the argument that this is something for a 2.0 release, rather than a 1.0

1 Like
8

If that like is a “go”(?), I would start drafting out that idea more concretely in a PR.

9

I’d be interested in more detail. But it does seem like a bigger topic, perhaps not essential for 1.0.

1 Like
10

Something I think would be a good goal for 1.0 is support for multiple panes/splits or maybe even tabs.

I find myself wanting to open two notes side-by-side pretty often. I don’t usually have much of a need for more than just two notes at a time, but I’m sure others probably do.

Related:

Other ideas:

  1. Read-only mode toggle per page.
  2. Ability to “zoom” into a code block or section and edit that section only, hiding the rest of the note. This would be really useful for spacescript/spacestyle instead of having to edit inside of a code fence.
  3. Note history - The git plug solves most of this already, so maybe it’s a better feature request there - but some sort of UI for browsing and restoring from previous note versions.
1 Like
11

This would be not very easy right now (like Zef already mentioned in the referenced threads) as the editor code is very tightly integrated into the rest of SilverBullet, so running two or more at the same time would be kind of difficult. We would need to separate the editor out, which is kind of what I proposed above or here.

1 Like
12

That would make SilverBullet an excellent outline editor, but I suspect that this kind of feature would be difficult to implement. :frowning:

13

On the topic of a side panel or split view: I see this as a huge potential development tangent.

“Just give us a vertical split for a second page!”

“But I’d like the split to be horizontal!”

“Tabs please!”

“Tab management please”

“Vertical tabs!”

“Tab groups!”

“I have a 30” screen and want three splits"

“I’d like to resize the panels”

“I’d like panels to be swappable with a keyboard shortcut!”

‘I’d like to save different configurations of panels and have them automatically restored, except of mobile screens smaller than 8" on the third day of the week’

My way to get out of this is to delegate this responsibility to the browser. Browser support multiple windows, multiple tabs, and some (like Vivalidi which I’m using right now) even split views.

1 Like
14

I have notes (in my private SilverBullet) on implementing a versioning system. I can see that this is a nice to have (and is implementable as a plug), but is also a potentially huge feature that will likely always be worse than using git. When using git in any meaningful way you’d essentially need to SSH into your server again, but ok. For me in practice I use git with auto commit enabled every 15 minutes that pushes to a private github repo. This gives me piece of mind backup and version wise.

15

I don’t want to be the nay-sayer all the time, but one of the challenges is that I’d really like SilverBullet to remain sustainable as a hobby project with one primary developer by design. The goal is not to remain the main developer myself, but to keep the scope small enough that it could remain a one-person operation, if need be. I think this is healthy.

If this project starts to grow to require a full team, I have to start to look at funding and who knows where things may go when this goes commercial. It may be ok, but we’ve seen plenty of cases where that’s the beginning of the end. It’s not easy to get this right. Look at almost any large scale open source project out there that tried to turn into a business.

Therefore I’m trying to keep the focus tight and give the project a somewhat finite scope. Nothing is ever done, but I do hope to get to a state where the core is stable and rock solid. The way to grow it beyond that would then be plugs, or just to create workflows that also involve other applications outside of SB (which is an option because it’s just files on disk).

Throughout my career I’ve been working on massive feature creeped systems and would like to avoid it to the extent I can with SB.

That’s why I often ask: what features can we delete? People that have been here longer will remember we used to have mobile and desktop apps — removed. Real-time collaboration and multiple accounts — removed. A lot of hardcoded slash commands and templates — removed (in favor of the new templating system). Every time I’m eying a major new thing to add, I’m also looking at something else to get rid of.

13 Likes
16

For a 1.0 release, feature-wise, I’d say you already have everything you need. You might even want to consider removing features which are currently unstable to be honest. I don’t have anything to point out specifically that’s unstable, but 1.0 should be a little “scrappy” imho. Make it stable, but don’t make it everything.

1 Like
17

Just to clarify, my thinking was just to improve the current git functionality by adding some UI/UX around it. Like a command that pops up a filter box with previous revisions of a file and lets you swap between them.

Adding a full-blown versioning system doesn’t seem worth it to me if we already have git that can do it for mostly free.

I can create a GH issue for the git plug though, I don’t think anything would need to be done in the SB core to support it.

1 Like
18

Hopefully you don’t feel like a nay-sayer, having a clear focus on what you want to accomplish is a huge benefit to keeping a project healthy.

I really like @MrMugame’s proposal for custom editors. Maybe I’ll change my recommendation for 1.0 (or maybe beyond) to this:

What can be extracted from SB core into plugs that could later be replaced by different community plugs? E.g. what are plugs not currently able to do or replace? The more plugs can do, the less sb core would need to be responsible for in the long run.

Also how can we improve the experience around plugs in general? There’s the list of plugs, but would a more automated registry be helpful? Or a ‘click to install’ type of button/command?

1 Like
19

An even more radical approach: ditch plugs, and go all-in on space script. Rewrite all plug code as space script libraries. :smile: How do you like them apples?

It’s been a thought, but I don’t think we should do it. SB is great for note taking, but we’d effectively have to turn it into a fully fledged IDE if you are you are going to write significant amounts of code in it and that… would be quite the tangent. One I’m prone to go into, since I worked on multiple in-browser editors/IDEs in the past :laughing:

Anyway, just to make the point I’m willing to burn quite significant parts of the product if there’s better, newer ways. I never saw an idea like space script coming a year or two ago when I started this project, and I still have concerns about security and stability but… it seems like people are really liking it, and this leads to some confusion. What should be built into the core, what should be a plug and what should be a space script?

2 Likes
20

Just a thought on this as an Emacs user. The best part about customizing Emacs is that if you want to build a quick hack, you just write and evaluate some elisp somewhere, but if that thing grows, you just put the same exact thing into a separate file and eventually into a separate repo and publish as a package.

I feel like space-script could do something similar. For small hacks that folks might want to do, space script is awesome, but if/when it gets larger and needs to be maintained more like code, you pull it out to a PLUG which can be “installed” and updated automatically by multiple people.

One of those examples for me personally is Migrating from Obsidian-Tasks - #14 by paletochen - Showcase - SilverBullet Community which I would totally use as a PLUG, but just copy pasting the snippet feels a bit odd.

1 Like