Hacker News new | past | comments | ask | show | jobs | submit login
Matrix 1.0 – Are We Ready Yet? (matrix.org)
332 points by jaywink 37 days ago | hide | past | web | favorite | 200 comments



I had a pretty positive view of Matrix until I came across this post and the follow up responses from the developer behind an unofficial Matrix server implementation: https://news.ycombinator.com/item?id=19365968

I'd say tread carefully given their apparent hostility towards competing server implementations, which is literally the only thing that makes the protocol meaningfully "federated" to begin with.

This part in particular was deeply disturbing:

> I can quote the CEO of new vector in an argument we had about the insecurities of the protocol and what needs to be done to fix them where he said "good luck talking to your own federation." That reveals a lot.

Not exactly the kind of attitude I'd like to see from the stewards of an "open" protocol.


Matrix isn't really hostile to competing server implementations. If it were, then they wouldn't have spent a long time and a lot of effort to finalize the Server-to-Server spec r0.1, which anyone can implement [1].

And just to add my personal anecdote, Matthew (CEO of New Vector, co-founder of Matrix.org) is present quite often in the Matrix HQ chat room, and willing to field questions from anyone. Perhaps with slightly less willingness when people start such accusations.

Also, to address some of the technical issues, I think what they're talking about as "The blocks have hashes but their implementation does not check the hash" in the DAG is being fixed with the next (v3) room version [2]. Again, this development is all being done in public: see e.g. https://github.com/matrix-org/matrix-doc/pull/1659 for the v3 room proposal.

[1]: https://matrix.org/blog/2019/02/04/matrix-at-fosdem-2019/ [2]: https://matrix.org/docs/spec/rooms/v3.html


To quote one of the follow up comments from the author:

> If you go to matrix.org and look at the list of about a dozen or so servers: you will find that none of them actually work except the reference implementation, and maybe sometimes Construct. Even thus, the phrase "able to build" is questionable. I have spent months reverse-engineering their software and its interactions before, and after, it was at all documented in this so-called standard (by the way, it's just documentation of their software -- errata and all (and rather poor)).

> Construct server is the single survivor out of the ones listed and even more who have attempted and given up early which we don't know about. That being said, it is still incomplete.

A spec that "Anyone can implement" doesn't have much value if it's so bad/incomplete that in practice nobody else is actually able to create a complete working implementation of it as the post claims.

And regardless of what they're planning on doing about any security issue, there's never a good reason for a discussion of a potential security issue in an "open" protocol to end in "good luck talking to your own federation." That's the behavior I'm pointing to that's hostile to competing server implementations.

Of course, the quote could be taken out of context, or straight up made up. But until proven otherwise, I'm willing to give the benefit of the doubt to the small independent developer who seems to genuinely care enough about the openness of the protocol to build their own server implementation.


The "good luck talking to your own federation" comment is being taken out of context. I can't find it in my history (so I assume it's been paraphrased), plus from memory I think it was the final line in an argument over how some bit of the protocol should be implemented. After failing to convince the guy that our approach was better than his proposal, I gave up with "okay, you can always do it your way, but you'll only be speaking to yourself" or something similar. I'm not sure this is evidence of being hostile to alternative servers, but if anything an encouragement for people to experiment with variations on the spec if they think they can do better :|

See https://news.ycombinator.com/item?id=19418111 for a detailed response to these accusations.


It'd be great if there were usable non-Riot clients that fully supported end to end cryptography. At this point Signal has better alternative clients in Pyre.chat and Signal-Weechat than Matrix has, as the existing alternative clients are almost all MVPs missing major features like e2e.

The lack of a simple, common library is a real sticking point. Each client & bot shouldn't have to implement the baseline network protocol and then build e2e atop it, rather the clients should be focused on what to do with the messages after receiving them, how to display them, etc.

I say this as a daily non-Matrix.org user of Riot, the functionality of the Riot ecosystem on its own is good, but I'd be hard pressed to port my own Signal bots to Matrix, let alone build a featureful client in a performant toolkit (eg: Not Electron) for Matrix today.

There isn't a viable ecosystem outside Riot/Synapse currently, which makes it feel like Matrix is just a self-hosted Slack/Hipchat solution with just Riot as usable clients. IMO there needs to be diversity in the Matrix ecosystem just like the Fediverse has with Mastodon, Pleroma, PeerTube, PixelFed, NextCloud, Rustodon, etc all inter-operating in a sane, functional manner.


So, other clients with fully working E2E encryption include: Seaglass, Weechat, Pattle and nheko (although it needs to implement attachments, but they is easy). The weechat and nheko implementations are independent implementations (ie not the same as the Riot ones).

We are starting work this week on closing the E2E gap for all the rest.


I don't think Pattle has e2ee support, from what I can see on my phone. While it is built on the Matrix Android SDK which has e2ee support, the app itself doesn't seem to use that support yet.


Oh neat. Is the plan to write a proxy sitting between client and server and decrypting/encrypting all events so any client can be used in e2ee rooms?


precisely. should have news about it later this week :)


There's weechat-matrix[1] which supports E2EE and the accompanying python library, nio[2].

[1]: https://github.com/poljar/weechat-matrix/

[2]: https://github.com/poljar/matrix-nio/


Good idea. A library written in Rust and compiled to WASM for Riot would be a good fit.


You're right, we need to do better, and we have started doing so under a fork of the protocol that will respect its user's privacy: The Grid - Come talk to us at #thegrid:libremonde.org


