> With XMPP and Matrix.org -based services you would still need to convince everyone to join your new network. Easy in theory, very complex in practice!
I think they missed the the bit where Matrix is called Matrix because it bridges (matrixes) the existing networks (Slack, IRC, Telegram, Discord, XMPP, etc) in, rather than needing to convince everyone to join. But no matter, we'll just provide a COI bridge if this takes off :)
> "Jabber is a new project I recently started to create a complete open-source platform for Instant Messaging with transparent communication to other IM systems(ICQ, AIM, etc).
Matthew Hodgson, 2019:
> I think they missed the the bit where Matrix is called Matrix because it bridges (matrixes) the existing networks (Slack, IRC, Telegram, Discord, XMPP, etc) in, rather than needing to convince everyone to join.
Those are some really good examples of the opposite of what you intended to say.
> * Wonky unwieldy hypertext systems instead of the WWW
Which ones? Gopher wasn't hypertext, but it is still going and still a good idea. A conversion to Gopher would be a huge usability and accessibility upgrade for many current websites.
> * The Nomad instead of the iPod
iTunes is garbage. iPods sucked until (certain models) had Rockbox ported to them.
> * The Blackberry instead of the iPhone
How about the Nokia n900 instead?
> * GNU Hurd instead of Linux
I'm "stuck" with BSD. Send help?
Ambitious projects are cool and should be encouraged. Being an ignoramus about existing developments (not saying that that is what the people behind Matrix are doing) and getting distracted by anything that claims novelty should not be. Hoare had a great bon mot about this: "Here is a language [Algol 60] so far ahead of its time, that it was not only an improvement on its predecessors, but also on nearly all its successors."
> The products you mention are all good examples of niche products for techies.
The blind person that told me about how much better Gopher was than the modern web for blind people was not a techie, and I don't think it is moral to treat disabilities as just a "niche."
I don't ever remember being 'stuck' with GNU Hurd. It was a "non-product" with a little more evidence of progress than Duke Nukem Forever. Back in those days, I used SunOS (later Solaris), HP-UX, DEC Ultrix, IBM AIX, Tandem Guardian and SGI Irix.
The more likely outcome is that GNU Hurd would be developed to be similar to Linux if Linus chose to stick with existing projects instead.
Linux had real improvements over Hurd but it'd be silly to suggest that a separate "Linux" brand kernel needed to exist to make those improvements possible.
That's not how interconnects work. You don't even have to connect to Matrix, you can just use it to link existing systems more easily. Pretend there is no protocol/standard and it still does a good job.
In reality, those bridges work badly and hardly anyone uses them. I had to give up on my attempt at using Matrix as IRC client - it had questionable uptime and some channels even banned Matrix users due to frequent reconnects (on Freenode).
Hackint recently shut down their Matrix bridge due to how maintenance-intensive it was (and the fact that it logged all messages in its own database).
This info is a bit stale - it's true we had stability problems in Freenode until July 2018 (exasperated by their spam issues), but since then it's been pretty stable and the reconnects are considerably rarer than freenode netsplits. It's not perfect, but many people use it fine as a casual IRC client. There are over 24,000 active users using the Freenode bridge in the last month, for instance, so I'm unsure that 'hardly anyone uses them'...
The Hackint story is a different one; the bridge itself is not maintenance intensive at all. But it is true that the default Matrix server implementation is resource & relatively admin heavy; we're working on that currently. Meanwhile we're also fixing the data retention behaviour - https://github.com/matrix-org/matrix-doc/blob/matthew/msc176... etc.
I tried Matrix last month. It's neat, but slow and a little buggy. Recommending it to anyone other than a Matrix developer right now seems a bit of a stretch.
Not to mention that it's just re-solving all the same problems other messaging protocols (XMPP, IRC, etc.) spent time solving 10+ years ago.
I always feel that the Matrix organization is a bit disingenuous. Not only are they not developed by any recognized standards body (meaning they have no long-term sustainable funding model), but if they really just wanted to connect all the other chat protocols and make sure everything was interoperable they could have built bridges for existing protocols instead of reinventing the wheel yet again and making the chat scene even more fragmented. Not invented here syndrome is not okay when there are plenty of good (or at least "good enough" even if they're not my favorite) alternatives on the market already.
> Not only are they not developed by any recognized standards body (meaning they have no long-term sustainable funding model),
I don't see a clear relationship between the sentence and its parenthetical.
I don't know about Matrix' funding model. But I do know Signal, for example, isn't developed by a recognized standards body. What can I infer from that about the sustainability of its long-term funding?
i'd argue that the Matrix.org Foundation is just as 'recognized' as the XMPP Standards Foundation :) In terms of disingenuousness - i'd argue that the definition of disingenuous is accusing us of reinventing the wheel rather than acknowledging that Matrix is an entirely different type of technology to IRC or XMPP. It's more similar to NNTP or Git than either IRC or XMPP. For better or worse, trying to solve existing problems using new approaches is how things evolve. On which note, it's cool to see delta.chat and COI trying a totally different approach too.
> Matrix is an entirely different type of technology to IRC or XMPP. It's more similar to NNTP or Git than either IRC or XMPP.
What does this have to do with anything? It's used for chat and solves all the same problems. You could easily have done all the same things (including building a system that does syncing like matrix nodes) on top of an existing protocol instead of reinventing the wheel.
We seem to have this same dead-end conversation every few months, so indulge me as I try to break the impasse with a story instead.
When I was about 13, I worked on a really fun chat system at school called (wait for it) iNFERNO][ (it was the second attempt at a chat system called iNFERNO). It was pretty awesome, and worked like this: the school ran a large network of 68k-based Macs (LCs, Centrises, even a Quadra) networked to a single Apple Workgroup Server, which ran a Filemaker Pro db instance that the school used for its HR and record keeping. As it happened, the DB server was set up such that anyone could create DBs on it, so the school geek community spun up a few to play with.
If you've ever used Filemaker, you'll know that it's a visual DB - almost creating Forms as the first-class citizen (a bit like Hypercard) and the fact they're backed by tabular data is almost hidden. Even more excitingly, it even had basic networking so you could run network queries between DB instances - including exchanging arbitrary objects (e.g. images, videos etc), if i remember correctly.
So, what we did was to set up a centralised DB (iNFERNO itself) on the server, shared over the network, which stored a bunch of chatroom history and provided a graphical timeline view onto the room when opened up over the network from a Mac (set up to occupy the top 2/3rds of your screen).
Meanwhile, and this is the fun bit: we also wrote a DB instance called your "iNFERNO Key", which you stored on a 3.5" floppy disk and could run as a local DB off the disk on any Mac you happened to walk up to. It coughed up a window on the bottom 1/3rd of the screen, which provided your composer prompt. Everyone had their own key, and customised it to their heart's content with different themes, colour schemes, buttons, bot-functionality etc. And it stored their credentials (and we even tried some basic shared-secret e2e crypto) to make logging in trivial - you just put the disk in the drive and clicked the DB (which would in turn spawn the separate main window to view the shared DB timeline).
When you sent a message (which could be text, or arbitrary filemaker objects like images, videos etc), Filemaker let you stage the table row locally and then insert it into the shared DB instance, so you ended up with a surprisingly fun and usable server/client chat system, with arbitrary scrollback, multidevice support, file-transfer etc... using a batshit crazy architecture which involved schoolkids running around waving 3.5" disks around and forking each other's "keys" and somewhat unnecessarily authoring messages using a local DB instance when the whole thing could have been done on the serverside DB instead.
The whole thing lasted about 3 months, getting increasingly popular until the school went nuts at their Filemaker server being completely overloaded and tragically turned it all off. And whilst I still probably have my Key somewhere, we surely didn't have a backup of the central server itself :(
So, my point is: this was a chat system, with many of the features shared by XMPP, Matrix, Slack, Discord etc today. Could we have built it on top of something else? Sure, we could have built it on IRC instead or Talk or some BBS based thing. But instead we chose to experiment with a totally different architecture, which had its own weird trade-offs and benefits, and learned a bunch of stuff along the way. (I still miss the idea of literally synchronising rich graphical objects over the network - it almost felt like Croquet or one of the virtual world things).
And so, whilst you're totally right that we could have tried to layer Matrix semantics over the top of XMPP or IMAP or Filemaker(!), we similarly wanted to try a totally different architecture; one without stanzas and message passing; one without all the historical baggage of XMPP; one which only does group conversations; etc. So I'd argue this is how stuff evolves, and sometimes it's good to experiment with building on a new base. And if it doesn't work out; hopefully it at least provided a learning experience for all concerned. The same goes for COI layering chat over IMAP; almost as questionable as layering chat over a networked DB ;). So, let's just get on with building stuff and seeing what works and what doesn't. This isn't a case of re-inventing the wheel for the sake of it, but seeing how well things work if you build on an entirely different set of foundations.
+1 and arguably the concurrent clients + multiuser thing is something which XMPP did never get around really. There are at least a dozen or so XEPs which noone is implementing (except for Conversations) which make basic functionality a mess. You download any client and get basic 1on1-chat with no missed messages when both parties are online. Everything else depends on, .... whatever. Even major providers needed some years to get around this (look at Whatsapp). So I think it's really not reinventing the wheel if one tries to implement something anew learning from the pasts mistakes
(if you are affiliated with riot/matrix: keep up the good work!)
well, I'm open to client suggestions (and to public servers, where I can try them out too). I was told by Google (tm) that gajim should be one of the most feature-complete clients on the desktop. tried it with conversations on the phone. group messages go into some archive-window (instead of showing up in the chat window like in every over program), sometimes the archive misses them... pictures are a link to the server, so I have to manually download them all. encryption with multiple clients is a mess (even more so than matrix). av is completely missing. of course this are all relatively minor things from a technical standpoint but they add up and together with the thing that a large amount also depends on the server this makes for a very bad user experience (basically it currently means: run your own server and use conversations)...
> group messages go into some archive-window (instead of showing up in the chat window like in every over program), sometimes the archive misses them...
Not sure what that even means. Worth reporting.
> pictures are a link to the server, so I have to manually download them all.
I think you need to install the image preview plugin.
Public server wise I don't have any recommendations (but i'm sure others have plenty) other than movim. https://movim.eu/#try they have a baked in client (and do a whole bunch of other stuff like micro blogging) but once you have a account, there is no reason you can't use any client you want.
Encryption with omemo is a issue and usability could be improved (I believe people are working on that).
Hey, thanks a lot, those clients look really quite great (and polished). Still, if you look at movim you imho experience the problem of the whole open XMPP-ecosystem. Somehow nobody cares for getting other people to support their features and in the end everything moves closed-source. At this point I think this really is a problem of years of standardizing new features and a lot of projects being sold under the label XMPP being 10 years behind on those features. In theory XMPP today (together with jingle?-based mediation of a jitsi-videobridge) is ready for everything. But in practice I didn't find 2/3 clients you recommended (google+xmpp-foundation site).
I;d like to see a table / chart showing the top 10 or 20 or so xmpp things - and what features are missing from each, along with notes about the language app 1 2 etc is written in, and an estimate in how long it would take coders to add the amount of missing features that others have..
then we could see an estimated total, like for $xx we could get most of these apps all on the same page of features running... if that is the major hurdle - a crowdsourced money or and time to get them all modernized may make the whole ecosystem 2.0 and worthy of use?
Surely it can't be that much that is needed - yet it seems that fixing just one or two is not having the same network effects of having them all speaking the 2.0 feature language.
https://compliance.conversations.im/ not for clients but slowly getting there for the servers. And this is only for a working text-based chat, AV is really of the table. Basically except for conversations, most of the "clients" should be labeled protocol explorers because most of them have serious usability issues with most of the listed XEP...
The worst thing isn't that the standard isn't defined or something, but that a lot of projects are claiming to support XMPP when they only support some core functionality...
> i'd argue that the Matrix.org Foundation is just as 'recognized' as the XMPP Standards Foundation :)
Recognized by whom? The XSF has standardized their core in IETF. Is there something similar for Matrix.org Foundation?
> trying to solve existing problems using new approaches is how things evolve.
What new approaches? You're just recreating federated IM network using different wire format. How on earth is it innovative or new? Using HTTP+JSON instead of TCP+XML is something new? Bridging to other IM networks is something innovative?
> Matrix is an entirely different type of technology to IRC or XMPP. It's more similar to NNTP or Git than either IRC or XMPP.
I've heard this argument many times already, but the truth is that XMPP formally speaking is de juro an "XML routing protocol", but both XMPP and Matrix de facto are being used largely as IM protocols.
> For better or worse, trying to solve existing problems using new approaches is how things evolve.
Since you invented nothing new, you evolve nothing.
The foundations responsible for the protocols look to be pretty similar to me (both non-profit orgs), and would be equally recognized as such by the general public. Obviously XSF contributed XMPP to the IETF after 10 years or so, and perhaps we'll end up contributing Matrix to IETF or W3C or whoever too if they'll have it.
> How on earth is it innovative or new?
> Since you invented nothing new, you evolve nothing.
sigh - I wonder if the XMPP community would spend less time constantly complaining about Matrix if they understood what it was :/
The innovative bit of Matrix is that it's a replicated database of objects (events), similar to Git, but designed for syncing conversation history around in realtime. The events for a given room get replicated over all the participating nodes. There is no central server responsible for coordinating the room; instead all the participating ones do so equally. It's impossible to communicate with someone on a different node without effectively giving them a lazy-loaded HA replica of the room. Architecturally this is about as opposite of MUC (or MIX or FMUC or DMUC or whatever) as I can think of.
It's NOTHING to do with HTTP+JSON versus TCP+XML - Matrix can use whatever transport and encoding floats your boat. For instance, at FOSDEM we showed Matrix running over CoAP+CBOR to try to spell this out: https://fosdem.org/2019/schedule/event/matrix/.
> On its own, Git can only synchronize changes between clones of a repository after the changes are committed, which forces an asynchronous collaboration workflow. A repository may be replicated across several machines, but the working copies on each of these machines are completely independent of one another.
> Memo's goal is to extend Git to allow a single working copy to be replicated across multiple machines. Memo uses conflict-free replicated data types (CRDTs) to record all uncommitted changes for a working copy, allowing changes to be synchronized in real time across multiple replicas as they are actively edited. Memo also maintains an operation-based record of all changes, augmenting Git's commit graph with the fine-grained edit history behind each commit.
They intend to use this in their WIP xray editor - a possible future replacement for the Atom editor. Meno will be used to provide real-time multi-user collaboration for the editor, like Teletype for Atom: https://teletype.atom.io/
I occurred to me, that if your got repo contained chat history, then your edit would then be a chat client, with your chat history version and stored by git.
Been watching Matrix for a long while now, and just now I see this:
> "innovative bit of Matrix is that it's a replicated database of objects (events), similar to Git, but designed for syncing conversation history around in realtime."
and think, this is basically blockchain workings right? IF we had only created a client that worked on iOs only, could store and send chat coins and log votes for each group, this could be presented in press releases as a new blockchain chat and get all kinds of posts and maybe money thrown at it.
kidding aside - I have more faith in Matrix moving forward than any similar projects at the moment, and I don't see that changing soon - so I hope more can be done to polish clients and make sure bridges and other features are well done.
As soon as moderation tools are enhanced I'll begin to use it on several sites.
I'd love to see some bubbles of related issues that need love and have some people put some estimated time and money on each bubble - maybe we could crowdsource some code for some bubbles and money for others or something -
I feel there are many groups of people who want / need different things in order to increase adoption, and I feel for the folks coders / maintainers who are trying to extinguish all the fires at once.
I put a few hundred into bug bounty like thing to get some features added to rocket chat so we could use it.. then found the amount of other bugs left un worked at the time meant it was not feasible for our usage any time soon. Hopefully with the funding and such of Matrix it can evolve on multiple levels at once and become a solid framework with many clients and ux options.
A bridge for COI and delta chat or any others. I'd love a client that bridges with email address and has one click to keybase auth or pgp and such - and puts things into a timeline / fbook feed like view.. not for me, but for others.. group friends, display on phones and web.. seems these things could be close to reality.
Chill dude. No need to get all butthurt. If you don't like Matrix, don't use it. The rest of us will also have make the same choice for ourselves and time will tell whether Matrix has a unifying or dividing effect on chat.
I, for one, have been playing with Matrix and other protocols for awhile and have been impressed not only by the Matrix team's vision, but also by their ability to deliver on it consistently (though sometimes slower than all of us would like). The whole ecosystem has become much more polished over the past year (and the new Riot client is sweet!)
Problem is, "team". It's not really decentralized at this moment, just software from the singular vendor. Of course, it moves faster than a really distributed protocol (in all senses of this word).
Let's assume this hypothetical client doesn't exist (I'm not actually sure if it does or not): are you suggesting it's better to start over and create an entirely new chat protocol instead of just writing a client that has the features you want? These features do all exist within existing open protocols, and clients do exist that implement some of these features (and probably all, but I'm not sure). So I don't see any reason to start over.
I've been using [Wire](https://wire.com/en/) very happily for some time now. Great interface, top quality audio/video, good chat, persistent, very secure, open source. I'm surprised it hasn't received more mentions.
promised for 6 years... and remember this thing is commercial, not OS...:
"Nonsense comments from clueless commentors. It's not our problem if you didn't update on feb14. Also, it's our app and we do whatever we want, please uninstall Xabber and use something else. You had no voice or rights here besides those that have been generously given by us. Now they are revoked."
Jabber is dead. Apparently it was either bad enough or complex enough to prevent creating good clients and servers. Matrix is another chance to kill Whatsapp and Telegram and replace proprietary software used by billions with free software. I'm not sure if it'll be successful, I think that implementations are not there yet and momentum might be lost when they will be there. But Jabber won't recover and we should try, because giving up is not acceptable.
To counterbalance this a bit, I'm using it heavily with a large group of (partially non-technical) friends and friends-of-friends, along with participating in public rooms over federation and it's been pretty smooth. Things were certainly rougher a year ago but they have improved a great deal and are continuing to improve at a good pace.
Speaking in my personal capacity but as somebody's who's a freenode oper:
The ridiculous crashing every few minutes thing of the IRC bridge has been fixed enough I haven't noticed a problem for quite a while.
I have a looooot of disagreements with matrix, which I have discussed and will discuss with them, but honestly they're not doing it completely wrong anymore.
> I have a looooot of disagreements with matrix, which I have discussed and will discuss with them, but honestly they're not doing it completely wrong anymore.
\o/ :) The other stuff is very much on our radar, fwiw (and in an ideal world i hope we'll finally be able to implement a services or TS6-based bridge). We've been a bit distracted over the last few months with an XMPP bridge (matrix-bifrost) but will be back on IRC bridging shortly.
This is completely the opposite of my experience. I'm in probably a dozen Freenode channels via bridge and another 5-6 Mozilla IRC channels, and haven't had a problem in as long as I can remember.
Bridges usually suck, even for IRC. Split brain, someone needs to monitor it constantly, you are not sure if Matrix clients have received it and vice versa.
But any bridge will be restricted to the lowest common denominator, often you get into weird corner cases where the two ends of the bridge work subtly different.
Very true, but have you tried just reaching out to someone via email on Matrix in practice? I tried with Riot and am not able to do that. Maybe just a bug, but if you want the real Matrix experience, you need a Matrix account. Don't get me wrong, I do love Matrix, but I also love XMPP - both not spectacular successes so far. AFAIK, the French Matrix version is even locked down and does not federate across the network.
You can reach out to folks by email in Riot by hitting "start chat" and entering an email address. I'm not sure how much easier we can make that ;)
We should run a general purpose email bridge though, and in fact there's a massive public sector outfit asking for such a thing currently so it'll probably happen sooner than later.
In terms of Matrix not being a spectacular success - well, that's a matter of perspective. The intention for France is absolutely for it to federate with the public network (once there's are sufficient border gateways in place). And France is far from the only high profile Matrix deployment out there, it's just one that we can speak about. But eitherway, COI looks cool, and I hope it helps OX sell more mail servers :)
I think they missed the the bit where Matrix is called Matrix because it bridges (matrixes) the existing networks (Slack, IRC, Telegram, Discord, XMPP, etc) in, rather than needing to convince everyone to join. But no matter, we'll just provide a COI bridge if this takes off :)