So far I have written a couple of posts concerning the stagnation of the fediverse, and I must say that the resonance has surprised me. It is clear that the fediverse matters, but it is also clear that it repels the opensource community.
Issues I raised are:
The reason is, precisely, that unlike other standards born for opensource, Activitypub was born exclusively for entrepreneurs and companies that can afford substantial budgets, or at least a fair amount of man-hours, to write an instance of the fediverse.
The creator of ActivityPub, after all, was an entrepreneur, and this standard is descended from ActivityStream, a standard whose minimal implementation in golang requires several MILLION lines of code. Impossible for an individual to handle, let alone make it safe.
If we check all attempts to write working code using ActivityPub, we see the barrier: everyone is stuck when they have to use this horrible standard to communicate. An example is lemmy: the first part was to write forum software, which worked. The second part was to get Lemmy to talk to Lemmy, and the last, most difficult and still incomplete part was to get Lemmy to talk to the rest of the world using ActivityPub.
This is clearly a problem: it means that for the opensource programmer, ActivityPub is a barrier. The aim of our action, therefore, should be to reduce the learning curve and leave only the functional part to the programmers.
This new protocol, therefore, should aim to be:
- simple to implement
- preferably pre-existing, so as to find well-made libraries
- tested
- clearly standardised.
optimized in a way to:
- increase its adoption
- invite to self-hosting
- number of programmers who set about creating software
First, therefore, we must ask ourselves whether we intend to keep the syntax “user@FQDN”. In that case, we certainly don’t have to invent the wheel, because we have the first candidates:
- SMTP
- XMPP
- SIP
the fact that we do not have to implement the wheel again, using already existing libraries, will make our software more stable, and more secure.
The mistake not to make, however, is to add complexity. If, for example, we think of SIP, we find that SIP is extremely effective for managing online presence and initiating a session.
What type of session is then decided by negotiating another layer, SDP (session definition protocol). This makes it enormously flexible, because the SDP session could range from a PDF file, to describing the codec for a voice call, or a video codec.
The trouble is that at this point the SDP layer could say “this is an ActivityPub session”, everything would be legal. Not even ActivityPub, in fact, specifies that the payload must be sent over http: any transport is fine.
But by using SIP, in addition to choosing the most difficult to implement of the three protocols, we have also decided to use a ‘superset’ of ActivityPub, something that can contain it. And that’s no good: we wanted something SIMPLE.
Let’s discard SIP, and try something simple. Let’s try SMTP. SMTP is simple, a programmer can implement it in a day, or less, and it allows a fairly extensive grammar.
Our instance, in fact, wants to group threads, and would like replies to a message to be grouped. And if we read a little bit about the grammar of SMTP, we find that the headers contain everything we need to describe the relationship between the reply and the message, and reconstruct the thread.
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
From: XXX <[email protected]>
Date: Mon, 10 May 2010 23:20:59 +0200
Message-ID: <[email protected]>
And to put it bluntly, there are also convenient headers that could help manage groups, such as Reply-To and ‘Sender’, which is different from ‘From’. Everything we need to do in the fediverse.
tools.ietf.org/html/rfc5322
Also amusing is the fact that using a header such as x-face it is also possible to send an avatar using a protocol field.
For the rest, the richness of MIME may already answer how to attach things to messages.
In this case, subscribing to a user would mean subscribing to a mailing list whose replies go to everyone in To or CC, whereas a ‘group’ would be a real mailing list, which already has its own semantics set up for subscribing and unsubscribing.
I already know that this sounds offensive. It sounds offensive because we are saying that a ‘social network’ is just a webmail, whose interface is more social-like than webmail-like.
This will offend all those who think they’re creative and ingenious because they reinvent the wheel: but it’s not my fault that you wanted to invent protocols (and failed) where good ones already existed.
The fact that a social network is just a UI placed in front of any communication protocol, on the other hand, is nothing new: even the guys who make ‘Delta Chat’ based on SMTP+IMAP, had the same idea. And it works.
But the point does not change: a social network is effectively a UI, which can represent any flow of communication, including email.
One crucial point remains to be discussed, which is transport. Transport is problematic for several reasons:
- SMTP is blocked in residential networks, discouraging self-hosting
- protocols with ‘user@FQDN’ semantics depend tremendously on DNS, which are also under government control.
SMTP must therefore be considered, where:
- works on other ports (not 25)
- works on other protocols (I don’t know, UDP), which however makes us subject to the hegemony of the DNS
- uses other transport protocols, such as DHT, or libp2p.
That way, we could build a possibly more scalable fediiverse, one that invites programmers to write instances and people to host.
The ActivityPub protocol is a useless attempt to rewrite the wheel, since almost nothing is needed of what is in the protocol if the purpose is only to send a message to “user @ FQDN”
Will anyone change direction? No. The Fediverse in some ways appears dangerous, in others it appears inevitable: this attracts a lot those who want to be the next Zuckerberg, and a few others.
Having something simple, and recognizing that a social network is just a webmail with a particular interface, is not easy for those who believe they have invented who knows what, and it is not even easy for those who could tomorrow be told that everyone social networks could communicate with each other, if only someone had used something like smtp to make them communicate.
I therefore do not believe that the adoption of a simple and public protocol will ever be in the mind of those who today are too focused on trying to dominate the new invention.
