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.
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.
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/.
> Memo – Real-time collaboration for Git
> On its own, Git can only synchronize changes between clones of a repository after the changes are committed, which forces an asynchronous collaboration workflow. A repository may be replicated across several machines, but the working copies on each of these machines are completely independent of one another.
> Memo's goal is to extend Git to allow a single working copy to be replicated across multiple machines. Memo uses conflict-free replicated data types (CRDTs) to record all uncommitted changes for a working copy, allowing changes to be synchronized in real time across multiple replicas as they are actively edited. Memo also maintains an operation-based record of all changes, augmenting Git's commit graph with the fine-grained edit history behind each commit.
They intend to use this in their WIP xray editor - a possible future replacement for the Atom editor. Meno will be used to provide real-time multi-user collaboration for the editor, like Teletype for Atom: https://teletype.atom.io/
I occurred to me, that if your got repo contained chat history, then your edit would then be a chat client, with your chat history version and stored by git.
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.
Which mature clients and servers should I choose from, implementing all this (basic) stuff?
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.
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.
(if you are affiliated with riot/matrix: keep up the good work!)
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.
For gajim make sure it's a recent version. Dino-im https://dino.im/ is decent. poezio https://poez.io/en/ if you want a text client. converse.js https://conversejs.org/ for a web client.
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).
EDIT: featured on HN https://news.ycombinator.com/item?id=16948597. Look at the comments and you understand why I'm not the only one thinking, the UX is bad...
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.
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 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?