I like the tone. But what the author describes as potentially world changing enablers is not triple entry blogging, but open standards, open APIs and (very) easy to use distributed nodes in some Form of mesh that uses these open standards to build cool stuff on top of this networked open standards based mesh.<p>I just sadly doubt that most people outside a very specific bubble would want to have their own node in said network. Even without the need to care for it, think about hosting and so on.<p>Most people are fine with using "rented real estate" on a centralized platform. It doesn't cost them time, nor money (advertising and data collection as revenue streams). They connect with people (social networks) or use a service (Goodreads) to achieve some form of goal.<p>Why would say add any friction for themselves? Any complexity above that?<p>A much as I would love to have these decentralized open networks, I will miss them in the future. Sadly it seems that central platforms have won.
So double entry accounting records each entry as a debit and credit which enables all sorts of new possibilities in accounting. Triple entry blogging is just having two backups for everything with completely different technology from those backups enabling some other things? I don’t get it. I don’t see having two backups as being any sort of secret sauce the way double entry was.
I handwrite all my blog posts in a journal then use Paper Website [1] to publish them online. This is great because I have a physical paper copy, and a digital one.<p>This "double entry" system has been pretty useful - I accidentally deleted a page once, and recovered it back by simply taking a picture of the physical page again - was pretty neat!<p>[1] <a href="https://paperwebsite.com" rel="nofollow">https://paperwebsite.com</a>
The comparison with double entry bookkeeping seems a little bit far fetched, in my opinion. But I like the enthusiastic tone of the article and I understand the comparison as a starting point for brainstorming new ideas!<p>I am now reading his post about RSS (<a href="https://tomcritchlow.com/2022/04/21/new-rss/" rel="nofollow">https://tomcritchlow.com/2022/04/21/new-rss/</a>). Good stuff!
How to implement what OP wants to have:<p>- their content stored on a PouchDB/CouchDB server. blog posts, comments, shared memes, listened songs... anything can be represented as an ActivityStream document<p>- files/attachments can go to an IPFS store<p>- the ability for authenticated users to <i>pull</i> this data, and remix into their own database.<p>That is it. You can then have all kinds of tools to author the content. You can have your static site generator pushing your content there. You can have a audio scrobbler and get last.fm. Any commit to github can become a entry in the journal. You can send pictures from your phone. Saved bookmarks. Shared cooking recipes...<p>So you will have your different sources of truth (git for the text content, your media library for your pictures), you have the database and you have your peers databases as the "remixed" copy of your data.
I love the idea of physical libraries establishing federated social media offerings, leveraging protocols like ActivityPub (to ensure interop)! To be sure, there would be challenges, and the model would not be ideal for all types of social media users...but I really like the opportunities that this approach can provide.
So.. a CI/CD pipeline?<p>You have the source (your local text files) which is deployed somewhere (GitHub pages) which other entities can access (spiders crawling it).