
Decentralize Messaging - wiggler00m
https://rodarmor.com/blog/decentralize-messaging/
======
edhelas
> These extensions could include:
    
    
        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/
    

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.

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.

I'm doing that for years with Movim [https://movim.eu/](https://movim.eu/).
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).

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.

Don't reinvent the wheel once more, just implement the standards.

~~~
neiljohnson
> How many Matrix servers are out there ? One, that is still in beta
> (Synapse). Worth noting that Matrix as a protocol and Synapse as a server
> implementation left beta in June 2019
> ([https://matrix.org/blog/2019/06/11/introducing-
> matrix-1-0-an...](https://matrix.org/blog/2019/06/11/introducing-
> matrix-1-0-and-the-matrix-org-foundation)). Matrix is deployed by
> governments and civic institutions the world over including emergency
> services. It is literally trusted in life or death situations.

While Synapse is the most mature server implementation there are others under
active development listed here \- [https://matrix.org/docs/projects/try-
matrix-now](https://matrix.org/docs/projects/try-matrix-now).

~~~
jasonzemos
Thanks Neil. It's difficult to find alternative servers on that page so I will
help by linking to The Construct which is the only other federating server.
Though it is not yet stable, it is the only functioning third-party server and
has more progress than your own reference implementation's rewrite!

Check out [https://github.com/matrix-
construct/construct](https://github.com/matrix-construct/construct) and join
us at #admins:matrix.org

------
adrianmonk
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:

(1) The address book.

(2) The easiest possible signup and setup.

More generally for #1, whatever method(s) you use to find people's contact
information and connect with them.

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.

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.

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.

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.

~~~
_nothing
So true. One of my most active channels of communication is actually
Instagram's chat despite it lacking many features I prefer in a messaging
service like a desktop/browser interface and search functionality. But it's
what my friends use, more actively than Facebook even, and so it's what I use.
If you have Instagram then you already have this messenger, so it becomes a
no-brainer.

------
rolleiflex
This is what I’m working on with Aether
([https://getaether.net](https://getaether.net)). A mass-communication method
owned by no one, like email is owned by no one. It’s a modern, decentralised
Usenet.

I used to call it _‘email for mass communication’_ but it confused people,
since it’s not based on email, so I stopped calling it that. That’s the goal
though.

I also gave a talk on it at the Internet Archive last week, if you want a
quick intro in video from.
[https://archive.org/details/12120iadweb](https://archive.org/details/12120iadweb)
(My part starts at 1:13:30). If you have any questions, happy to answer.

~~~
skyfaller
"In Aether, spam prevention is accomplished by requiring proofs of work".

Now, I recognize that regular e-mail uses proof of work as a spam prevention
measure these days, so I don't want to be too harsh on a decentralized
alternative.

That said, I've watched the energy expenditures of Bitcoin etc. with alarm,
and I've become very concerned about the sustainability of anything using
proof of work if it should become popular. Fundamentally proof of work makes
people waste energy in order to accomplish tasks such as sending messages, at
a time where we need to use as little energy as possible to reduce emissions.

Have you considered sustainability at all with Aether? Have you considered any
alternatives to proof of work for dealing with spam?

~~~
drdeca
I suspect that the PoW energy costs of things like this would be negligible
compared to that for cryptocurrencies, but I haven’t justified my guess.

~~~
rolleiflex
You’re correct. Besides, proof of work in Aether is user adjustable, everyone
can choose their own threshold. No need to turn it up unless you see spam. As
you turn it up it becomes harder for other computers to pass your filters,
which will cut down on spam (or anyone who’s trying to create too many posts
for any reason).

~~~
dchyrdvh
While reading this, an idea popped up in my head about monetization. Sending a
message needs spending a PoW token that can be mined or bought. The price is
set by the recipient and can be different for different senders. Zero for
friends, a high number for potential spammers. The author, however, has a
private key that can produce PoW tokens cheaply, but still in a limited amount
to retain trust and prevent diluting everyone's share to nothing. Some
companies may want to send spam and will be happy to buy PoW tokens. Users
that suddenly start getting spam, raise the bar, as it costs them nothing.
Those companies now need more tokens and they come to you. This is inflation.
As long as SEC understands what's going on, it shouldn't have problems with
this sandbox economics.

~~~
rolleiflex
I thought about monetisation and it’s also in the talk linked but ultimately
I’ve decided to not monetise it. Instead, to make it sustainable, I’ve created
a separate app called Aether Pro at [https://aether.app](https://aether.app).
It’s a much better version of Google Groups. You would use it if you wanted
the modern features of Slack like channels, guests and integrations, but you
also want to keep email discussions as your main work tool, and not move to
chat.

By having them separate, I can make sure that the the P2P version isn’t
influenced by money-making concerns, since we have a product explicitly made
for that.

------
thulecitizen
Completely agree. For anyone who hasn’t come across it, check out the exciting
work being done by developers of the Secure Scuttlebutt protocol:

“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.”

Read more:
[https://en.wikipedia.org/wiki/Secure_Scuttlebutt](https://en.wikipedia.org/wiki/Secure_Scuttlebutt)

Join us! There is a fully functioning client, and bustling Solarpunk
community: [http://scuttlebutt.nz](http://scuttlebutt.nz)

~~~
ElFitz
I'm really worried about the total amount of data each user will end up
lugging around though.

Also, append only => no deletes, correct?

~~~
thulecitizen
Yes, no deletes. Since there is no company in the middle, the GDPR rules don't
apply to this P2P network, so it isn't an issue legally (in Europe).

This is something that will probably take some puzzling to get to a
sustainable mechanism. The strategy I've heard talked about most often is to
append metadata that marks it as 'deleted', so when things populate or
'gossip' further, it won't show up in the user interface. Instead it's labeled
as 'archived' or 'deleted', or has a link to it's replacement.

~~~
masukomi
It should be noted that while you can't delete / edit messages you _can_
delete blobs (binary attachments). They'll come back if you load a post that
references them, but that's where the majority of size comes from and it is
manageable.

Also, how much you download is related to how many people you follow, and text
doesn't take up a ton of space.

~~~
ElFitz
Sure. But where do the blobs "come from" when they "come back". Since it's
fully P2P, _someone_ has to keep them around.

As for text not taking up a ton of space. Sure. Except it's text with it's
metadata, and possibly text generated by a few hundred people.

A friend and I managed to exchange ~24k messages on Slack over the last 3
years (~4k each / year); using it like some kind of "private twitter" where we
would just post anything that might be of interest to the other.

What would it be like if I follow 300 or 1000 people doing the same, over
Secure Scuttlebutt?

\- At 1 byte per character (from what I've gathered, Unicode characters
actually take up 1 to 4 bytes) \- 140 characters / message (because Twitter
proved it's usually enough) \- messages' metadata (50 bytes?) \- 4.000
messages / user / year \- following 300 people

We'd get... 228MB / year?

That's actually way less than I expected!

------
kitd
Mentioned in a separate thread, but DeltaChat [1] offers a WhatsApp-style
messaging interface over standard email.

[1] - [https://delta.chat/en/](https://delta.chat/en/)

~~~
rapnie
Like the idea. It was discussed here:
[https://news.ycombinator.com/item?id=19216827](https://news.ycombinator.com/item?id=19216827)

------
egypturnash
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.

~~~
VvR-Ox
Matrix has bridges to solve this:
[https://matrix.org/bridges/](https://matrix.org/bridges/)

------
johnmorrison
I'm working on a sort of ancillary project which may help with this at Valyrio
[[https://valyr.io](https://valyr.io)]

Counter-intuitively, the current goal is to _centralize_ 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)

Bringing email, text, and (aspirationally) all other messaging systems into
one.

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

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)

After all, Valyrio _means Language_

I've also been working on an adjacent concept with
[[https://jwmza.com/polymath](https://jwmza.com/polymath)], 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.

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.

------
parvenu74
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).

~~~
cjslep
It's a shame you say "Mastodon" when we want to say "ActivityPub".

Federating an RDF graph is powerful.

------
jasonzemos
> messaging apps are all the same, making them easy targets for
> standardization and interoperability.

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.

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.

Matrix has failed to solve this problem. We need a new approach. What will
emerge to finally conquer this space?

~~~
johnmorrison
I feel like you're overestimating the differentiation and not accounting for
the fact that 99% of the population basically just uses the minimal subset of
features (sending plain text and images)

Two services don't need to have identical feature sets to interoperate,
because you don't need _perfect, full interoperability_ , if you can send
_most_ of your messages across platforms, that's still pretty good.

> Let me just make that last point clear: you cannot design a messaging
> protocol where one party sees emojis and the other doesn't.

Which service doesn't show emojis? Literally every mainstream mobile operating
system and desktop browser supports emojis as regular text.

~~~
jasonzemos
> the fact that 99% of the population basically just uses the minimal subset
> of features

The tendency is for people to invoke features situationally. If you are
communicating with someone who is using rich-replies there is a tendency to
also invoke that feature yourself. If people are using emojicons there is a
tendency for others to play along rather than use plaintext characters.
Feature invocation is situational and relative.

> Two services don't need to have identical feature sets to interoperate,
> because you don't need perfect, full interoperability, if you can send most
> of your messages across platforms, that's still pretty good.

This has proven to result in an unacceptable user experience throughout the
history of messaging. When a system loses social information from the
environment it is no longer an effective communication tool. Worse, it is
_dangerous_. If you send me a message and I respond to your message with some
thumbs-up emoji, and your platform doesn't support it (e.g. a text-based IRC
client) that information gets lost. You believe I have disregarded your
message. You may assume I have been rude when the opposite is true. This is
absolutely unacceptable UX.

~~~
johnmorrison
> This has proven to result in an unacceptable user experience... Worse, it is
> dangerous. If you send me a message and I respond to your message with some
> thumbs-up emoji, and your platform doesn't support it ... that information
> gets lost. You believe I have disregarded your message. You may assume I
> have been rude when the opposite is true. This is absolutely unacceptable
> UX.

This is an assumption that bad implementation is the only possible
implementation, and it is wrong.

Obviously omitting content from missing features is bad UX - but it's
absolutely not necessary to interoperate. It's easy (and should be expected)
to avoid this by simply telling the user something from a missing feature has
been sent - they can then inquire and get back the lost information / clear up
the confusion.

Furthermore if interoperability is implemented on both ends, the sender's
client should know to alert the sender before they attempt to use features
missing on the receiver's end.

None of this is a difficult issue.

------
hardwaresofton
> I see two promising and complementary paths to decentralized messaging:
> building on the new and shiny Matrix protocol, and gradually extending
> email.

COI is chat over IMAP[0], I think it's one of the best solutions I've seen in
the sapace.

[0]: [https://www.coi-dev.org/](https://www.coi-dev.org/)

------
aey
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.

------
marknadal
I talked to Twitter's CTO, Parag.

He said the move is to specifically reduce fragmentation in public
conversation.

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.

------
zzo38computer
Make using standardized and simply enough protocols, such as IRC, Message Send
Protocol, NNTP, Zephyr, etc

~~~
dmix
Like gtalk using XMPP?

~~~
zzo38computer
XMPP uses XML. IRC is simpler and can be used without any specialized
software, and was designed like that, so that you can use without specialized
software (I have used IRC on computers before installing a IRC client)

~~~
KaiserPro
typing PONG every ten minutes isn't entirely practicable

~~~
zzo38computer
I am aware, and is why I normally install a IRC client soon, but when I want
to ask something first before installing a IRC client, it helps anyways.

------
jacob019
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.

~~~
Andrew_nenakhov
As a person involved in XMPP development for over a decade, I can tell you
why.

To date, no one ever developed XMPP chat applications as a product, which can
be easily deployed and will work consistently on every platform. Client and
server developers were always disjointed, working separately from each other.
This lead to great inconsistencies in implementations of even such basic
functions like adding a contact. Also, it often happens that when a client
developers need some feature that honestly should be done by a server, a
developer still does this on a client, because it's all he has, with subpar
results.

Absent leadership from XSF also plays a role. This club now mostly cares about
bureaucracy and following a set of self-imposed rules instead of developing a
set of working standards that would allow XMPP apps to compete with the best
messaging apps out there. That's why it is unlikely for any great product to
appear under such guidance.

We're trying a different approach, maybe we'll even succeed. If so, you'll
hear about it on HN.

~~~
upofadown
>...following a set of self-imposed rules instead of developing a set of
working standards that would allow XMPP apps to compete with the best
messaging apps out there.

That is no excuse for doing embrace, extend and extinguish as your Xabber
seems to be attempting with the XMPP standard. I can't help but note that the
Xabber project has outright rejected OMEMO capability.

If you are extending XMPP in incompatible ways (as Whatsapp did) it is only
ethical to clearly state that to potential users.

~~~
Andrew_nenakhov
1\. We don't do embrace, extend and extinguish. All we do is open-source, with
products available to download, and docs fully available.

2\. We don't 'outright reject OMEMO capability'. I reject OMEMOdiots who moan
excessively because their wishes aren't satisfied on the spot.

Why are not they satisfied? Because XMPP does not have a reliable control of
message delivery, no way to remove messages from message archive, no good
group chats, no client sync protocol, no way to revoke session tokens, no way
to know which messages in archive were read, no way to add reactions to
messages, no way to do threaded conversations, and while we're building all
that we're constantly attacked by individuals who demand us drop everything we
do and urgently add OMEMO so they can feel safe (and do it at our own expense,
of course).

We'll provide some E2EE capability, but only after we are finished with
everything else that we consider more important than this.

3\. Extending XMPP in incompatible ways, I'll cover this a bit.

Do you even remotely imagine an amount of shit an XMPP client (say, a web
client with no stored history) built on 'compatible' XEPs must do to display a
telegram-like interface, with all the recent chats? How much time does it
take? Best result we could achieve in our web version with 'compatible' server
and 200 contacts is like 5 minutes. With our custom XEPs, it's currently down
to 15-20 seconds, and our goal is to trim it to 3 seconds. Does it break
anything with s2s? No. It only adds methods of how a client interacts with a
server, that's it. Does it break legacy clients? No, they still can do it the
old way, if someone is willing to wait 5 minutes.

Next, we have our group chats. They are powerful: archive search, moderation,
anonymous mode, public mode, pinned messages, replies, mentions, extremely
agile restriction/rights management. They are very easy to implement (on a
client) and provide a nice fallback compatibility for any XMPP client even
without support for them. You don't need support on participant server to use
it (not as in MIX, to say). You can chat using multiple devices, with legacy
clients alongside supporting clients, all working nicely with simple Carbons.

Documentation for all improvements is open, (it's not in english yet, but
we're getting there), implementations are open-source and distributed under
GNU licenses. No, I don't think your point about extending in incompatible
ways is valid.

Probably, the more correct way to call it is that we are forking XMPP. Like,
in git. We'll be sending XSF pull requests on every XEP we create - hopefully,
one day XSF will come to their senses and see that their platform is fading
into obscurity and irrelevance, and that to prevent it from happening they
should do something differently.

------
ravenstine
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.

~~~
buboard
thats why its best to extend email . it's already decentralized and people
don't claim it helps drug dealers. i think the worst part of centralized
services is they made police and states complacent and depend on constant
spying

~~~
deadbunny
For 99% of the population email is extremely centralized.

~~~
buboard
hm not really, thanks to corporate / institutional email silos . sure there is
gmail, yahoo , outlook ... but also a huge long tail that is not going away

------
coding123
xkcd 927, I'm not even going to link it because you know what it is.

------
timw4mail
Unfortunately, it's probably too late. Email caught on because it was the
first option, and it's become ingrained in spite of itself.

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.

That said, I would love to see a good standard for person to person chat,
especially one that doesn't rely on magic numbers.

------
sagichmal
It is astonishing to me that, after skimming the spec, anyone believes Matrix
is the future. Or ActivityPub. Or XMPP.

The future of messaging, decentralized or not, is certainly something with a
tractable protocol.

~~~
ppjet6
I agree, and this is one of the reasons I use (and contribute to) XMPP. For
the Extensibility part.

------
max_
Social media has more problems besides the need to “decentralize”

The biggest problem with social media is how it is ruining our mental health.

It’s sad that almost no one looking in to this.

------
zapf
Does Matrix allow for anon communications?

~~~
Arathorn
Yes, for better or worse.

