One of the people on the Interledger Foundation's board of directors (Chris Larsen) is the Chairperson of Ripple. 2 of the 3 people listed under the Interledger Foundation's "Our People" are affiliated with Mozilla.[1]
I feel that it was a mistake for representatives of Mozilla and these other organizations to endorse the Interledger Foundation. Coinbase has been restricting XRP from being bought, sold, or traded ever since the SEC sued Ripple Labs just over a year ago.[2]
And yet none of those corporations has displaced email, despite the fact that it has become a universal cyberattack channel, with a stagnant UX that doesn't address most real-world use cases for email!
I saw a need for a safer, better, decentralized protocol for email, so I drafted one (TMTP) and implemented client & server. More at:
> I saw a need for a safer, better, decentralized protocol for email, so I drafted one (TMTP) and implemented client & server.
We definitely do, and then we need big, heavy corporate advocates for this new protocol. That second part is the rub. I would argue that every company embraced email early only because proprietary formats that locked customers into a platform weren't yet a thing. Now that they are, it is so much harder to propose that we all "just get along" with shared protocols.
Your work looks very interesting and I applaud you for taking this on. I will take a look. I am not entirely pessimistic. Have you thought about building a company around it?
I have sketched a plan for a venture, for which I'd need co-founders (e.g. mobile app code & UX expertise) -- feel free to reach out via Twitter @mnmnotmail (link above).
Those big corporate advocates necessary for the success of a new email protocol are fortunately not the major email hosting players! See the mnm FAQ #2 for a plausible adoption path.
The success of a wide variety of messaging and discussion apps demonstrates that the network effects of email are not necessarily a high barrier.
What these products have lacked, which email has, is an open protocol. (XMPP had early success, but never addressed the main use cases of email, and has major design flaws.)
A handful of credible alternative protocols are now in development:
Email was designed in the 1970s & 80s for an Internet whose population and topology have dramatically changed since.
We no longer need a messaging system that allows anyone, claiming any identity (i.e. "real name"), to send you any content, without limits. Federation was necessary for the topology of the early Internet, but today it is a drawback --
making email by far the most effective method to initiate cyberattacks.
Real open protocols are ones not coming from a single vendor / not controlled by a single entity. XMPP and email are open protocols, Matrix, Mattermost and RocketChat are not.
Speaking as Matrix project lead: we'd love to submit an RFC (or W3C proposal) once Matrix has sufficiently stabilised. Right now it's moving very fast though (e.g. we're about to totally change the sync API so that it's O(1) rather than O(N) with number of conversations).
In terms of contributions to the Matrix spec; from a quick eyeball at https://spec.matrix.org/unstable/proposals/, there are 95 different authors, of which 31 work for Element (the company formed by the original team who created Matrix). Or to slice it another way, there are 498 spec change proposals there, of which 358 were written by folks at Element (so 70%). Meanwhile the protocol itself is defined by the independent and neutral Matrix.org Foundation non-profit (https://matrix.org/foundation).
In other words, accusations that Matrix is entirely defined or controlled by Element are untrue - by the time we created Element there was already significant contribution from the wider community, and these days there are loads of other individuals and companies like Beeper, Famedly and even Ericsson contributing to the spec.
Edit: oh, and Rocket.chat is adopting Matrix too, which refutes the GP comment even more...
We all know that 'independent matrix foundation' will never oppose the will of the leading vendor. Don't tell me about how you agree to everything in your wonderful community, tell me how you resolve conflicts?
You and your company has all the leverage and no sane independent developer will invest in your protocol because he'll always have to play the catch up game.
An example of resolving conflicts is something like MSC2962 (https://github.com/matrix-org/matrix-doc/pull/2962) and MSC3216 (https://github.com/matrix-org/matrix-doc/pull/3216). Two proposals to solve the same problem, different ways. The first one was written by me; the second one was written by joepie91, who's a completely independent community member. Doesn't get much more of a direct conflict than this.
So, to resolve it, the spec core team (which is a mix of element employees and community members) went through the two proposals to compare them and concluded that joepie91's approach is better. So we're about to kill off MSC2962 and merge MSC3216 into the spec instead.
Please stop with all the disinformation - it'd be way more constructive to invest your energy into improving XMPP than trying to make Matrix out to be evil.
What you cite is not a conflict. It is a mild disagreement about the development of new features. A real conflict is when you have different entities with different implementations, and diverging views on how to develop the protocol, and the stake for the losing party is to abandon their investment in their existing implementation and starting over from scratch.
However, I already have the answer on how you plan to deal with such conflicts, you've said it yourself [1]. I'll quote:
> The idea on Matrix is that you say "Hi, I talk Matrix CS API 0.4" and be done with it - and you end up with much more social pressure to keep up to date with the current latest spec, because otherwise you are simply falling behind
If we say it in a less courteous manner, "Once we introduce changes, your independent implementation will be cut off from our network, and if you'll need several more months to implement changes, well, tough luck".
You see, I'm not saying Matrix is evil. It's a rather developed product, just like Mattermost or Flock. But a federated protocol it is not. Please stop advertising as such, and I'll have nothing to say about it.
The primary problem for email at this point is that it's a highly effective cyberattack channel, because it allows anyone, claiming any identity, to send you any content, without limits. This cannot be "fixed" as it's the intended function.
No one was working on an alternative that addresses this problem, so I drafted & implemented "TMTP". It also addresses a variety of other common email problems.
Great story of "market-based" engineering management & collaboration, where different teams could trade resources (in multiple categories) with other teams to optimize each component while staying in-bounds with the mission requirements.
https://webmonetization.org
https://grantfortheweb.org