Matrix 1.0 – Are We Ready Yet?
matrix.org
matrix.org
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.
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
> 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.
See https://news.ycombinator.com/item?id=19418111 for a detailed response to these accusations.
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.
We are starting work this week on closing the E2E gap for all the rest.
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.
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.
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
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).
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
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.
[1]: https://github.com/kamax-matrix/mxhsd [2]: https://gitlab.com/kamax-io/grid/gridepo
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.
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?
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.
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
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
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.
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?
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.
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.
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.
"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'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.
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.
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.
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).
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.
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.
Google killed the xmpp momentum by gettimg scared of Facebook around 2010. and adopting the 'walled garden' approach.
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.
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).
You're supposed to use an off-the-shelf XML/JSON parser, not write it yourself.
That's basically a description of ActivityPub that wraps HTML in JSON!
<body> markdown text </body>
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.
Check this active member of the community. Also folks on this very page claim how xml consumes much more resources
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.
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.
Average Joe Dev does not reach the impedance mismatch you mention correctly.
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
I agree with the rest though.
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!
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.
proof please. Checked the top 3-4 xmpp servers last summer and they almost died.
IRC looks 1000000x more active.
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...
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.
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.
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.
Meanwhile both sides get to use free and open communication protocols :)
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!
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.
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).
[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!
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! :)
Let's compete.
[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.
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.
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.
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.
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.
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.
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.
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).
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?
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?
Don’t you mean CVS?
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.
Really, Telegram client is open source and the app is more usable than any other bloatware on the market.
EDIT: Someone seems to already have done this:
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)
- decentralized
- encrypted/private/secure
- open-source
It's like irc or email for private decentralized encrypted chat.
Where can I read more about this?
[0]: https://thomaslarock.com/2018/11/no-you-dont-need-a-blockcha...
aren't? If so can you explain?
In the current internet environment of walled gardens and a siloed and decimated internet, any federation system is worthy of attention.
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.
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.
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).
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.
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.
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.
Compare:
with
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.
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.
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/
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.
As a side-note, someone should make that link a bit more visible on the matrix.org site.
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.
https://ux.stackexchange.com/questions/108801/what-is-the-be...
http://i.imgur.com/4K0pa6m.jpg
That said...I must confess that irssi uses a non-trivial amount of margin space as well!
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.
not being able to snap the window seems to be a conscious choice on their part
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.
We’ve also made usability improvements pretty much across the board, including making the left and right panels resizable [...]
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.
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.
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/.
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!
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.
Here it is: https://www.youtube.com/watch?v=rCggOcKZn-c
(There's a fun interaction at 25:52)
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).
Anyone know if it runs well on Docker via træfik?
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).