[zinid]

> i'd argue that the Matrix.org Foundation is just as 'recognized' as the XMPP Standards Foundation :)

Recognized by whom? The XSF has standardized their core in IETF. Is there something similar for Matrix.org Foundation?

> trying to solve existing problems using new approaches is how things evolve.

What new approaches? You're just recreating federated IM network using different wire format. How on earth is it innovative or new? Using HTTP+JSON instead of TCP+XML is something new? Bridging to other IM networks is something innovative?

> Matrix is an entirely different type of technology to IRC or XMPP. It's more similar to NNTP or Git than either IRC or XMPP.

I've heard this argument many times already, but the truth is that XMPP formally speaking is de juro an "XML routing protocol", but both XMPP and Matrix de facto are being used largely as IM protocols.

> For better or worse, trying to solve existing problems using new approaches is how things evolve.

Since you invented nothing new, you evolve nothing.

[Arathorn]

> Recognized by whom?

The foundations responsible for the protocols look to be pretty similar to me (both non-profit orgs), and would be equally recognized as such by the general public. Obviously XSF contributed XMPP to the IETF after 10 years or so, and perhaps we'll end up contributing Matrix to IETF or W3C or whoever too if they'll have it.

> How on earth is it innovative or new? > Since you invented nothing new, you evolve nothing.

sigh - I wonder if the XMPP community would spend less time constantly complaining about Matrix if they understood what it was :/

The innovative bit of Matrix is that it's a replicated database of objects (events), similar to Git, but designed for syncing conversation history around in realtime. The events for a given room get replicated over all the participating nodes. There is no central server responsible for coordinating the room; instead all the participating ones do so equally. It's impossible to communicate with someone on a different node without effectively giving them a lazy-loaded HA replica of the room. Architecturally this is about as opposite of MUC (or MIX or FMUC or DMUC or whatever) as I can think of.

It's NOTHING to do with HTTP+JSON versus TCP+XML - Matrix can use whatever transport and encoding floats your boat. For instance, at FOSDEM we showed Matrix running over CoAP+CBOR to try to spell this out: https://fosdem.org/2019/schedule/event/matrix/.

[dflock]

Your description of the Matrix protocol reminded me of this, currently in development by the Atom/xray team: https://github.com/atom/xray/tree/master/memo_core

> Memo – Real-time collaboration for Git

> On its own, Git can only synchronize changes between clones of a repository after the changes are committed, which forces an asynchronous collaboration workflow. A repository may be replicated across several machines, but the working copies on each of these machines are completely independent of one another.

> Memo's goal is to extend Git to allow a single working copy to be replicated across multiple machines. Memo uses conflict-free replicated data types (CRDTs) to record all uncommitted changes for a working copy, allowing changes to be synchronized in real time across multiple replicas as they are actively edited. Memo also maintains an operation-based record of all changes, augmenting Git's commit graph with the fine-grained edit history behind each commit.

They intend to use this in their WIP xray editor - a possible future replacement for the Atom editor. Meno will be used to provide real-time multi-user collaboration for the editor, like Teletype for Atom: https://teletype.atom.io/

I occurred to me, that if your got repo contained chat history, then your edit would then be a chat client, with your chat history version and stored by git.

[stevenicr]

Been watching Matrix for a long while now, and just now I see this: > "innovative bit of Matrix is that it's a replicated database of objects (events), similar to Git, but designed for syncing conversation history around in realtime."

and think, this is basically blockchain workings right? IF we had only created a client that worked on iOs only, could store and send chat coins and log votes for each group, this could be presented in press releases as a new blockchain chat and get all kinds of posts and maybe money thrown at it.

kidding aside - I have more faith in Matrix moving forward than any similar projects at the moment, and I don't see that changing soon - so I hope more can be done to polish clients and make sure bridges and other features are well done.

As soon as moderation tools are enhanced I'll begin to use it on several sites.

I'd love to see some bubbles of related issues that need love and have some people put some estimated time and money on each bubble - maybe we could crowdsource some code for some bubbles and money for others or something -

I feel there are many groups of people who want / need different things in order to increase adoption, and I feel for the folks coders / maintainers who are trying to extinguish all the fires at once.

I put a few hundred into bug bounty like thing to get some features added to rocket chat so we could use it.. then found the amount of other bugs left un worked at the time meant it was not feasible for our usage any time soon. Hopefully with the funding and such of Matrix it can evolve on multiple levels at once and become a solid framework with many clients and ux options.

A bridge for COI and delta chat or any others. I'd love a client that bridges with email address and has one click to keybase auth or pgp and such - and puts things into a timeline / fbook feed like view.. not for me, but for others.. group friends, display on phones and web.. seems these things could be close to reality.

[petre]

Except XMPP already has several mature client and server implementations since it was around for longer.

[fock]

So I want: - multiuser chat (persistent) - voice-calls (let's have them 1on1) - file-transfer - concurrent clients

Which mature clients and servers should I choose from, implementing all this (basic) stuff?

[SamWhited]

Let's assume this hypothetical client doesn't exist (I'm not actually sure if it does or not): are you suggesting it's better to start over and create an entirely new chat protocol instead of just writing a client that has the features you want? These features do all exist within existing open protocols, and clients do exist that implement some of these features (and probably all, but I'm not sure). So I don't see any reason to start over.

[Natales]

I've been using [Wire](https://wire.com/en/) very happily for some time now. Great interface, top quality audio/video, good chat, persistent, very secure, open source. I'm surprised it hasn't received more mentions.

[petre]

https://en.wikipedia.org/wiki/Jingle_(protocol)#Clients_supp...

[fock]

Yeah. Did you actually try calling someone with any 2 of these clients?

[Andrew_nenakhov]

All things you need will be covered by Xabber in second half of 2019, on ios, web, android.

[fock]

promised for 6 years... and remember this thing is commercial, not OS...: "Nonsense comments from clueless commentors. It's not our problem if you didn't update on feb14. Also, it's our app and we do whatever we want, please uninstall Xabber and use something else. You had no voice or rights here besides those that have been generously given by us. Now they are revoked."