(Full disclosure - I'm contracted by New Vector to work on their integration services, but the below experiences are about my open source work which is unfunded and unrelated to my day job)

I wanted to chime in as another developer in the server area. I've recently been working on a service that sits atop of an existing homeserver (like Synapse) to handle outgoing federation in .NET rather than Python (which has proven to give quite an nice performance boost). The project implements it's own federation and signing code.

So far I've had to do almost no special casing around Synapse and followed the new S2S spec without issues, which has all been done in the open. The special casing I did have to do was brought before the team, judged a Synapse bug and will be fixed in an upcoming update.

I don't have any evidence to point to whether the spec can be used to write a complete homeserver implementation, but everything so far has been done painlessly following the docs online. I believe that I could, with enough time.

The project is developed by myself and another, and we've experienced no hostility from the team when asking questions about the protocol or the above bug. Quite the contrary, they were quick to help and the project has been promoted by matrix.org every week in the news blog posts.

On the project itself, we hope one day to branch out from working on services that sit on top, to being a standalone homeserver (which should progress naturally. I don't foresee any spec related problems with doing this from reading the spec and chatting to folks in the community.

So I felt it would be worth sharing my experiences as another server developer, albeit one that hasn't gotten as far in their journey yet.


The server-to-server specification was only formally released on February 5 of this year. Before that, it was certainly necessary to do reverse-engineering of synapse in order to build a HS, but it no longer is. The lack of server implementations just over a month after the release of the spec isn't good evidence of a bad spec. I strongly disagree with Jason's (who has been openly hostile to most of the matrix community including me) characterization of the spec in its current form.

Disclosure: I like matrix and have hacked on a few matrix-related projects as a hobby activity (Jason would refer to this as buying into Matthew's (the CEO of New Vector, the company primarily driving matrix) personal cult). That's it.


As the author of mxhsd [1] and Gridepo [2], I can sadly confirm Jason's claims that it is STILL necessary to reverse engineer to talk to the existing federation.

Synapse doesn't follow the spec, which is a fact I'm experiencing every day. But more to that, there is no desire from its developers to ever comply with the spec, rather than changing the spec on a whim.

And that are the reasons why making a HS is not possible: endless moving target.

[1]: https://github.com/kamax-matrix/mxhsd [2]: https://gitlab.com/kamax-io/grid/gridepo


if anyone's curious about the unspecific complaints here, it transpires that the actual complaint is synapse had a bug where it some endpoints were called with a trailing slash when the spec said it shouldn't have one... it got fixed in https://github.com/matrix-org/synapse/pull/4840 and https://github.com/matrix-org/synapse/pull/4935.


At least from my perspective (I've never implemented the spec), I wouldn't call it just documentation [1]. Sure, there are likely some holes, but overall it seems like they've put a pretty good-faith effort into making it detailed enough for someone to implement.

I feel like the difficulty comes mainly from the breadth/size of the spec. Which is a major issue (the Matrix.org team's own alternative server, Dendrite, has been slow to progress as well), but ultimately I'm not sure what they can really do about that considering one of their key tenets is to contain all the functionality out-of-the-box, so to speak (no extensions like XMPP).

[1]: https://matrix.org/docs/spec/server_server/latest.html


I am the author of the now-frozen mxhsd project [1] and its resurected version, Gridepo [2]. I have contributed several times to the specification, reported issues for the past two years and still, to this day, I can confirm that it is not possible to implement a Matrix server with the current specification that can talk to the reference implementation.

Most fundamental problem: synapse doesn't sign the events like the spec tell us to do it, making every event invalid. Whatever you sent that is spec compliant will be refused by synapse.

So talking "synapse" is possible. Talking Matrix and be able to federate with the ecosystem is not. I wish people would not blindly believe what a for-profit is saying, especially one that is in full control of the said protocol, and start checking for themselves.

[1]: https://github.com/kamax-matrix/mxhsd [2]: https://gitlab.com/kamax-io/grid/gridepo


I'm not aware of a bug in how synapse signs events, and whilst it's possible there's a bug there, we can't fix stuff which we're unaware of which hasn't been disclosed. (Max would probably claim he can't disclose because he's been banned from our Github for consistently being obstructive; unfortunately this is a case in point).

Edit: he might be talking about https://github.com/matrix-org/synapse/issues/4787? Except that was fixed a month ago...

In terms of "don't blindly believe what a for-profit is saying, especially one that is in full control of the said protocol", I'd agree, were it true. However:

* These days the protocol is controlled entirely by the non-profit Matrix Foundation.

* The majority (3 out of 5) of the Foundation's directors have zero affiliation to New Vector, the company that the core Matrix set up to try to keep the project funded.

* The governance of the foundation & protocol is entirely open, as per https://github.com/matrix-org/matrix-doc/blob/matthew/msc177...

* We're announcing the final board once formally appointed; due in the next few weeks.

Meanwhile, it's also true to say that you shouldn't believe the skewed perspective of a disgruntled ex-community member with a chip on their shoulder, who is trying to plug their hostile fork: https://news.ycombinator.com/item?id=19473694.


I'm the original creator of Ruma, another homeserver implementation, and our project has received nothing but support and appreciation from the Matrix team. It's true that Synapse is the only homeserver that is in a "finished" state, but that has more to do with Matrix being young, the spec still needing work (although it's come a long way recently), and the lack of time and resources to complete such a big project if it's not your full time job.


Is the Ruma project still alive? I liked your website and your goals but last I checked there was very little activity.


Yes, it's alive. We've been on a long hiatus while we wait for the dust to settle with async code in the Rust ecosystem. This is the GitHub issue that best tracks our ongoing blockers: https://github.com/ruma/ruma/issues/189


As the author of one frozen homeserver [1] and an hybrid implementation [2], with various work made all across the spec, I'm not shy to say synapse is the only homeserver because it talks its own dialect of the spec, not because there wasn't attempts to build something else.

[1]: https://github.com/kamax-matrix/mxhsd [2]: https://gitlab.com/kamax-io/grid/gridepo


I'm one of the people in that thread and I'm unconvinced by Jason's insinuations regarding the hostility of the New Vector team. From everything I've seen, interoperability and federation is extremely important for New Vector. The fact that Matrix is a rather innovative and semi-research project has to be taken into account.

For instance, here[1] is the github thread on verifying event hashes which he refers to in that HN thread. From what I can see, he notes some of his (insightful!) thoughts on the matter, nothing but a civil discussion ensues, with parts of his suggestions getting implemented and others being worked on.

[1]: https://github.com/matrix-org/synapse/issues/1252


And here is three documents/issues that all related to synapse breaking systems in the federation, despite repeated extensive technical feedback.

And to this day, despite people that keep on reporting about the issue, nothing is done to actually solve the problem.

https://github.com/matrix-org/matrix-doc/issues/1194 https://github.com/matrix-org/synapse/issues/4540 https://github.com/matrix-org/matrix-doc/pull/1915

If interoperability and federation is important, why push changes that break those, and do nothing for >6 months?


fwiw, the linked MSC https://github.com/matrix-org/matrix-doc/pull/1915 solves the problem, is merged, and is implemented in https://github.com/matrix-org/synapse/pull/4982.

Yes, it would have been great to have done this sooner, but unfortunately fixing a bug which only impacts deactivating accounts when using custom identity servers took a while to get to the top of the todo list.


I think it's easy for bystanders to mistake hostility towards the developer of construct as hostility towards the project or the specific implementation without knowing the full context, however this is not the case.

The developer is without doubt a brilliant individual, however also extremely toxic. Not in the Linus sense, but in the Terry A Davis sense.

If anything, I think the matrix team has been too reasonable with him. He actually agreed with that himself, making fun of the team for not having the integrity to ban him out of sympathy for his situation and wanting to avoid the optics of banning a developer of an alternative server.

I have a lot of sympathy him as it sounds like he has a very serious substance abuse issue. I really really hope that he can beat the problems he faces, and I'm sure he will be accepted by the community again if he does. I understand that he is not fully under control of his situation but until he is, I don't think he should be tolerated when his presence is so hurtful to his victims and the community as a whole.

Here's some fun highlights I've experience first hand for context:

- spamming rooms with BSDM porn

- spamming rooms with links to his implementation

- hurling sexist abuse at a female matrix team member

- hurling sexually abusive language and rape threats at people

- numerous other drug-fueled breakdowns and caps locks tirades

- sockpuppeting and circumventing bans

- attempting to blackmail the team with his exploits

- deliberately bricking rooms


I think the situation is not that matrix.org is hostile to outside developers but that they are working on something new and rapidly changing and other implementations aren't able to keep up until the protocol changes slow down and the docs get better.


It seems like a few folks have been burned by the failure to put the spec before the implementation.

Another example: Kamax provides mxisd[1], the only federated identity server (the official identity server is/was controlled by vector, and doesnt openly federate). They had to give up on mxhsd[2], their home server implementation due to spec inadequacies, and ended up forking the spec into Grid[3]

[1] https://github.com/kamax-matrix/mxisd [2] https://github.com/kamax-matrix/mxhsd [3] https://gitlab.com/kamax-io/grid/gridepo


Matrix has always deliberately put implementation before formalising the spec, because there's no point in speccing things which haven't first been tested in the wild. This is also partially influenced by observing that many XMPP XEPs seem to have lacked a proven implementation at the point of being specced, contributing to the fragmentation of the standard.

Now, the reason that we didn't formalise the federation spec until very recently (Jan 2019 - https://matrix.org/blog/2019/02/04/matrix-at-fosdem-2019/) is because the implementation in the wild was showing problems which we wanted to resolve first. Now, this took ages to do, mainly because the team got mired in technical debt in Synapse and keeping the matrix.org server running, whilst trying to support the overall featureset (E2E etc) needed for Matrix to be successful. But we made it in the end. Meanwhile, it's true that server implementors got bitten by the lack of formal spec. The Ruma project for instance went on hiatus until a stable spec was released. Meanwhile unfortunately the mxhsd project lost patience and forked.

In an ideal world we'd have been able to move faster on releasing the stable federation spec, but the reality is that Matrix is a lot more than the federation API (although server implementors obviously focus particularly on it): we've put a lot of work into the CS API, E2E encryption, AS API, bridges, bots, reference clients etc too. History will tell if in the long term we got the prioritisation right.

Meanwhile, the federation API should now be sufficiently specced for server implementors to be able to successfully implement it - see https://matrix.org/docs/spec/server_server/r0.1.1.html if you're interested.


Still can't implement to this day.


I am not surprised at this and I am not sure why the Construct developer was either. Protocols like this during the initial growth phase have a ton of churn on the backend and because of that, reluctance to finalize any spec -- it's understood to be a moving standard. So presumably this person knew the risks.


> Not exactly the kind of attitude I'd like to see from the stewards of an "open" protocol.

It depends on what exactly the complainant was proposing to change in the protocol.

There are no details in the link you provided about what was insecure about the protocol at that time, not to mention the proposed fixes. Is there another link for that?

> Not exactly the kind of attitude I'd like to see from the stewards of an "open" protocol.

Are you talking about the development process that led of the 1.0 protocol, or the spec itself?


I think you're letting some rando's accusations color your perception of the project too much.


I would be interested in knowing whether anyone else has confirmed these accusations or created a writeup as to why the protocol is insecure.


It also has very questionable choices towards respect of Privacy: https://github.com/matrix-org/synapse/issues/4540


I can confirm. One of the write-ups I did: https://gist.github.com/maxidorius/b25769f1a89c8860b928babe7...


this write-up boils down to saying that servers that don't uphold server ACLs (server-bans) will leak messages from banned servers.

it's a feature, not a bug; if you want to deploy the nuclear option of a server-ban in a room, you also have to ban any other servers which don't know what a server-ban is.


I'm the project lead for Matrix (and CEO of New Vector, the company which hires most of the core Matrix team) and can try to clarify this.

1. We don't have any hostility to alternative server implementations; it would be utterly idiotic to sabotage the project by doing so. Instead, we promote them, even when they're written by people who for whatever reason have issues with the project. For instance, if you look at https://matrix.org/blog/category/general/this-week-in-matrix... you can see us publishing almost weekly updates on Construct (the server written by the guy who is levelling the accusations here). Meanwhile, Construct appears to work well enough to talk to the rest of Matrix in practice.

2. Yup, there have been some security issues pre-1.0 in Matrix around federation, particularly around state resets (thinkos in the state merge resolution algorithm), event ID collision, incorrectly trusting potentially malicious DAG depth parameters, and issues around the perspectives logic. As far as we're aware, these have all been fixed now, or will be once everyone has migrated from perspectives to real TLS, as per the original article - hence us making a big noise about it with AreWeReadyYet.com. Most of the gory details are at: https://github.com/matrix-org/matrix-doc/issues/1442, https://github.com/matrix-org/matrix-doc/pull/1659, https://github.com/matrix-org/matrix-doc/issues/1229 and https://github.com/matrix-org/matrix-doc/pull/1711 respectively. You can also see me talking through these issues one by one on the main stage at FOSDEM, starting around https://youtu.be/C2eE7rCUKlE?t=2035.

3. I can't remember the precise context where I said "good luck talking to your own federation", but I suspect it was the result of a disagreement over how federation should be designed - probably over whether DAG depth parameters should be calculated locally or proposed remotely and then validated. We chose one solution, there was a lengthy disagreement, my eventual response on giving up on the argument was "okay, if you want to do it the other way, good luck with that" or words to that effect.

For context, the guy levelling the accusations here is also responsible for maliciously exploiting the security issues on discovering them (e.g. https://matrix.org/blog/2018/06/14/security-update-synapse-0...). He is also banned from our github and the core-team chatrooms on Matrix after exhibiting pretty much every flavour of obnoxious and destructive behaviour, culminating with ad hominems against me and most of the individuals on the core team, illustrating his points with hardcore porn, and asking how we're going to compensate him for not launching further exploits. He's also filled up the network with sockpuppet accounts to spam his project (despite us, for better or worse, already promoting it on the weekly blog), and I'd assume he's also seeding sockpuppets on HN too.

So, TL;DR: whilst it's true that pre-1.0 we had some security issues around federation, we believe they are now fixed (or will be, once we've upgraded all the rooms to 1.0). Meanwhile, be aware that the complaints are coming from a deeply disingenuous and malicious source.


Thank you for providing your side of the story. While I can no longer edit my post to point to this, I have upvoted this post to hopefully bring some visibility to it, and encourage others to do the same.

Until someone can provide a chat log of what was actually said in that conversation that led up to that comment, it's still going to be difficult for any outside observer to make up their own mind on whether or not those words were indeed taken out of context to the degree that you suggest. But I can appreciate that it could be frustrating to deal with someone who behaves as you claim, even if his intentions might be to keep the protocol open and secure.


Matrix is a fantastic project. As the technology matures and becomes more useful, I hope there will be a large push to formalize the organization and bring in other stakeholders. As I'm sure you know, Matrix will not be able to get off the ground by itself, it'll need institutional buy-in from corporations and existing tech companies. Hope there is a plan for that type of out-reach.


Totally agreed. https://github.com/matrix-org/matrix-doc/blob/matthew/msc177... is the core of the plan.


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


Thanks for building Matrix. It’s a great product / standard / protocol


Thank you for continuing your FOSS work despite the attacks and for taking the high ground / mostly maintaining civility from your side (even keeping up with updates to Construct)!


I find it strange to suggest that he is using sockpuppet accounts on HN without any proof. You may as well be using sockpuppet accounts to promote Matrix. It is also really suspicious to attack someone that has spent a significant amount of time on your project.


Here is a typical sockpuppet: https://news.ycombinator.com/item?id=19081596 (which matches the @senora_acero:tedomum.net puppet which was being used on Matrix around the same time)

We do not use sockpuppets to promote Matrix, and I don't see the link between pointing out someone who does as somehow meaning "we may as well be using sockpuppet accounts too"; it's a false equivalence if ever there was one. :|

And I'm not sure that calling out the unpleasant behaviour here is 'attacking someone who has spent a significant amount of time on the project' - but thankfully enough other people have independently pointed out the reality of the situation on this thread (e.g. https://news.ycombinator.com/item?id=19422064).


Thanks for working on Matrix!


Damaging if true :/


I'm not very much into chat apps and protocols, but isn't it possible to just revive XMPP? Ten years ago we used Adium and Pidgin, and federated chat seemed like a solved problem. I understand XMPP with its extensions and use of XML fragments might be complex, but it sounds like matrix or another new protocol isn't easier. In a way, those willing to invest time into F/OSS chat apps have done the best they could with XMPP, and creating a new community around a protocol for no good reasons seems like a wasteful thing to do. XMPP folks shouldn't stop using it just because of Google's kiss of death.


Why are people so attached to XMPP?

There was no entity preventing XMPP from thriving, if the community really wanted XMPP, we would have had XMPP everywhere.

But honestly, as someone who ran and tried to use XMPP for many years, the entire protocol was an unmaintained divided mess. And the XEPs didn't help, they felt like hacky workarounds to keep an old protocol up-to-date with the modern needs.

Matrix feels very consistent, specially in the client side. I have all the modern features one could have wanted (E2E encryption, video and audio calls, file sharing, proper synchronization across multiple devices, etc) working out-of-the-box across all my devices. This was almost impossible to achieve with the XMPP clients existent nowadays.


Weren't facebook messenger and google talk based on xmpp? I know that at least they were compatible, but in the end they removed that. Trying to force people on their own client


This is the problem - if you have a large user base there is simply no business incentive for federation. It is so much easier (and cheaper) to just build your own silo without worrying about interoperability. Plus you have the ability to monetize a closed system through ads, data mining, etc. There are so many advantages.

And people don't complain (much) because, for chat especially, they have had years of conditioning that leads them to accept (and expect) that communication with their online contacts depends on installing multiple apps from multiple vendors and sharing their data with those vendors on whatever terms the vendors decide.


And don't forget about spam. Spam becomes a problem when your system gets bigger.


Google Talk was, Facebook just had an xmpp gateway.

Google killed the xmpp momentum by gettimg scared of Facebook around 2010. and adopting the 'walled garden' approach.


Of course, app that implements it's only server API would be consistent with itself. You see, Matrix isn't mature enough to have XMPP's problems, such problems must be deserved first.

And seeing how fixated matrix zealots on JSON superiority over XML as a format, I don't think Matrix will ever mature to a point to have problems faced by real federated protocol with multiple implementations of both clients and servers.



What does JSON vs XML have with facing problems related to maturity?


I have very same impression. XMPP is basing on XML where parsing is order of magniture more complex than JSON. In lot of ways very similar to SOAP mess where you could not comunicate across different software because each of them supportet different set of SOAP extensions and good luck with communicating with web client.


> XMPP is basing on XML where parsing is order of magniture more complex than JSON

The last time I heard, there weren’t two JSON parsers that actually accepted the same language, so I’m not sure there’s an existence proof to back this statement up. :-)

XML is more complicated, but if we want to compare apples to apples, it’s only due to the white space sensitivity. (dtd, schema, etc don’t have analogous technologies in the json world, and at least xpath is a standard, unlike jq).


> XML where parsing is order of magniture more complex than JSON

You're supposed to use an off-the-shelf XML/JSON parser, not write it yourself.


Even if you don't parse it yourself, XMLs data model is usually more of a chore to consume.


XML/SGML is highly appropriate for representing rich text, though, which is the purpose of chat apps/logs. Using JSON you'd have to invent ad-hoc markup on top of JSON, loosing any advantage it may have.


Nobody uses rich text formatting, and even if they did, the message body is only a small fraction of the total protocol content.


> Using JSON you'd have to invent ad-hoc markup on top of JSON

That's basically a description of ActivityPub that wraps HTML in JSON!


Will activitypub let me do:

  <body> markdown text </body>
And ship some js to convert to html?


No, each server has their own rules what and how will they present content. Usually they accept limited subset of HTML and filter out everything else.


Where does "order of magnitude" come from? In my experience, XML parsing is about three times slower than JSON and around two or three times the size. For most complex applications, this is not a show-stopper, because the bottleneck is elsewhere.

XML was a hype in 1999, when XMPP has been invented and JSON was a hype fifteen years later. When people invent protocols they just use what is trendy in the moment.


Sure, XMPP has problems, but ZERO of them comes from using XML. Thinking that using JSON will help solve the real problems any federated protocol would face is very naive and will lead to more than a few unpleasant discoveries down the road.


fwiw, nobody on the Matrix team (or that I know in the community) thinks that JSON is somehow fundamentally superior to XML - it’s just a data encoding. More recently we’ve been using CBOR over JSON for instance. Anyone who claims Matrix is about “using JSON rather than XML” to do the same thing is catastrophically missing the point.


https://twitter.com/joepie91/status/1102888957510107136?s=19

Check this active member of the community. Also folks on this very page claim how xml consumes much more resources


XML is not popular because of JavaScript developers.

Coming from .NET, I do not care using JSON or XML, because the APIs System.Xml.Linq, Newtonsoft.Json and the upcoming System.Text.Json are a joy to use. I think the lack of good native representation of XML in JavaScript made it a unwanted choice.

Regards SOAP I tend to agree to you. Beyond the Basic profile it was a hassle to interop.


>XML is not popular because of JavaScript developers.

This could not be more false. JavaScript is built around the DOM. You can parse XML with DOMParser and query it with the same interfaces that you build your UI with. The X in AJAX is XML. The "good native representation" of XML in JavaScript is the very core data structure that JavaScript was designed to interact with.

XML is not popular because it's complex. Escaping is hard. XML bombs make it unusable in its raw form.

Fundamentally, XML doesn't give you data structures that look like the ones you use in your application logic. You have to transform your data into something that makes sense in XML, then transform it back. With JSON (and other formats) the data structures that you're given are present in almost every programming language. You don't need to model your data differently for transit or storage than you do in your application logic.


Good arguments but using DOM Api in JavaScript needs many more lines than JSON parsing and access. jQuery made HTML access bearable for a simple reason: DOM sucks :)

Average Joe Dev does not reach the impedance mismatch you mention correctly.


The DOM interface is roughly the same in almost every language. The JSON interface is almost always simpler. It's no mystery why JSON is more popular. XML never died because of JavaScript developers.


XML is extremely popular with the JS crowd, they just don't know they're using it ;) JSX (React's template language extension to JavaScript) stands for "JavaScript XML" [1], and there was E4X as an official ECMA spec for XML literals before that (though admittedly not as cool as React is, doesn't have vdom and update events, components for MVC, etc). And JavaScript was indeed invented for DOM manipulation, it's just that the DOM API simply sucks.

The whole XML hate thing is symptomatical for the staged this-vs-that discussion we endure in today's forums.

I guess there are those document representation schemes that everybody hates on, and those that nobody uses ;)

[1]: https://en.wikipedia.org/wiki/React_(JavaScript_library)#JSX


E4X was far more powerful than JSX. JSX is just a nice syntax for object construction. E4X could additionally query XML (think XPath but different) not to mention support for XML namespaces, etc.

I agree with the rest though.


I agree.


Plenty of us are still working on XMPP, and there are thousands of XMPP servers and many more users on the network.

It's true that since the original Jabber project began in 1999 there was a vision of giving users freedom of software and service, yet that vision is still nowhere near reality in 2019. But we are still an active community and still work towards that vision. XMPP is not dead.

Unfortunately Pidgin and Adium were two of the most popular clients for XMPP, and their development (in Adium's case) and XMPP development (in Pidgin's case) has almost completely stalled, which is unfortunate. Alternative XMPP projects are still very actively developed.

The XMPP community recently began holding sprints, where a bunch of us get together in real life to focus on specific topics, such as UX and interop. It's been great!


For those searching a very simple to use XMPP client:

Quicksy.im: https://play.google.com/store/apps/details?id=im.quicksy.cli...

It is a fork (same developers) of the popular Conversations client, which does not bother you with provider selection and such kind of technical decisions. If you just want to try XMPP or invite someone, it is probably the easiest way to start with.


> and there are thousands of XMPP servers

proof please. Checked the top 3-4 xmpp servers last summer and they almost died.

IRC looks 1000000x more active.


I'm not sure how you are judging "activity". I suspect you are talking about chatrooms. In this sense, yes, IRC probably would look pretty active - it is built around the concept of channels, the majority of which tend to be public. XMPP is far more diverse, rooms are spread across multiple servers with no central way to list them. A project that aims to spider the network and help find rooms is at: https://search.jabber.network/ (note that this doesn't currently index jabber.org, traditionally one of the larger hosts, due to a technical glitch I believe).

My mention of thousands of servers is not related to public chatrooms however. There are a bunch of public servers which you can register accounts on, but many more private ones (that federate) run by businesses and individuals and other organisations. A quick shodan search reports 55,760 unique IP addresses speaking XMPP publicly on port 5269 (the default federation port): https://www.shodan.io/search?query=port%3A5269+http%3A%2F%2F...


> I'm not sure how you are judging "activity"

OK, "324 Kuketz-Blog (kuketzblog@rooms.dismail.de)" seems like most popular jabber channel, right?

Here's the #freenode top in this moment:

#linux 2000

#python 1950

#archlinux 1860

And it's ONLY first 3 top channels.

So, the facts matters.


> the facts matters.

Indeed. Could you also provide the number of 1:1 chats and private groupchats running on freenode, then? Both of these are way more popular use cases for XMPP than public rooms.


XMPP is different from Matrix.

On Matrix practically everyone is matrix.org. The other public servers I tried are relatively slow and suffer hickups when joining rooms.

On XMPP, many people run servers in their companies, projects, or homes. Which are the "top 3-4 XMPP servers"? I probably do not even know them.

But you are right: XMPP is used mainly for IM, i.e. one-to-one dialogues or smaller, non-public chatrooms. I'm not aware of any huge, public chatrooms in XMPP, and for that I'm on IRC — via a gateway from XMPP called biboumi.


We have almost finished a pretty decent XMPP to Matrix bridge, if you are attached to XMPP (https://github.com/matrix-org/matrix-bifrost with a bridge running at bridge.xmpp.matrix.org). However, Matrix has a fundamentally different architecture: replicating conversation history over a full mesh of participating nodes, rather than passing messages via a star topology, and we opted to build that as a fresh stack rather than creating a mutant hybrid of XMPP.


I'm so happy this bridge exists. I'm using it to join rooms of some open-source projects that opted to use Matrix, and I know of some people on Matrix using it to join similar rooms on XMPP.

Meanwhile both sides get to use free and open communication protocols :)


> isn't it possible to just revive XMPP?

Please no. XMPP has adapted over time to support various chat and instant messaging features that we today take for granted. These adaptions come in the form of Extensions[1]. A year ago I spent about two hours with a geek friend to configure something that resembles what we get from any other instant messenger today. That's not acceptable to the outside world.

Meanwhile, Matrix just worked. Granted, UX involved with the key management associated with E2EE was not what it should have been. But, that has largely been fixed in v1.0.

Funny thing, Matrix is still struggling (like every other federated network) to explain the concept of federation. People may have grasped email, but for some reason it seems hard to translate that knowledge to other federated technologies.

To suggest that we should just go back to XMPP seems like insanity to me. Matrix stands a chance. It's freaking wonderful!

[1] https://xmpp.org/extensions/


> Funny thing, Matrix is still struggling (like every other federated network) to explain the concept of federation.

Are there any data on how federated is Matrix? I mean number of users on different servers.

From my experience most of people are on matrix.org server and even if they run their own homeservers the identity server is still vector.im.


From memory, about 50% of the users visible in Matrix are on the matrix.org server, which is one of about 30K deployments total that we're aware of, directly or indirectly. This will likely change in the near future as the French deployment expands, which should dwarf the matrix.org server. In the medium/long term, we'd like to at least disable registration on the matrix.org server if not turn it off entirely (once decentralised accounts land).

The identity server is used ONLY for mapping email addresses and phone numbers to matrix IDs, and is strictly optional, so I'm not sure it counts as centralisation. We are also hoping to remove it entirely from the mix in future (switching to storing 3pid->mxid mappings per room instead).


Thanks for your post. I've been wondering about federation distribution in various protocols since seeing similar stats for Mastodon [0]. Having federated protocol where vast majority of users still use one server is sub-optimal IMHO (this is not only for Matrix).

[0]: https://rosenzweig.io/blog/the-federation-fallacy.html

As for identity server, it was just surprising for me (from user's perspective) that when my friends ran a homeserver I still needed a lot of config on Riot for Android to connect to (homeserver URL, identity server URL). I've seen some well-known URIs [1] but sadly Riot for Android did not query them for my e-mail.

[1]: https://f-droid.org/.well-known/matrix/client

Thanks for your work on Matrix, glad that you guys are pushing the boundaries of UX of open-source software!


the mobile clients lagged a bit on .well-known support, but it landed over the last few weeks: https://github.com/matrix-org/matrix-ios-sdk/pull/644 and https://github.com/matrix-org/matrix-android-sdk/pull/436. Hopefully this should improve things a bunch.

For 'the federation fallacy' thing: our approach is to first decentralise accounts (so you can transparently move them between servers), at which we can turn off matrix.org (or at least disable signup) assuming there are enough other quality public servers available to incorporate the resulting diaspora. In the longer term, we want to enable P2P in Matrix so you don't even need a server at all if you don't want it, at which point the federation fallacy argument entirely falls apart :)

and thanks for the thanks! :)


