I’m new to SilverBullet, and I really like it so far.
I also like Peergos, and am gradually migrating over from Google Drive.
Is there a supported API (maybe via some sort of Plug or Library or something?) to customize how the client syncs files? I think it would be very powerful if, instead of using the Deno server, I could run SilverBullet client as a Peergos custom app. It would be great if I could just build some storage adapter to wire it up to Peergos file APIs.
I’m very comfortable with TypeScript, but I’d rather not fork SB if I can avoid it. Is this possible? If not, are there future plans for it something like that?
There was an S3 Backend once, I don‘t know where it went tho. Right now the only option afaik would be to fork or write a patch. This would be the backend for writing to disk, it‘s pretty simple honestly.
But those custom apps seem to have no server backend, which also isn‘t really a supported way of running silverbullet. So you‘d have to fork, but just from a quick glance it would probably be „fairly“ simple to adjust silverbullet to be a custom app, if you know what you are doing.
Correct. It seems that I would need to modify the SB client to use Peergos APIs instead of the Deno server.
I found this HTTP API doc. Is this the only way the SB client communicates with the server? If so, then maybe I use a service worker to intercept fetches and use the Peergos APIs.
Edit: Looks like the SB client already has a service worker, and it already intercepts fetch events. Maybe I could make some modifications in there.
… I think so mostly, @zef would have to clear that up I haven’t been to up to date with the api since v2. Although the document does seem to not be a 100% correct (granted for the LLM, the API is very weird in some regards), because GET some_page.md sends me the UI not the raw file (at least with a default request).
Which leads me to another question for @zef, now that federation is gone, could we move the endpoint for raw files to something custom now, like GET /.file/*? This would clear up some messy code on the server side.
Plus there are some endpoints for auth or shell interaction that aren’t mentioned in the document (and one or two more haven’t completely looked at both). I guess you could just completely cut the auth part without any repercussions, if you don’t need that and shell stuff isn’t going to be very useful either.
All in all I think that’s mostly it. You could obviously make the modifications in the existing service worker, although you’d still have to deal with the API as the client sends out requests using it.
Architecturally SilverBullet is ready to support multiple storage backends. At some point there were multiple, but in my v2 cleanup I removed all of them because they were not (or rarely) used.
I cannot really judge what would be involved in supporting something like Peergos. However, every time somebody tried to embed SB or put some sort of layer on top or underneath it, it complexity explodes in cases to support. A lot of the weirdness around redirects that @MrMugame mention come from an attempt to support auth proxies for instance. I’m not super happy with this complexity, also because I often have to make blind changes there hoping that I don’t break anything (and I often do).
SilverBullet is primarily developed by just me (although I do get more help now, which is much appreciated), and it’s a hobby project. Maintaining, testing a lot of permutations of setups (proxies, backends) is a ginormous time sink, so I’d really like to keep things as simple as possible.
Maybe working on more storage backends becomes a priority again in the future (and it’s easier now than in the past) but I don’t have much personal interest in spending time on this topic now.
That completely makes sense, and it’s actually part of why I like SilverBullet; It has this lightweight, minimalist feel while also being quite powerful.
By the way, this is impressive for a hobby project! Thanks for sharing it with the world.
I suppose it would help if I can learn more about what exactly the Deno server does. Does it only store the files, or is there more to it [1]? Maybe I can find more time over the weekend to better familiarize myself with it. If I can understand the Deno server well enough to mock it, then I might be able to pull this off.
Is there a test that runs the Deno server and tests all API calls that the client uses? And if not, would you be interested in having such tests? I tend to enjoy working with TypeScript and Deno, so this might be a nice weekend project, if time permits
Edit: I realized after posting this that it also does auth and runs shell scripts… So there’s a good chance that I’m missing a lot of other details as well ↩︎
The Deno server is rather thin now, it mostly serves files and persists them (and does auth indeed). This was different in the past. Most logic is purely living in the client right now.
And yes, a test suite for the HTTP layer would be nice to have!
