In sync mode everything lives on the client, this means plugs, files and the database used for queries and such. In online mode plugs, files and the database live on the server. This adds complexity to the server as it has to be able to generate and update the database, run plugs and handle the plug calls from client. The advantage of having everything on the client is, that it still works offline. The server is only used to sync and store the files securely. Disadvantage is that once you load the page for the first time in sync mode, silverbullet has to fetch all files in your space and regenerate the database from the files, this is obviously pretty slow for big spaces.
1 Like
Then sync mode is for me. 
First of all, thank you all for your support. I’m extremely happy that you’re taking this in such a positive way. I couldn’t help myself, so I’ve already started the “rambo work” on a branch: [WIP] SilverBullet v2.0 by zefhemel · Pull Request #1302 · silverbulletmd/silverbullet · GitHub
Not there yet (that would be fast), but it’s a very rough first cut. It’s deleting almost 10k lines of code 
On the topic of online and sync mode: as @MrMugame points out, supporting these two modes adds a lot of complexity. I’m rather surprised it’s worked as well as it had this far.
On my v2 branch I’ve removed online mode altogether. However, I’m considering adding back a type of online lite™ mode later.
This online lite™ mode would serve two use cases:
- It would be enabled during your initial sync. I don’t want people to have to wait for a full space sync to complete before being able to browse and edit their pages.
- The occasional “I need to quickly check/edit something on a foreign device” scenario.
In this “online lite” mode all Lua-enhanced functionality would be disabled (Lua expressions, custom commands, slash commands, configuration, space style). Basically you’d end up with a basic markdown editor where you can navigate links, and use the page picker to switch between pages.
10 Likes
I am very glad to this announcement and I think it would be easier for new contributors to navigate to a lightweight codebase.
1 Like
Hmmm… If you rip online mode, will this affect the possibility to start commands on the server, like with shell.run?
I hope not, as i plan to use that a lot, e.g. for coverting md files to presentation with marp or export with pandoc.
No that will stay.
1 Like
Ok @FuriouZz in the chat asked how they could help. I think for a little while I’m good on the development front. I need a little bit of time to clean up the code on a branch, then I’ll merge everything into main. I also want to take a whack at the docs myself, because I want to use this as an opportunity to “reposition” SilverBullet as a slightly different thing than the “hacker’s notebook.”
However, what you can already do today — and what would be very helpful — is to prepare yourself
You can already start to migrate your existing “legacy” queries to space lua based queries, get rid of templates and use the ${} syntax everywhere. Share the things you run into and aren’t working yet, and even share some of your findings, tips & tricks on the Lua forums here.
If you’re especially brave, I have already started pushing builds to GHCR under the v2 tag. This is the equivalent of edge builds, so you get a fresh version on every commit to that branch:
docker pull ghcr.io/silverbulletmd/silverbullet:v2
Before doing trying this:
- Backup your space (as usual)
- Remove all your plugs (they will likely break until they’re updated), so delete everything under
_plug/ - Remove the Core library, so everything under
Library/Core/— most of this is in process of being reimplemented in Lua on this branch.
Be prepared for a bunch of stuff (specifically all your settings) simply being ignored (because one part I ripped out is space config).
For the record, I’ve already switched to this v2 build for my personal space. Because I’m brave. And I need to better understand what’s broken and what’s still missing.
1 Like
Exciting stuff!
- Would you consider having a hotlist of dependent issues blocking the release, and having Having second client open in sync mode causes conflicts · Issue #1136 · silverbulletmd/silverbullet · GitHub on it?
- Any hope of making the initial sync any faster? My space is 100MB (but more importantly, 1232 items), and initial sync on localhost takes 59 seconds (for comparison,
cp -a-ing ortar | md5sum-ing the space takes less than 100ms on this system, andscp-ing it to a nearby machine takes 3 seconds).
For both yes.
More focus on making sync mode more bullet proof will become a bigger priority. I’ll add this issue on my list of things to look at.
Sync speed: yes I think this can be optimized (for instance by parallelizing downloads).
JavaScript not being fun for me has been a reason for me writing so little space scripts, so I’m all for Lua 
1 Like
<sees v2 tag, downloads v2 tag> Well guess this is my life now
2 Likes
What would that be? Just curious
I like Lua in general and am happy with the changes, especially if it means saving you time and effort.
Not sure if this has been mentioned, and just a thought: there should be a time buffer between the productive Space-Lua release and the V2 release. This would allow people to work with Space-Lua, create guides and use-cases, update the docs and so on. Every major release brings in new people and it could be confusing if the forum and docs talk and show Space-Script etc tech when it is no longer available with the new release.
I hope this makes sense.
Also, it might make sense to mark Space-Scripts etc as deprecated already in the next release and point to the alternative + a guide.
And regarding docs, I am not sure if you want to continue using SB as the main platform for docs. Using something else might help with collaboration (to share the work) and make it easier for things like translations.
Thank you Zef.
Cheers.
2 Likes
I just wanted to chime in that I consider a project being able to be sustainable developed is a key feature for wanting to invest in it. If slimming down things is the way to do it, I fully support that change. Thanks for doing the work so far, I look forward to using SilverBullet for years to come!
7 Likes
Looks like I missed some excitement, but just wanted to throw in my support as well! You shouldn’t have to worry about making everyone happy. The primary user is you. A lot of people happen to also think similar to you and want similar things in a tool like this.
I’m behind on the lua side of things, but generally like what I’ve seen and used so far. I’m hoping I can maybe eventually replace my silverbullet-ai plug with a set of lua scripts too.
Once you get the code to a state you’re happy with others mucking around in, I’m sure there are several of us who’d be happy to help tackle some of it.
3 Likes
I just pushed a v2 site live, while work is progressing. It’s very much a WIP, but a few pages (including installation instructions) have already been updated. And obviously, the site itself runs on v2 itself.
7 Likes
I’m also for 2.0 . Cleaning up mess is the best way to keep your work enjoyable, and we want you to keep working on this 
Throwing an idea out there: I would really love if the v2 exposed a web standard fetch handler (a function that takes a Request and return a Response).
It is now a proven api that has been adopted by a lot of tools (cloudflare workers, netlify functions, val.town…).
I would love to be able to host silverbullet from my own project: https://www.smallweb.run/
Lol, wtf, I remember you from this issue. (Silverbullet would also benefit from this features)
How would you expect the api to work? Just a package you can add import which exposes it? It would be fairly simple to create a patch/fork for this. This file is the entry of the server, running the serve command, so starting the server calls this file, which uses the class HttpServer, which uses hono under the hood to run the server. You would have to export that hono api and somehow bundle it, which I guess is the hard part here, because silverbullet currently doesn’t export any package (except for some type stuff for plugs), it only builds the cli tool, so this would mean a a bigger change/addition to the build system, which I’m unsure is defendable for such a niche use case.
The pattern I use for smallweb apps is:
// npm packages can contains static assets
import { Silverbullet } from "npm:silverbullet"
const silverbullet = new Silverbullet({
user: "pomdtr",
password: Deno.env.get("PASSWORD"),
// ...
})
// works because silverbullet exposes a fetch method
export default silverbullet
I use this method to distribute vscode as a smallweb app, see the screenshot below (or try it at https://vscode.demo.smallweb.live). It means that once you have smallweb setup, installing vscode on your smallweb instance only requires copy pasting a single file !
I hope that smallweb will someday be big enough for it to be considered as something worth supporting
One more vote for SilverBullet 2.0, rip that band aid!
I have to say though, at least visually, writing templates seems to be a lot more verbose and less elegant than the template blocks of yore. Admittedly I haven’t kept up with the Lua development, but I think that’s going to be the biggest adjustment for me. Still, I think the jump to 2.0 is a good idea and I’m on board.
2 Likes