I am wondering if it’s possible to create two instances of SB pointed at the same directory, where one instance supports edits and the other is read-only. This seems like a simple way of hosting a blog.
But I tried this and I keep getting “failed to update read-only database” errors from the read-only SB instance.
It seems that maybe each space directory can only support one SB instance at a time. Is that true?
If so, is the recommended workflow to somehow continuously replicate from one source to the read-only replica?
I think you will have issues because the db is in the root of the space. And you need two different db for two different instances.
One solution would be to have the read-only instance in a sub-directory of your admin instance. I saw someone with a setup like this in the forum.
Other possible solutions would be to use some containers volume mapping to point different db on the host system while using the same path in both containers.
This is currently how im using silverbullet. You can take a look at my blog.
However, i found some issues with the original method of accessing the admin site. You can read the issue i was having here. Essentially, the admin side can’t be password protected. I removed the admin route in nginx and removed the environment user/pass. I then setup cloudflare tunnel access to get to the admin on localhost. I’m in the process of redoing that blog with this current admin solution.
For now, you can check out this video that i used to setup my admin side. This one is good too. There are some other good videos as well that describe the same setup. I set mine up to only allow my email and authentication is through github. It’s worth mentioning that if you are running silverbullet in docker, when you setup cloudflare tunnel, do not do the docker setup for that. Install cloudflare tunnel locally on your host. It will save you hours of pulling your hair out troubleshooting the complexities of docker network routing. I did eventually find a way, but i wouldnt recommend it to others due to it being a very new feature docker has added, and im not too familiar with how well its supported.
I have a somewhat different approach. I have a script that starts SB with 2 functions, ro or rw. For ro mode, I just set the following environment variable:
#!/usr/bin/env bash
cd /path/to/sb_docroot
env SB_READ_ONLY=true /path/to/silverbullet [options] .
The rw function just starts SB without the ‘env’ part.
If it does: Would it be feasible to (in v2) implement the ability to change the mode based on which port (or domain/URL?) is used to access Silverbullet? That way, as an example, Silverbullet could provide public read-only access at mydomain.com, but read-write access at edit.mydomain.com behind either its own authentication layer or one added by the sysadmin.
Edit: Would you prefer I turn this into its own thread?
I just tested running two v2 instances in parallel for the same space: one with read-only access and one with authentication and write access. From the limited testing I did, everything seems to work perfectly. The read-only instance receives live updates as expected.
Yeah, can confirm, seems to work perfectly. Just some UI tweaks could be good, like disabling the apparent ability to rename a file (it fails if you try but yeah). I think it makes sense to move these thoughts to a new thread though so I’m going to start working on that
I would like to actually switch between read-only mode and editable mode live with a command. It would make navigating your notes much easier, especially on mobile. On mobile, each time you tap anywhere, including on links, it pops up the on-screen keyboard, taking up half the screen and making it more difficult to just read through your notes.
If I could just tap an actionButton to toggle read-only mode, it would make it so much easier.
However, I’m not sure how difficult this would be to implement and how tied to a boot the read-only mode is. The alternative would be indeed running two instances and keeping two different PWA’s on my phone, which is not ideal.
Oh wow, sorry. There is actually editor.setUiOption("forcedROMode", true), which I just found out from the Action Button page and this topic. This is perfect and should be there by default!
