One way to define identity to meet all these requirements is to have the id be a URI with the URI internally (as in the HEAD section) identify my current server. Examples that fit this purpose are OpenID, indieauth and WebID. But alas, it is too late for email; but not for the new crop of fediverses.

This means my server must be able to use third party authentication If I must be able to change my server, the id shouldn't explicitly identify the server. And another desirable property to have is I must be able to bring my own identity.

A proper design of email would be I store the content in my server and push a short notification to your server which delivers the notification to you if I am in your whitelist. To read the content, you use the notification to pull the content from my server, which will deliver to you after authenticating you.

Previous examples of fediverse have this flaw built into it. Consider PSTN, email. Yes email. Though fediverse proponents use email as a shining example of fediverse, indeed it is the opposite - one should not design a fediverse along the lines of email.

Almost all of the fediverse have a fatal flaw in the way they have structured their id and also how they authenticate them. The flaw is they include the server in the id and the server authenticates the id on its own. The problem with this is that it is not easy to port the data to another server, though data portability must be a desirable feature. This point was made by admin in a recent VUC call.


Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!