making the roaming future

I’ve been recently thinking about this and if we really want everyone, not just the nerds, to have their own stuff on the web and not settle on joining the social networks akin to Twitter and Facebook, we need to have easy solutions for each step in our web-citizen self-development.

First, we’d set up a blog on third-party’s subdomain. You could choose the template for the thing - is it a blog, microblog, photo blog? In all cases you’d get a website with RSS feeds. Yay.

Next you’d need out-of-box comments, working webmentions, or some other means to enable conversations, so your own social network emerges.

If you want to keep your web content on your own domain, you need to be ready to pay for that a bit. You should be able to find a domain, pay for it and be done with it. Once the domain would be set up, all traffic from the subdomain would be redirected to your new home. Just as you don’t change your mobile number every time you switch the provider, you want to keep a fixed web address as well.

If you wanted to customize the blog, a simple action would lead to stylesheets and templates becoming available for you to edit. Your template editor would hold your hand the entire time -- show any issues with the template (both the template markup and the resulting HTML) so you wouldn’t get a broken blog in the end. Messed up somehow? You’d be able to easily revert to the default state.

If you wanted to go further, the web app that drives your blog would be revealed and you could now dig in and modify the code. Decide you don’t want to maintain it after all? Reset, revert, no problem.

You wanted to move to another provider or host the content on your own? This should be easy, or at least possible. The building blocks, like e.g. docker images, would be there. They’d need to be put together in an elegant fashion so the process is seamless.

There is the issue of storing the blog posts so they don’t get buried in a binary file of a perhaps an obscure database that may be the hotness of the moment, but will go unmaintained in a year. SQLite, although one of the greatest technical software achievements of all time, is still an SQL database with a binary storage file and the data structure kept by it can be essentially anything. The filesystem with plain text files of a known schema seems to be a simplest and most portable solution. My blogging system does that and the flexibility is amazing. But perhaps instead a Perkeep store, if a plain-text one is not possible in case the provider doesn’t allow access to a writable filesystem. Those solutions are actually much better also because they are much more reliably syncable - Perkeep’s ability to sync stores is one of its main goals and features. Currently if you write to the web, your content is stored there exclusively, until you remember to either export or back it up, and sometimes that’s much too late.

Another issue is scalability. In the good old days, if a post on your blog got popular enough and got Slashdotted for example, your host would simply melt down under the sudden spike of incoming traffic. I’m not sure how modern hosting solutions stand up to Reddit/Slashdot loads, but then again, if the blog is based on static files generated upon edit, it’s mostly bandwidth that’s needed, since serving static files from fast storage should be enough for everybody who’s not Google.

Glitch, for example, implements some of those ideas. It doesn’t check all these boxes, but they have the tech to do so. It would have to be wrapped in a less of a hack-your-thing kind of a product, and more like a set-up-your-stuff-on-the-web-easily one.