This isn't the hard part of self-hosting, at least not anymore. In the comments here there are lots of examples of similar projects that solve basically the same problem (app selection and deployment). To make self-hosting "easy" we need to solve domain registration, DNS management, and port-forwarding configuration.
This probably requires a project more like OpenWRT that includes an API-driven relationship with a registrar. The lack of a standard (consumer accessible) domain registration API is a huge hole in automating this. If such a project gets some traction, then it could migrate to a physical router that prospective self-hosters could buy. With domain registration, DNS management, and port forwarding all in the router's software, then the remaining hard parts can be sufficiently automated to make self hosting accessible to the average gaming console owner.
In that time I started a domain registrar, a free OpenID Connect login service (https://lastlogin.net/), created the de facto list of tunneling tools (https://github.com/anderspitman/awesome-tunneling), and built a couple of my own tunneling tools (SirTunnel and boringproxy), all to try and make self hosting easier.
I'm still trying to solve this problem. Some progress has been made (mostly by other projects), but we're still not there.
FWIW, I used to think everyone owning a domain was the way forward. I now suspect otherwise. Domains are too expensive (especially most TLDs outside .com/.net/.org) and the costs of accidentally forgetting to renew are catastrophic. Domains just aren't a consumer product.
I think you only need a domain if you want a permanent public web presence, and I don't think most people need that. Most people just need a better/faster/private google drive, google photos, google docs, etc, and for that it's ok if your domain changes once in a while.
So I think free subdomains set up without vendor lockin are probably the ticket.
If anyone is interested in collaborating in this space, definitely reach out.
I wholeheartedly agree with your comment and have thought a lot about how I would solve these problems. Considered founding a startup as well, but the market size is very unclear. I would say in theory, cloud-in-a-bottle already comes quite far. The only thing missing is another tier where imbue only provides you with a domain and a reverse-proxy so your home-server is reachable. Of course, their software would then also habe to manage the whole certificate lifecycle and DNS-challenge, but if it did, then you can have your server at home and not have to worry about how it manages to be reachable from the internet.
However, if I'm understanding you correctly, a solution like this would also be too much vendor lock-in for you, correct? If so, how independent do you wanna go? I think especially if you want people to be able to self-host from home, you will always need some proxy in the cloud. Or are you considering a DDNS setup?
I agree and disagree. Easy management of server apps IS a hard part. Domain registration, DNS management and port-forwarding are ALSO hard parts.
For 99.99% of the humans on earth, their primary computer is a smartphone. Anything that they can't do with a smartphone-like interface is hard, bordering on impossible. Even on the smartphone, there is a huge app complexity hurdle - sure some folks will use complex apps, but most people won't go much further in complexity than a subset of the apps that come with their phone. They'll add apps because it is easy, but they won't actually use apps that are too hard for them to use.
These days, those same majority of the population might be annoyed at having to use an app to manage their wireless headphones, printers, smart appliances etc etc.. but they WILL do it. And they CAN do it.
Effectively all of those devices are technically servers too. Back in my youth, we'd call a printer connected to a network a "print server" and it was often a standalone device that connected the printer to the network.
There is no inherent reason that managing a fairly capable server, backups, DNS, VPN tunneling, port forwarding etc can't be as simple as "a basic app." Yes - a lot of limitations on what is theoretically possible will be imposed. Limitations and defaults will need to happen in the background to keep it simple. But it can happen.
Insightful comment I fully agree that the hardest part needs to be automated fully, there's plenty of DNS providers with API access so it can be done. Naming is oftentimes the hardest part we have in tech, I dream of a future we are more decentralized and we have alternatives to DNS to access ressources,see this great text by Andrew Nesbitt about the subject of naming: https://nesbitt.io/2026/03/03/package-management-is-naming-a...
Has anyone built a dedicated OPDS client for the Kobo?
I've experimented some with the Kobo ecosystem since I got my Clara BW, I've played with NickleMenu, Plato, and KOReader. KOReader has a built-in OPDS client, but KOReader is a bit heavyweight and it would be really nice to have a dedicated stand-alone client (especially one that supports credentialed OPDS feeds like calibre-web exposes)
I've been using .lan, referenced in rfc6762[1] as a good alternative to the multicast .local
> We do not recommend use of unregistered top-level
domains at all, but should network operators decide to do this, the
following top-level domains have been used on private internal
networks without the problems caused by trying to reuse ".local." for
this purpose:
Sharing my experience as a tinkerer, sideloader, and recent Kobo owner.
I used a Kindle for ages, always in airplane mode and only sideloading content. Honestly, it was a pretty good setup.[1] But it seemed like it would be harder to setup this way on newer devices, so when mine finally failed, I got a Kobo Clara BW. I was thrilled I could boot it up in "sideloader mode" and not even register it or enable wifi.
I noticed poor typography on my epubs, learned about converting to kepub so I did that (which helped). It was a familiar flow to what I was used to converting to azw3 for the Kindle. My remaining typography gripe with kepubs is that it treats a word+em-dash as a word for inserting space in full justification. Em-dashes generally don't have spaces on either side, this often looks like a space has been inserted only to the right of the em-dash.
I went down the rabbit hole of NickelMenu and other readers including KOReader and Plato, and even tried (and mostly failed) to vibecode my own opds client app. (because KOReader which has one built-in felt overwhelming)
My current sense is the device feels so much more like it is mine. I have much more flexibility to tinker with it. It is not as polished as the Kindle and the Adobe rendering feels stupid, but that's also a sharp edge that only the side-loading community will hit, most of whom use Calibre which can auto convert to kepub for them. Everyone else is buying books from the Kobo store and getting them delivered as kepubs.
So in the end, I'm a big fan of the Kobo devices.
[1]: Except you cannot remove a wifi password if you aren't in range of that wifi signal. I had a rude experience when my two-year-old was fiddling with my Kindle at my in-laws' house and turned on the wifi where there was still a saved credential. An update triggered immediately and I was frustrated for days that everything in the UI changed.
I consider myself pretty pro-privacy, but there is so much dragnet surveillance and legitimate breaches of the fourth amendment that I have a hard time getting up in arms over a company complying with a valid search warrant that is scoped to three hard drives (and which required law enforcement to have physical possession of the drives to begin with).
This is so much more reasonable than (for example) all the EU chat control efforts that would let law enforcement ctrl+f on any so-called private message in the EU.
A lot of them are not really legitimate though. There's a reason that 4th amendment needs a modern version to require a warrant for tapping of any sort for things people generally assume are private. Flock, palantir, etc need to all go bankrupt, starved of data to spy on. In an ideal world of course. Maybe someday we'll wake up from the nightmare.
The article goes back and forth between bloggers who "are doing well" (ie: making money) and efforts that are non-commercial. It comes across as asking humanity to put more effort into writing and publishing in a non-profitable space while the blogging incentives are profit. I still think the unexplored space for blogging (and the LLM-proof space) is _private_ blogging--for friends and family. But maybe Facebook killed that space off, who knows.
This probably requires a project more like OpenWRT that includes an API-driven relationship with a registrar. The lack of a standard (consumer accessible) domain registration API is a huge hole in automating this. If such a project gets some traction, then it could migrate to a physical router that prospective self-hosters could buy. With domain registration, DNS management, and port forwarding all in the router's software, then the remaining hard parts can be sufficiently automated to make self hosting accessible to the average gaming console owner.
reply