I am trying to work out the strengths and weaknesses of messaging platforms from fully decentralized to federated to centralized. I am only a user on Mastodon/activitypub and IRC, but I have in the past hosted usenet and currently host:
smtp (email)
XMPP
Matrix
SSB (Secure ScuttleButt)
SIP (fully decentralized)
The impressive feature of twitter and it's totalitarian centralized ilk is that a single id can have millions of followers - and know that. SSB supports unlimited secure (signed) broadcasting, but there is no mechanism for knowing how many followers there are. Of course, TV was in the same boat, and you could get an estimate by polling. BBC broadcasts on SSB.
Counting followers is essential for monetizing content via advertising and sponsors in a decentralized manner - i.e. not subject to cancellation at a whim by a global centralized platform.
Matrix seems ideal for many of the purposes people use Teams or Substack or Slack. Private conversations e2e encrypted, logging with controlled retention (HIPPA compliant), voice and video calls, voice and video conferencing, media. But performance of small personal servers drops with number of participants in a room - I don't think it can support a million followers.
XMPP has inconsistent state for multiple devices, and is terrible at group chats. I do use it a backup for matrix and for voice/video calls. Open XMPP clients supporting VOIP and IPv6 are easier to find than SIP clients. (And SIP is even worse at state for multiple devices.)
Usenet has no authentication (not worth tacking on GPG header schemes).
Email is not designed to be "instant" (as in IM), but can be coaxed into resembling that by clients such as DeltaChat.
Ok, so now I should make a feature matrix (which includes Matrix), but have I missed any open and federated/decentralized protocols? Any other features? Current feature list:
broadcast (million+ followers)
follower count
p2p voice/video
e2e encryption
authentication
federated
decentralized (or federated that can be practically fully decentralized, like SMTP)
Did I miss any?
@customdesigned What about RSS/Atom and having something like a feed reader/aggregator for Mastedon. I think this would make for more fluid usage, rapid curation, and identification of new content being followed.
@orcmid HTTP doesn't scale - without applying abominations like Content Distribution Networks - which greatly diminish confidence in authentication (private keys distributed to CDN servers).
Further, HTTPS authentication for Joe Sixpack is accomplished by using the TLS cabal - which can cancel you at a whim (and has done so). ICANN can also cancel domains at whim (part of the agreement for official TLDs).
Yes, you can run your own CA, your own TLD, and this works very nicely, and we have done it for a private Matrix homeserver. But unless you know Joe personally, he is not going to be installing your CA and DNS resolver for his browser.
@customdesigned Wow. I am not so disturbed by HTTP[S] and I'm using Mastodon in my browser this minute. Something like a feed reader could work assuming the Mastodon APIs are supportive, whether or not it is literally RSS/Atom. I don't quite know how the endstate you aspire to is going to be consumer and casual-user friendly.
@orcmid There is nothing wrong with HTTP - it just doesn't scale. Your Dell server in your office is not going to support a million people viewing your site.
There is nothing wrong with TLS - it just that a secret cabal decides what CAs are included by default in popular browsers - wielding an effective power to cancel.
There is nother wrong with DNS are originally conceived - it has just been centralized because companies were mad that using a new "cool" TLD wasn't resolved by all users (depending on the sysadmin for their DNS resolver). There were the original ARPA TLD list, and ISO country codes that everyone agreed on. (With some disputes over nations out of favor - e.g. Kurds today banned by ICANN.) But using .COM for your company was BORING.
But mainly, ICANN was sold to sysadmins as a convenience - no more following mailing lists and keeping nameservers updated for the TLDs you support. ICANN does all that work for you! All they ask in return is world domination.
There are attempts to provide a successor to HTTP that scales. E.g. IPFS, DAT, and other content addressable schemes. Note that CDN providers work similarly to IPFS, and their business model continues to hold if IPFS gets widespread adoption. (Pay us to ensure your content is cached close to your customers - instead of relying on amateurs who may or may not be reinstalling their server at the moment or turning their desktop off.)
@customdesigned This all hinges on the assumption that I would want to run a server in my computing locality. I understand your perspective for that situation. It's not a problem I intend to have.
@orcmid A long term goal is get EVERYONE to run their own DNS resolver. Or at least use a trusted geek's resolver. Like everyone did before using ICANN became widespread. DNS is *supposed* to be federated. Using ISP resolvers is a huge problem, even if you aren't concerned about centralization.
If that were accomplished, then it would be easier to convince people to add just your TLD - it wouldn't interfere with anything else (except someone else's TLD with the same name - in which case they have to choose).