> These extensions could include:<p><pre><code> delivery receipts => XEP-0184: Message Delivery Receipts
optional read receipts => same as above
user presence information => XMPP RFC
binary serialization for efficiency and extensibility => XEP-0231: Bits of Binary
end-to-end encryption => XEP-0373: OpenPGP for XMPP, XEP-0384: OMEMO Encryption, XEP-0378: OTR Discovery
WebRTC signalling for negotiating VOIP and video chat => XEP-0343: Signaling WebRTC datachannels in Jingle
signed introduction tokens to reduce spam => ?
a standard extension mechanism => https://xmpp.org/extensions/
</code></pre>
Can we just stop prettending that XMPP is not ready and/or outdated, all those things are there, used and implemented in more clients than Matrix has.<p>Doing decentralized social media, on XMPP, is possible. Take XEP-0060: Publish-Subscribe, add Atom 1.0 (yes it's the power of XML, you can put a standard in another) and boom you have a social network with feeds, comments, subscriptions and everything, fully ready.<p>I'm doing that for years with Movim <a href="https://movim.eu/" rel="nofollow">https://movim.eu/</a>. The several major XMPP servers are handling that perfectly as well. How many Matrix servers are out there ? One, that is still in beta (Synapse).<p>XMPP is standard (IETF wise), is already massively deployed, is used by universities, governments, companies…, is exensible, is stable and is maintained by a big and motivated community.<p>Don't reinvent the wheel once more, just implement the standards.
Protocols and privacy and chat features are all great, but let's not lose sight of the two absolutely killer essential features of every successful chat app / system:<p>(1) The address book.<p>(2) The easiest possible signup and setup.<p>More generally for #1, whatever method(s) you use to find people's contact information and connect with them.<p>Without that, you could have created the perfect chat experience in every way, but people still won't use it. Because their friends aren't on it and/or they can't find their friends.<p>A ton of chat apps fail because engineers sit around talking about how to architect things, when the truth is that once you've gotten past the almost-insurmountable hurdle of getting two users onto the system and starting a conversation, the actual mechanism for actually sending messages back and forth is not much more than an implementation detail.<p>Not that those things aren't important, but they are like 10% of the formula for success, and the other 90% is getting to the point where they can start a chat session.<p>People's primary need is to communicate. With the people they want or need to communicate with. And via the contact information they have available. (Exchanging contact info for a new service offline is a huge hurdle.) A better experience is better, but at the end of the day, these other concerns will nearly always win out. So you don't get very far trying to use a superior experience as leverage to get people using it. You need to attack that problem more directly.
This is what I’m working on with Aether (<a href="https://getaether.net" rel="nofollow">https://getaether.net</a>). A mass-communication method owned by no one, like email is owned by no one. It’s a modern, decentralised Usenet.<p>I used to call it <i>‘email for mass communication’</i> but it confused people, since it’s not based on email, so I stopped calling it that. That’s the goal though.<p>I also gave a talk on it at the Internet Archive last week, if you want a quick intro in video from. <a href="https://archive.org/details/12120iadweb" rel="nofollow">https://archive.org/details/12120iadweb</a> (My part starts at 1:13:30). If you have any questions, happy to answer.
Completely agree. For anyone who hasn’t come across it, check out the exciting work being done by developers of the Secure Scuttlebutt protocol:<p>“Secure Scuttlebutt (SSB) is a peer-to peer communication protocol, mesh network, and self-hosted social media ecosystem. Each user hosts their own content and the content of the peers they follow, which provides fault tolerance and eventual consistency.[5] Messages are digitally signed and added to an append-only list of messages published by an author.[6] SSB is primarily used for implementing distributed social networks, and utilizes cryptography to assure that content remains unforged as it is propagated through the network.”<p>Read more: <a href="https://en.wikipedia.org/wiki/Secure_Scuttlebutt" rel="nofollow">https://en.wikipedia.org/wiki/Secure_Scuttlebutt</a><p>Join us! There is a fully functioning client, and bustling Solarpunk community: <a href="http://scuttlebutt.nz" rel="nofollow">http://scuttlebutt.nz</a>
Mentioned in a separate thread, but DeltaChat [1] offers a WhatsApp-style messaging interface over standard email.<p>[1] - <a href="https://delta.chat/en/" rel="nofollow">https://delta.chat/en/</a>
I miss the days when one chat app could easily connect to multiple protocols. I didn’t care if my friends had AIM or Yahoo or ICQ or whatever, they all showed up as a tab in Adium’s window and a name on its floating buddy list.
I'm working on a sort of ancillary project which may help with this at Valyrio [<a href="https://valyr.io" rel="nofollow">https://valyr.io</a>]<p>Counter-intuitively, the current goal is to <i>centralize</i> the messaging interface, providing a common platform for users who are willing to pay for a consolidated system that saves time and confusion, and to reduce the waste of niche use cases (e.g. having the entire [name here] messaging app on your phone because one weird family member or friend insists on using it)<p>Bringing email, text, and (aspirationally) all other messaging systems into one.<p>In doing this, we cannot possibly hope to uniquely integrate each of the countless hundreds of services with their weird quirks and formats, so I aim to establish a standardized language for async messages equipped with the basic common features and extensions for prevalent (but not universal) features like read receipts, "liking/reacting" to messages, etc<p>It would be really cool to open up that standard to the world if we do a good job of designing it, or collaborate with anyone else who wants to participate in this goal. Our core service will be a niche, paid, closed system, but the underlying language I would like to be open source and interoperable with whatever else turns out to develop (Twitter's new endeavor and Matrix are the two efforts I am most aware of)<p>After all, Valyrio <i>means Language</i><p>I've also been working on an adjacent concept with [<a href="https://jwmza.com/polymath" rel="nofollow">https://jwmza.com/polymath</a>], which is a new comprehensive markup language meant to define long-term compatible, human readable documents and websites/document structures which intermix existing standards like (La)TeX, HTML, CSS, Markdown etc.<p>Perhaps the underlying language and concepts here will mix with the effort to decentralize messaging as well, as messaging is fundamentally the asynchronous bidirectional transfer of documents of mostly text and sometimes other media or information.
Isn't this, at least in part, the goal of OStatus/Mastodon? It's a great idea but I find it humorous and ironic that many mastodon admins circulate block lists specifically meant to cut off nodes. I would prefer that users just use the block features available (and adding the ability for a user to block nodes or apply blocklists if they want to, but not for admins to make that decision for them).
> messaging apps are all the same, making them easy targets for standardization and interoperability.<p>This is patently false. Look no further than the other comments in this thread. Nobody can agree on what they want out of the messaging experience. Some want a rich experience like telegram and others want a minimal one like IRC. Should this protocol's features maintain parity with the proprietary and centralized services? Better develop them rapidly to keep up. Should they stagnate to maintain interoperability across an ecosystem? Good luck being competitive. We haven't even gotten to the features themselves and I promise you there will be irreconcilable differences. Does the protocol maintain message history or is it ephemeral? What is the privacy model? Can we delete messages on other servers due to GDPR? When you spend time at the business end of the messaging space, these dichotomies flow endlessly, without consensus, and they cover the entire horizon of the space.<p>If you think you know the answers to these questions, you don't, because you're solving the wrong problem. If you want to decentralize messaging you have to solve the problem of how to agree to disagree while maintaining interoperability for a shared experience. Let me just make that last point clear: you cannot design a messaging protocol where one party sees emojis and the other doesn't. That doesn't work because you can't lose social information.<p>Matrix has failed to solve this problem. We need a new approach. What will emerge to finally conquer this space?
> I see two promising and complementary paths to decentralized messaging: building on the new and shiny Matrix protocol, and gradually extending email.<p>COI is chat over IMAP[0], I think it's one of the best solutions I've seen in the sapace.<p>[0]: <a href="https://www.coi-dev.org/" rel="nofollow">https://www.coi-dev.org/</a>
It feels like we are saturated by messengers and social networks. Twitter, fb, slack, discord, matrix, signal, whatsapp, wechat, telegram... I am not sure what decentralization could bring there.
I talked to Twitter's CTO, Parag.<p>He said the move is to specifically reduce fragmentation in public conversation.<p>I'm in the decentralized (dWeb) community (we have 10M+ users monthly, in-production, running thru GUN) and admittedly, I think we all get distracted with the war cry of privacy, p2p-for-sake-of-p2p, etc. but is not many other people's end goals.
I don't know why everyone hates XMPP. There are multiple solid open source server and client applications for just about every platform. It is decentralized and works well but without google, apple, and facebook making it practical for grandma to use, it doesn't catch on. Well the big players have no incentive to cede control to decentralization.
We could decentralize things more, but then people will point to decentralized communication and claim it's dangerous because it helps drug dealers and pedophiles.
Unfortunately, it's probably too late. Email caught on because it was the first option, and it's become ingrained in spite of itself.<p>At this point the closest thing to a standard for person to person messaging is SMS... which like the old guard of ICQ, uses a number rather than a screen name.<p>That said, I would love to see a good standard for person to person chat, especially one that doesn't rely on magic numbers.
It is astonishing to me that, after skimming the spec, anyone believes Matrix is the future. Or ActivityPub. Or XMPP.<p>The future of messaging, decentralized or not, is certainly something with a tractable protocol.
Social media has more problems besides the need to “decentralize”<p>The biggest problem with social media is how it is ruining our mental health.<p>It’s sad that almost no one looking in to this.