Spent some time thinking about what it would take to bind Mastodon and the ATmopsphere and the remains of the blogosphere into a single information space.
Yes, I do realize some folk would rather erect a little moat around their social space rather than to unite against the people yelling 'free speech' as pretext for censoring all opposition to the orange rapist. Well tough.
First dimension of welding together the social media is to enable people to use a single account anywhere. OAUTH provides a framework for doing just that but it is only a framework, to achieve account portability, we need a single standard that is widely supported. The BlueSky profile of OAUTH looks like it does just that. There is one dependency I would like to shear off but that is pretty much it.
Second dimension is to provide a standard means of presenting an index of a social media stream. This is the role RSS was originally developed for but being based on XML which only allows for one root element, the entire RSS document has to be rewritten every time a new entry is added.
I proposed a format that allows JSON and XML objects to be packaged up in a simple binary format for precisely that purpose some years back. I am now proposing it to IETF as part of my @nyone proposal. The idea is simple, wrap each JSON or XML object in a binary frame using the same varint length-data chunking scheme used in QUIC.
The third and final dimension is an efficient update notification mechanism so that any one of millions of users can be notified when any one of billions of information assets is updated.
RSS allows Alice to pull a document giving the last ten posts of Bob's blog. Expanding that to all the posts is an improvement but what Alice really wants is a scheme in which she is informed the minute any update occurs.
This is a problem that is solved to a degree in pretty much every modern social media system. What I want to do is to strip that mechanism down to the absolute bare minimum so that it can be used as a generic protocol building block across systems built for entirely different purposes.
For example, when Alice updates her JSContact card, she wants Bob and everyone she knows to start using the new contact immediately.
This part of the problem is the part that is still 'research'. Which is to say that it is a problem Blue Sky and Mastadon have only partial solutions for at the moment.
The part that makes it a really hard problem is that the advertisement mechanism is potentially under constant attack from parties attempting a denial of service attack. The goal of most Russian disinformation operations isn't so much convincing people of anything in particular, it is denying them the ability to think for themselves or discuss anything amongst themselves.
And to make my specific problem with the Mesh social media system harder still, all the content is encrypted end to end, none of the services know what it is saying.
So before I start, yes I am aware that much of this is supported by existing schemes. The different is not the features I am adding, IT IS THE FEATURES I TAKE OUT. The reason the Web worked when Xanadu did not is not because the Web has cleverer technology, the real breakthrough was junking features driven by Ted Nelson's peculiar ideological commitments that were very expensive adding complexity and computation overhead into the specification core. The Web doesn't guarantee referential transparency and doesn't support search directly and that is why it works.
The design I am looking at right now begins with the concept of an aggregation provider which accepts notifications from a set of producers and forwards them to a set of consumers.
Each notification is a fixed length data object specifying a unique notification identifier, the producer identifier, the object that was updated by means of a UUID, the time the update occurred an indicator of the update type and a logarithmic indication of the number of updates.
[Collections of notifications MAY be authenticated by means of an efficient digital signature scheme, e.g. ML-DSA over a Merkle Tree. Since this is only needed for an accountability control, it does not need to arrive with the notifications.]
This allows a blog to inform the aggregator that there have been ~200 like/dislike responses to a post. It also allows the aggregator to create summary notifications aggregating across producers responding to the same object.
It is not necessary for the update count to be very precise; a producer is likely to react differently 1,000,000 notifications that a hash tag is being used than ten but isn't going to be reacting any differently to 1,000,001.
On the consumer side, consumers respond to sets of notifications indicating relevance so that the aggregator can pick the items to forward in the future. This is the primary defense against flooding attacks. Producers generating notifications that are consistently flagged as irrelevant will be deprioritized and eventually dropped entirely.
Limiting the notification engine to just reporting the fact that an update has occurred allows the defenses against resource exhaustion attacks to be made more effective as they are not attempting to provide protection across a wider field.
Now obviously, generating plaintext notifications on the basis of the content of encrypted posts is going to compromise confidentiality.
That is going to require some degree of encryption of the notifications and we are probably going to have to accept that there will be some residual leakage even then but certainly less than what leaks from S/MIME because the subject line isn't encrypted.
Nefarious Aryq