and RSS.

The only thing they seem to miss from the author's description is: "It has to be decentralized. The database would be hosted on many computers and each new entry would be processed using some sort of consensus algorithm."

But there's no motivation for why this is a expected property of the network

RSS came to my mind too. If everyone self-hosted something that gives an RSS feed, your social network feed could really just be an RSS reader.

RSS is a good example. In the simplest form my proposed social network structure could be seen as RSS feed of all the social web that is stored in a decentralized database. The main feature is that the posts can be 'liked' or 'upvoted' by users (domains).

The sudden idea is to separate metadata and content on different services and merge them only for viewing and interaction. Then users can selfhost content and request its distributed social metadata (upvotes, emotes, other people's comments etc) dynamically without easily losing control over the content itself.

Masoton doesn't encode useful information in the URL like the author described in the first section.

It's an implementation detail. You probably just need to change the code of file to change the format of Mastodon's URLs: https://github.com/tootsuite/mastodon/blob/master/app/lib/ac... and this line: https://github.com/tootsuite/mastodon/blob/master/config/rou...

Neither of those examples are working well - not even close.

They "work" in the sense that they have a checklist of features that I'm sure function as intended.

But the product/network as a whole is far from "working".

Maybe, but the article needs to talk about that. That is my point. From my own view, I'm using both of those things and it does work, so why would I entertain a slough of new ideas to be started from scratch without seeing a compare and contrast discussion?

Yep, that's fair pushback on the author; I agree.

> But the product/network as a whole is far from "working".

In what way?

Number of users I guess.