> go-ipfs with a few pinned files taking more than 5GB
Yeah, I don't understand the hype around IPFS when it performs so badly. After reporting the issue and having a conversation with the devs I had an impression that they are just dilettantes.
> This problem doesn't exist for JSON, because pretty much every language directly supports arrays, objects/maps and primitives
No, JSON will not map directly to a language with advanced type system (with tuples, variants, etc). Even in Elm it's recommended to write a decoder to convert incoming JSON into an internal structure. So in fact the mapping is very poor. And I see no difference in this regard: both XML and JSON is crap.
> it'll need institutional buy-in from corporations and existing tech companies. Hope there is a plan for that type of out-reach.
"Failing to plan is planning to fail".
I don't see why would corporations and existing tech companies be interested in yet another IM protocol they cannot control, especially in the era of total silos and FAANGs. Doesn't sound like a solid plan to me at all.
I can absolutely imagine why existing tech companies would be interested if the protocol became so popular that they'd be stupid to ignore it and start from scratch with their own protocol, like XMPP was at one point.
I'd be more interested in seeing how they plan on preventing the whole Embrace, Extend, Extinguish thing pretty much every company pulled with their initially XMPP based chat apps that gained market share, turning them into back into closed silos.
Preventing the embrace, extend, extinguish manoeuvre that WhatsApp, Facebook Messenger, Google Talk, even Apple Push Notifications did with XMPP is indeed a tough one.
The best solutions we have right now are:
* Ensure there's enough value in the wider network (e.g. available services, integrations, bridges, public chatrooms) that you'd be taking a massive step backwards not to federate.
* Try to build the protocol to be capable enough that vendors don't feel that they have to fork and close it in order to make it do what they want.
I think it's mainly the first one that will make the difference. If there hadn't been such great content out there on the public internet, we might still be on AOL & Compuserve today.
The second point will only address the vendors that are actually interested in federation, not the ones that want to close down their silo. XMPP fifteen years ago is a prime example.
Regarding the first point, I'm not sure it will be ever possible to pull this off. The proprietary IM silos are many orders of magnitude larger than IRC, XMPP and Matrix taken together. You are doing a good job with promoting Matrix to nerds, and there will be _some_ value in being able to directly contact the French government (provided that they will allow federation from the public network, which I have a hard time imagining).
I think the only viable route today is to push for legislation (e.g. in the EU, in the context of ePrivacy / GDPR) that will force silo providers to open up their silos and to offer interop by means of standardized protocols. But even in this improbable case they will probably rather create their own rubber-stamped standards (remember Office Open XML) than follow what is already out there.
> I'm not sure about that. If the main matrix server disappeared today that'd be problematic
This ^^
Currently a large amount of users (I'm told around a half, but I'm not sure) have matrix.org as their home server. So Matrix is effectively building a power-law network with all its drawbacks: when the "power node" of the network goes down the whole network falls apart.
To be fair, this is somewhat inevitable in the initial stages, before a reasonable spec is released. Many people, like me, are just "sitting on the fence" and test-driving Matrix via their matrix.org server, until there are reasonable assurances that deploying our own Matrix server will come without too much hassle.
After Synapse 1.0 is released (sometimes next month, IIRC), I'm definitely deploying my own homeserver, and federating it with the rest of the world.
FWIW, I've been running Synapse since 0.20 or so (for at least 2 years now), and there has never been a breaking change in the protocol as far as I'm aware. I had to read release notes at some points to get the upgrade to work, but it was mostly Python-library-related stuff IIRC.
Well they are making one big instance nothing else. Also unfortunately it means that you can't possibly federate with matrix.org. I've been running small otherwise perfectly functioning instance for few years for my circle/work as slack alternative on small vps. One time i did the amazing mistake of turning on federation with matrix.org. It immediately killed my servers performance especially when i joined some popular channel. The channels probably have more messages than my whole server combined. And it works the other way too - matrix.org is like sponge sucking other instances.
I guess this is the real problem for me - i would love to federate but i can't possibly police or enforce what servers/channels are small enough that my users can join them.
This isn’t anything to do with the size of the matrix.org server; just that synapse needs to be more resource efficient and we need to limit the sizes of rooms small servers try to join. we are doing both.
Also, what custom protocol are you talking about? XMPP works on top of TCP/TLS (or Websocket). Those are the IETF standards. In fact XMPP doesn't require an additional layer of HTTP at all.
> with lightweight mobile clients
Where are they? Anything even remotely comparable battery-wise with Conversations (an XMPP client)?
Not to mention that Matrix has a terrible server implementation which requires several GB of RAM just to join matrix.org room.
> It also has a lot built into the core protocol, where as to get XMPP to do anything useful you will need to use a lot of extensions (and ensure the server and all clients support them).
I fail to see how having a monolith core versus splitted specs has to do anything with code written to support that. Of course, initially every implementation will strive to implement full core (that was in XMPP in 2000s), but when the core evolves you have absolutely no guarantee that every developer will implement all new parts of the core. How is that addressed in Matrix?
Well that's quite easy, since hosting a server is a resource hog, most people are still on matrix.org, which gives it a special status in the ecosystem (even more special than jabber.org has been in the early 2000s fox XMPP). This allows them to "move fast and break stuff" on short notice (a few months), to bring the protocol forward and force people to upgrade. In the federated XMPP ecosystem, they essentially have to come to a community consensus between developers, servers operators and all other relevant actors to write a manifesto or a new spec that says "stop using $thing at $date".
In my opinion matrix, while being open-source, federated and easy to write clients for, is still a half-locked platform because essentially the matrix.org server is "too big to fail", and the matrix team is the only one who can e.g. offer consultancy over the protocol because nobody else can have a long-term view of its future evolutions (of course the matrix people are nice, and you can discuss with them, but that is still not a standards body).
> is still a half-locked platform... but that is still not a standards body
Exactly. That's why I always stress the importance of the IETF. The whole point of the IETF is that you cooperate with people, deal with opposite opinions, accept criticism, come to agreement, develop a compromise and produce a high quality absurdly documented standard. In Matrix bubble (and any others, see cryptocurrency or p2p community for example) they are the only one who makes the decision. They don't care on other opinions. If you disagree with them you're asked to stop "fighting", "focus on interaction", "understand their goals" and other meaningless stuff like "let the best standard wins" (when in reality the whole point of the standard is to cooperate). Formally speaking they try to substitute a "standard document" with an "open document" and people kinda swallow this because they don't see the difference.
> In Matrix bubble (and any others, see cryptocurrency or p2p community for example) they are the only one who makes the decision. They don't care on other opinions.
> You can see our governance model at https://github.com/matrix-org/matrix-doc/blob/matthew/msc177.... and see that we do everything we can to ensure that the wider community can contribute to the spec and steer it in the right direction... And fwiw, we'd be perfectly happy to contribute the spec to IETF or W3C or whoever once it's relatively stable, just like XMPP did.
I'm not a lawyer to read such documents. Just "contribute" your core to the IETF, prove me wrong.
> 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.
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/.
> 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.
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.
Chill dude. No need to get all butthurt. If you don't like Matrix, don't use it. The rest of us will also have make the same choice for ourselves and time will tell whether Matrix has a unifying or dividing effect on chat.
I, for one, have been playing with Matrix and other protocols for awhile and have been impressed not only by the Matrix team's vision, but also by their ability to deliver on it consistently (though sometimes slower than all of us would like). The whole ecosystem has become much more polished over the past year (and the new Riot client is sweet!)
Problem is, "team". It's not really decentralized at this moment, just software from the singular vendor. Of course, it moves faster than a really distributed protocol (in all senses of this word).
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.
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.
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."
Yeah, I don't understand the hype around IPFS when it performs so badly. After reporting the issue and having a conversation with the devs I had an impression that they are just dilettantes.