Doing the same for XMPP: http://upload.zinid.ru/xep-eax-cir.html

Let's compete.


The problem of XMPP is just lack of good clients on some platforms, most notably for iOS. For Android there is an excellent Conversations.im client [0] that I've successfully use with my non-technical family and friends. (There is also Quicksy [1] that uses phone numbers for onboarding but it's XMPP all the way down). Conversations doesn't use a lot of battery (anecdata but it's 1% on my phone) and just works.

[0]: https://conversations.im/

[1]: https://quicksy.im/

As for servers ejabberd is successfully used from small deployments to big MMORPGs. The team is extremely focused on performance and from what they say XML isn't actually a big performance problem. Prosody, another server, is in my opinion also high quality, even though it's developed in free time (AFAIK).

The "myriad of extensions" is mostly solved problem due to Compliance Suites and automated testers [2] (think SSLLabs) that people use to get their servers in shape.

[2]: https://compliance.conversations.im/

For the record I've used Matrix for work too and it's not bad, the clients are decent (I've used web client), but it's not a revolution especially if one's contacts can use Conversations, that, in my opinion, is just very good.


I have to agree and disagree. I agree, that XMPP clients are not very good. And horrible on iOS (and MacOSX). I disagree, that Matrix has good clients. Riot is an OK web client, but too slow and too confusing for my taste. And native desktop clients, like Nheko or Quaternion, are not yet very useful. XMPP has many more mature clients at the moment.


In case of iOS/macOS - there are: * BeagleIM by Tigase (https://beagle.im/) for macOS * Tigase Messenger for iOS (https://itunes.apple.com/us/app/tigase-messenger/id115351683...)


I am completely on your side. Matrix did improve upon the state of XMPP in 2012. But XMPP improved too and therefore the problems we had 2012 are not relevant anymore today.

There is just one big problem with XMPP nowadays: Very few people are interested in XMPP as everybody wants to learn the new shit aka Matrix. And actually, that is the one thing I blame the Matrix devs for. Instead of improving an existing open IETF standard they decided to invent something new and split the community.

Technologically, Matrix is neither better nor worse than XMPP, as far as I can tell, but splitting the community wasn't such a brilliant idea.


Well it is better in some regards, such as each server being an independent store of events of all rooms in which its users are participating.


Nobody buried XMPP. Write good server and client, comparable with proprietary protocols by features and it might work.


Nice, if XMPP works for you, but I hope do not use Pidgin or Adium nowadays. They still work, but AFAIK, they do not support newer XMPP features, such as encryption using OMEMO, HTTP upload, message archive management, etc.

There are nice, modern XMPP clients like Conversations on Android, Gajim on Linux and Windows, etc. that do support the latest XMPP features and are much more pleasant to use today.


Matrix is the perfect example of xkcd 927 - https://xkcd.com/927/

They built something like XMPP, just a bit different. What they got is more fragmentation in the space of free messaging. None of the justifications they have how their approach is different justifies the costs of additional fragmentation they create.

This is super frustrating, people don't seem to have an understanding what the costs of incompatibilities are. You can also observe pretty much the same at the micro level of within XMPP and encryption standards, where everyone seems to think the solution is yet another encryption standard instead of having just one.


I'd counter and suggest that the super frustrating thing is XMPP zealots saying "oh my god how dare you try to create a different protocol". With this mentality, nothing would evolve and we'd be stuck on svn rather than git...

To reiterate once again, the things which Matrix tries to do differently to XMPP include:

* Be a replicated conversation database for realtime conversations, more like usenet (NNTP) if anything than IRC or XMPP or SMTP (or, alternatively, an open standard alternative to Slack, which is also focused all around syncing conversation rather than passing messages).

* All conversations are group conversations. There are no such thing as 1:1s; just a room with 2 people in it.

* To be clear: there are no APIs to send a message from one user to another in Matrix. Instead, you sync a message to a room, which updates its conversation history, and the history update is then synced to all the other servers (and users) in the room.

* Have a single monolithic versioned protocol (https://matrix.org/docs/spec) rather than a finely granular cloud of XEPs which may or may not be compatible or best practices or implemented at any given point.

* Build in E2E encryption from the outset.

* Implementation before formalising spec

* A "there is not more than one way to do it" mentality on developing the spec (i.e. a python rather than a perl approach)

Meanwhile, we have spent a lot of time writing decent bridges to ensure that we do not fragment communication with chat systems - be they open or closed. For instance, right now, I see 41 people participating in Matrix HQ from XMPP, ~200 from IRC, ~40 from discord, ~20 from telegram, 5 from slack, and the rest (~3000, including idlers) from elsewhere in Matrix.


> Have a single monolithic versioned protocol rather than a finely granular cloud of XEPs which may or may not be compatible or best practices or implemented at any given point.

I totally get where you came from, the fragmentation within the XMPP universe is annoying. The problem is that a monolithic spec doesn't solve this issue at all. It's not like code magically updates itself when you update a monolithic spec. The problem is missing manpower on the implementation side, and ditching modularity from the spec just makes it harder to cope with this in graceful ways.


I'm not sure that the problem is missing manpower on the implementation side - it's more that it's hard to know as a developer which current blend of XEPs is the recommended combination and which might have the most chance of working between a given client & server (and server & client) combo.

Things like the XMPP compliance suite XEPs have helped a bit with this, but looking at the XEP list and trying to work out which XEPs you should be using on a given day is still daunting - as well as trying to track which clients are most likely to be supporting them.

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 (rather than happening to chose not to implement some XEPs).

It boils down to a question of governance & social dynamics rather than anything related to writing code (magically or otherwise).


> I'm not sure that the problem is missing manpower on the implementation side

If it isn't, why are there so many red crosses on https://matrix.org/docs/projects/clients-matrix and so many servers that aren't even capable of talking to matrix.org?


> why are there so many red crosses on https://matrix.org/docs/projects/clients-matrix

Because the world is littered with unfinished projects? The key thing being that the authors KNOW very concretely that the project is unfinished, and there is a big red X next to the feature in question.

> so many servers that aren't even capable of talking to matrix.org?

Because we only released the first stable release of our federation API a month ago?


And admins will update their deployments instantly? Because of monolithic core? Interesting...


Yes, instantly. Or else they'll lose connectivity with central matrix server and 80% of users.


> I'd counter and suggest that the super frustrating thing is XMPP zealots saying "oh my god how dare you try to create a different protocol".

I see no such consensus within the XMPP community, but yes personally I agree with those zealots. My interest in federation is making it possible to communicate with anyone just like I can call anyone by phone. Inventing an incompatible protocol obviously won't help with this goal, even if you ignore the issue of splitting up scarce manpower and assume bridges can act as a partial workaround (at least for geeks who can cope with their limitations).

> With this mentality, nothing would evolve and we'd be stuck on svn rather than git...

Comparing XMPP to SVN and Matrix to Git just reads like trolling to me. The obvious difference is that XMPP is highly extensible while SVN is not at all. So the discussion is not about whether or not to evolve, the question is whether evolving federated IM required starting from scratch, i.e. whether the advantages are worth the resulting fragmentation. And I just fail to see the problem in using/extending the XMPP spec to replicate your DAG.


> we'd be stuck on svn rather than git...

Don’t you mean CVS?


I used to be a big fan of XMPP, but I've also come to the conclusion that it failed.

Technically, too long the clients just weren't good enough. First the desktop ones, then the mobile ones. Not losing messages if you were logged in with multiple clients was hard.

Matrix (after waiting a little) now just works. Yes, maybe I just don't have any energy left to fight on this front, but for a huge chunk of people I communicate with it has finally replaced IRC. Finally as in reuniting the people who had stopped and also didn't want Slack or Discord. And never got on the XMPP train.

Now we'd just need more native desktop clients, but so far Riot is good enough for me.


I still use pidgin for my "eve online chats" and it continues to do all the things I need pretty effectively. I've had a couple of slacks and a couple of discords over the years and they really haven't improved on many axes at all.


I sincerely hope someone took the Telegram client code and add Matrix protocol to it.

Really, Telegram client is open source and the app is more usable than any other bloatware on the market.


Agreed, the Telegram desktop client is super fast.

EDIT: Someone seems to already have done this:

https://matrix.org/docs/projects/client/nheko.html


I think nheko is a clone of the telegram UI rather a fork of it.

I agree it'd be awesome if someone took the actual Telegram FOSS clients and ripped out the TG backend and replaced it with Matrix (a bit like the Delta.chat folks did, but replacing with email)


No need to replace it, just add dual protocol support :D


I hear about Matrix a lot, but I have no idea why I should use it. Can anyone explain why I should use Matrix?


Basically, because there's no alternative for a truly open, striving for security messenger software. It's imperfect, but, honestly, Matrix/Riot is as good as it gets for now. Both server and client software are open-source, and it is designed to be federated network, meaning if you don't trust their e2e encryption or whatever, you can just roll up your own server and use it to communicate with somebody. And it's pretty decent in terms of features already implemented, it's easy to write helper-bots, it has clients for all major OS. And, sadly, almost everyone still uses Telegram/Whatsapp instead, which is, I believe the main reason you (and everyone else asking) should start using it even if you don't feel like you have to, because none of your friends are currently on it.


I'm still very partial (obviously) to the Introduction to Matrix guide we wrote as part of Ruma's documentation: https://www.ruma.io/docs/matrix/


It's xmpp reborn (or IRC if you're that way), with a modern feature set, so the thing you use if you want Slack but without SlackCo.


- no vendor lock-in

- decentralized

- encrypted/private/secure

- open-source

It's like irc or email for private decentralized encrypted chat.


Matrix isn't really decentralized. It's federated.


In Matrix the conversations really are decentralised, not federated, over the servers - they are replicated over the nodes just as you would with git or a blockchain. Meanwhile we’re actively working on running servers clientside, at which point it becomes fully p2p as well as decentralised if you want that.


Right, I meant federated in that each user is expected to connect to a home server, not to "the network". Running the server locally on the user's device definitely changes the picture.


> we’re actively working on running servers clientside, at which point it becomes fully p2p as well as decentralised if you want that.

Where can I read more about this?


Federation is a form of decentralization.


Also you can host a completely isolated matrix server, that does not connect to "the Matrix network"


For example, every client could choose to run its own server to have a perfectly decentralized network. Federation is a feature that allows for greater than 1:1 mapping between clients and servers.


No, decentralization is invented alongside the blockchain and nothing without a blockchain is decentralized. :)


No, you don't need a blockchain for decentralization. Also, you don't need a blockchain[0].

[0]: https://thomaslarock.com/2018/11/no-you-dont-need-a-blockcha...


I believe you missed a joke.


Gosh, I did miss it actually, my bad. Mild autism, I suppose, I often take words literally, esp. when there are no facial/voice tone cues.


I think a useful way of looking at it is that the rooms are decentralized, i.e. not owned by a single server, but the user accounts are (for now).


> but the user accounts are (for now)

aren't? If so can you explain?


yes, I meant they aren't


The home page gives no clue as to what "Matrix" is. It seems to be yet another "federation" system. Is this worth any attention?


> It seems to be yet another "federation" system. Is this worth any attention?

In the current internet environment of walled gardens and a siloed and decimated internet, any federation system is worthy of attention.


Given Facebook, Microsoft, and Google have shown they're against federated messaging the more pertinent question for me is "can it work?

Will anyone other than geeks switch from Facebook, et al..

You'd probably need some legislation to force those running large communication platforms to open their protocols and allow federation before there can be significant progress. I really can't see their being political will for that at present.


> Given Facebook, Microsoft, and Google have shown they're against federated messaging the more pertinent question for me is "can it work?

You're probably right, the legacy companies won't buy-in without a fight, but I see two avenues of success.

- New companies: If a federated messaging system existed five years ago, Slack may have chosen to run on an open standard rather than build its own.

- Large corporates: they may want the self-hosting, security customizeation, and lack of vendor lock-in of an open standard. For example, I know that Goldman Sachs has built their own in-house messaging service (crazy, I know). They may be a good candidate to switch to an open standard.


The lack of ability for their chat to interface with others is probably a considerable measure of control over information flow, which I imagine is good for Goldman Sachs.


> The lack of ability for their chat to interface with others is probably a considerable measure of control over information flow, which I imagine is good for Goldman Sachs.

A federated system can still be locked down, and made to be inoperable with other services. If you wanted to make an email service that didn't speak to other email services, you would still probably start with the email standard and make changes to lock it down rather than creating a new email service from scratch.

Likewise, a Goldman Sachs (or similar company) that wanted a locked down messaging service would likely consider an open platform that they could modify and lock down rather than using a commercial one (like slack) or rolling their own (which is extremely expensive).


Matrix itself can be used for a few things. The main one being instant messaging but it can be used for a bunch of different things. At its core its a way for clients to exchange json messages in a way that doesn't require everyone to be on the same server.

People have built other stuff like blogs on top of it and you could use it for stuff like IoT devices.

It also comes with end to end encryption.


Yes, a good place to start reading: https://www.ruma.io/docs/matrix/


It's the standard problem of software designed by software engineers: they have a problem turning off their geek-brain to see how a potential user views it.

Matrix folks:

* if a teenager cannot understand what it is in 10 seconds of looking at it or if a teenager does not download the client after understanding what it is your product is hopelessly broken

* if a 30 year old cannot understand what it is in 20 seconds or upon understanding does not immediately install that software, your product is hopelessly broken

* if a 50 year who has facebook just looks at your website funny, then your product is hopelessly broken.


That's why you point users to Riot.im instead...

Seriously, you don't expose end users to platform-level infrastructure. Matrix audience is software engineers, so it's good that matrix.org is dedicated to explain itself to developers. The tools you build on top of it, those are the ones you show to end users.


Oh so the users also need to know that when they hear Matrix, it means people are talking about Riot!

Compare:

https://telegram.org/

with

https://matrix.org/blog/home/

Where is a link to the app store for Riot? Where is the link to the website? Why do I get a table of "yes/no/kinda" when I click on "Clients"?

This project will will become another IRC -- cute but irrelevant.


IRC has active users.

I have, or had, a Disapora account. Nobody to talk to. I have an OpenID. No service I use still accepts it. The home page of Matrix has to provide a convincing argument that Matrix is worth more attention than Mastodon or GNU Social.


What's wrong with the link " Try Matrix Now / Get Chatting ", right below "Welcome to Matrix / Learn more"?

https://matrix.org/docs/projects/try-matrix-now.html


No.

But I mean that in a nice way. Here's why...

My understanding (limited, to be fair), is that a large percentage (most?) users have a matrix.org account instead of an account somewhere else. By definition, this is not federation. Certainly riot.im users get that by default.

Let's look at a different example - email. What if the inventors of email created email.org and created accounts on it. Everyone would also ask "where's the federation?". What ultimately made email really useful (note the use of the word "really"), was the ability to reach people outside your organization. So you could email back and forth to stanford.edu, ibm.com, usna.mil, and even aol.com.

What is difficult (today), is for me to go to google or yahoo, or microsoft, or stanford and get an account. Yes, there is this [0] but only one provider is on the page. Further, according to that provider [1] it's only a sub-domain, not my domain. It's a start, but also a version behind from the looks of things, so therefore not truly ready.

If any of this is wrong, and I can sign up with a reliable hosting to have server.mydomain.com, I'd sign up. I don't have the time to manage updates & server security, and a reliable provider would allow me to run my own instance.

[0] - https://matrix.org/docs/projects/hosting [1] - https://www.modular.im/


modular does support custom dns (at no extra charge) - eg webchat.kde.org is hosted on it.

there are a bunch of public servers you can sign up on rather than matrix.org - see https://www.hello-matrix.net/public_servers.php.

our hope is to turn off matrix.org sooner or later (or at least disable signups) to prevent these misconceptions.


Thank you!

As a side-note, someone should make that link a bit more visible on the matrix.org site.


When is the kickass Riot UI remaster that y'all showed off at Web3 coming to town?



I don't want to knock the hard work the Riot developers have put into their application, but I just don't understand: why does 'modern' web design seem to require wasting so much white space? Looking at the screenshot on that blog post, the actual chat transcript is somewhere in the middle of the screen (sandwiched between giant sidebars on either side).

Compare to irssi (or any other console IRC program), which uses just about the entire width of the terminal to print chat messages.

Is this really just a side-effect of developers all having large, high-DPI monitors, making the white space look smaller to them? Because on my tiny little Chromebook, no more than 50% of the screen width is actually used to display chat messages.


Why would you want messages to span the entire screen?

https://ux.stackexchange.com/questions/108801/what-is-the-be...


Because: window managers!

http://i.imgur.com/4K0pa6m.jpg

That said...I must confess that irssi uses a non-trivial amount of margin space as well!


I think some developers either only have one window open at a time, or always use fullscreen/maximized windows. There are so many things that are just difficult to use when windows are tiled to fit ~4 things on one monitor.


I use Wire which has a similar problem to Riot. That is now 2 different workspaces just for "chatting" (they take up an entire workspace to be usable, because it wastes space, not good, IMO), then there is another for IRC on which I can also have a browser anyway because the terminal is only 80x24. I stopped using Riot because of it, and I might stop using Wire, too. :/ I hope they will fix it in Wire though, for example, by making the friend list collapsible or something.


The user list on the right can be closed, and the channel list on the left can be collapsed.


What if your window doesn't span the entire screen? It's a frustrating and common flaw in so many modern websites and apps that they simply do not work unless the app is fullscreen on a widescreen monitor.

For example Discord is borderline unusable if it is one of two windows side-by-side on my laptop, and completely unusable if you have three. This can't even be an unusual case for people on UNIX derivatives using tiling window managers - Windows has had functionality to tile windows like this since 7. Whatever happened to responsive design? See Telegram desktop client for an example of how it should work - the layout actually changes as you resize the window.


Discord isn't meant to be used side by side,it's default usecase is joining a channel and continuously talking while doing something else(mostly gaming).

not being able to snap the window seems to be a conscious choice on their part


I assure you there are lots of people who don't use it that way. It probably depends on what circle you end up in on it. There are text-based communities on there related to all sorts of topics. The Rust community was even considering using it as a default communication channel at one point I believe.


> So keep your paragraph width between 50 and 70 characters.

Yes, I have a terminal (xterm) with irssi running, that terminal is 80x24, and give or take the timestamps, it is indeed between 50 and 70 characters.

Whereas Wire and Riot takes up the entire screen as a single window.


Too late to edit, but I confess that TFA refutes what I wrote!

We’ve also made usability improvements pretty much across the board, including making the left and right panels resizable [...]


Only Riot Web though :(

Riot (both web and mobile) desperately needs to make room and user search more obvious. Everyone I give Riot to has issues finding me and my channels. I get around this by asking their usernames and sending invites to the right channels.


Have you checked recently? The mobile version has gone blue for me.


Yes, I in fact just installed it. They changed the text in the "search bar" present in the homescreen, which is a great improvement (it now says "filter rooms"). However this feature is only useful for really heavy users with tons of rooms, yet it's displayed front and center while the global search option which is fundamental for onboarding is still hidden.

The full redesign has been postponed because they are rewriting the whole program: https://github.com/vector-im/riotX-android But this issue I'm complaining about is also present on the redesigned Riot Web.

Edit: sorry, I think I'm wrong. The current mobile version seems to already be the redesign though it looks mostly the same to me: https://medium.com/@RiotChat/riot-mobile-update-brand-new-ri... I think it still needs a lot of work.


the recent mobile update is just a cosmetic redesign (getting rid of all the green!)

You're completely right that RiotX is where the overall usability fixes are happening, including ones which would solve your problem here. Good news is that RiotX is evolving fast though - we're putting all our resources into it rather than Riot/Android, and then the same UX will be ported over to Riot/iOS. We're aiming to get a daily-usable RiotX into the app stores in the next 1-2 months. N.B. that the UX will change substantially from the current prototype at https://matrix.org/jenkins/job/RiotXAndroidDevelop/.


Right now is it generally recommended to use Riot or is RiotX stable/good enough? Also is RiotX like a beta channel, so when it's considered complete/stable will an update effectively replace Riot with RiotX for all current users?


RiotX is alpha right now, but should be usable day-to-day in a month or so. Once it has parity with Riot we'll replace Riot with it.


Thanks for the clarification. Those are great news!


Oh awesome, thanks man.


It's already released, as of a few weeks ago.


I think Matrix is brilliant. I run a synapse home server and updating/maintaining it has been a breeze.

That said, on a couple of occasions (once a while ago, and once with Riot 1.0) I've tried migrating from my free Slack org to Matrix and it still falls short for the feature set I want.

Specifically, I want a community whose members can create rooms for that community that are automatically visible and private to the community. Currently the community features in Riot make that a difficult task.

If anyone has had success doing this I'd be more than happy to hear about it!


I made a seq2seq chatbot with Matrix/Riot, the python-api implementation (https://github.com/matrix-org/matrix-python-sdk) and https://github.com/tensorlayer/seq2seq-chatbot:

Here it is: https://www.youtube.com/watch?v=rCggOcKZn-c

(There's a fun interaction at 25:52)


That triple nested if is horrible though…


Off-topic, but Whatsapp provides E2E for groups upto 256. Matrix can apparently provide E2E for bigger groups. Did they do scaling better?


yup. we layer megolm on top of olm (double ratchet) to scale to ~1000 or further.


Looks like every device still has to establish an olm channel with every other device in the group. Does that scale?


you're right that that's the slow bit (typically about 50ms to set up each channel, so across 1000 devices that's 5s to establish the initial mesh), but the important thing is that having established the channels, they are only used to sync key data for the megolm layer which sits on top. megolm keys typically rotate every 100 messages or every day (whichever comes first), and this uses the existing olm channels. In turn, the olm channels themselves only resetup when conversation changes direction (or if they stall).

https://blog.jabberhead.tk/2019/03/10/a-look-at-matrix-orgs-... is quite a good overview of this (from the XMPP perspective!), as is https://www.uhoreg.ca/blog/20170910-2110 (from the Matrix perspective).


OK, you want XMPP. But without the many XEPs, something with a monolithic specification. And you like to use the latest trendy hipster stuff, like JSON over HTTP instead of XML. Then you get:

Monolithic, Awefully Trendy Re-Implementation of XMPP (M.A.T.R.I.X.)

Which is also a dedication to XMPP, which has been invented in 1999, the year of the Matrix film.


I don't know about Matrix, but Riot, the default frontend, certainly isn't: https://github.com/vector-im/riot-web/issues/7062 Copy/paste is a pretty fundamental feature.


I was the original reporter of linked bug. In fairness to Riot team, it appears to be an upstream bug with their rte: https://github.com/ianstormtaylor/slate/issues/2612


This only applies to text with embedded formatting, like bold and italic


It doesn't have to have any explicit formatting, it just needs to be rich text. If you try pasting anything from a web browser or WYSIWYG editor it will break.


How does Matrix's encryption compare to Signal? I've heard they are supposed to be very similar but I'm doubtful



I'm tempted to spin up a Matrix homeserver.

Anyone know if it runs well on Docker via træfik?



Thanks for that!


Doesn't run well per say compared to optimized applications, but it runs.


FWIW I found installation/upgrade via apt to work very well.


Can't Check my federation, only seeing the square next to the textfield animating the sh*t out of itself :-)


Lets Encrypt has been enabling bad behavior quite a bit lately. Here Matrix says they will no longer accept federation from peers that self sign their certs. Why? Because Lets Encrypt exists. That's the entire argument. They do not address the problems of centralization this creates.


no, the argument is that Let's Encrypt is doing a better job at trustworthiness than our previous attempt at using Perspectives to vouch for self-signed certificates, and so at least self-signed folk can have a fairly seamless upgrade to LE if they want.

However, if you want better trust, you can always use a CA you trust more than Lets Encrypt (including a private one, if you're on a private federation, of course).


Could you please point me in the direction of someplace where this problem is better explained? I'm struggling to understand, how the certificate choice of the peer X should be a problem, given you send them only the information directly related to the peer X, so it seems like you shouldn't care if the traffic between you 2 is encrypted using X's key or MitM's key, because it's only their part of the network that potentially gets compromised. If so, it should be the choice of every given node, if they trust that part of the network they are connecting to, and, conclusively, if they want to accept a certificate they see for the first time, no matter if it's signed by any common CA or not.


https://github.com/matrix-org/synapse/blob/master/docs/MSC17... is the best explanation. You can’t just make it a per-node decision otherwise everything would splitbrain.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: