st.ht, look at it, it's glorious. the shortest domain I own, all four letters of it.
So I wanted to build a markdown digital garden website/hosting/service thing, but really I had a domain and I needed to put a service on it. I realised st.ht was kinda like site hut and so I bought it.
I've built my own digital garden a few different ways, but I've not really been satisfied with any of them. I used pandoc and a Makefile at one point and that was probably the best in terms of getting out of my way and letting me focus on writing notes, but I'm an engineering and so I want to do it myself.
A few static generators in go and I have a rough idea of what I want.
I think the main selling point of a digital garden is interconnectedness. Backlinks, tags, dates, people, etc, all entities which can be used to link to each other. What did I do on this date? what else happened on this date? what notes link into this subject, etc.
There are plenty of services that already exist for publishing, Obsidian Publish springs to mind, and so does Quartz.
But I wanted a solution in go, and I wanted to leave the writing side of this alone. There are plenty of tools out there for writing and I like to use neovim and I'm not reinventing that (might do an LSP though...).
The initial idea was to allow a user to upload a folder containing their markdown content and have it available as a subdomain on st.ht-- fairly straightforward.
But to truly over-engineer it I didn't want the app to have any concept of a user.
The idea was to provide each user their own "digital garden" pod, and to have an upstream server handle users, auth, and proxying to the backend garden pod.
This brings in some additional complexity, like needing to garbage collect idle pods, and restarting them when a user reconnects. but in Kubernetes its relatively easy to do. The benefit of this is being able to develop a tool for local use, and building in the tenancy separately.
My initial prototype of this actually worked. The proxy has a database of users, when the user signed up they were assigned an id for their digital garden and when they attempted to reach that digital garden the proxy would check if the pod already existed otherwise created it, and we'd show the user a little spinner before dropping them in.
Caveats:
but if I don't bake this in at the beginning, it will be way more difficult later.
so lets picture a workflow.
so a config file to specify
public: true/false
preview the site locally, pack everything into an sqlitedb and upload that db to the service?
stht sync => uploads the sqlite db to remote
this is cooked what the fuck do I want
I really like the idea of separating out the auth from the user so I just need a way to handle blocking certain pages in the upstream service?
so ingestion service