In my small bubble of tech news, France has popped up a few times. Found out recently that they are officially[0] using the privacy-respecting Qwant search engine. Several weeks ago, I learned that they have planned obsolescence laws[1] which makes them a pioneer in this area (from what I understand).
There's also an active non-profit organization using FOSS to create alternative, privacy-respecting, solutions to Google products (framasoft[2]). I mention this last one because I haven't come across a similar major undertaking (or similar mindset) in too many other countries.
Now they are evaluating Matrix for their communications needs. I can understand the importance of countries, nowadays, not relying too much on the services of companies tied to a specific country (namely the US) but I wonder what else is different about France? What else are they engaged in re: FOSS, privacy?
French citizen here. For as long as I can remember, there's been a strong will in the French FLOSS communities to develop local alternatives to the ever-expanding reach of the FAANG/GAFAM, for many reasons. The obvious one being the export of data outside actionable jurisdiction, but it could also be explained by differences in ideology.
As for what else we're doing, there's La Quadrature du Net (LQDN)[1] which took part in the recent Google €50m fine, some projects by concerned citizens to keep a watch on politicians[2] and tracking in mobile apps[3], but one of my favourite things comes from the increasing will to release "OpenData" (public data sets from various sources)[4] to let collectivities, regions and smaller units build tools to solve their local problems.
France's position on this is essentially nationalist; local surveillance of the internet is strong following various terrorists attacks, and there isn't quite German levels of distrust of state security apparatus. But on the other hand they are outside the five eyes, run an aerospace and tech industry that has to deal with US industrial espionage, and are aware of the cultural hegemony of English language media.
(People seem to think that France doesn't have a tech industry; it very much does but little of it is consumer facing)
>Nationalism is a political, social, and economic ideology and movement characterized by the promotion of the interests of a particular nation,[1] especially with the aim of gaining and maintaining the nation's sovereignty (self-governance) over its homeland.
>a sense of national consciousness exalting one nation above all others and placing primary emphasis on promotion of its culture and interests as opposed to those of other nations
Oh, that makes more sense. The first definition seems nearly self-evident; what nation state doesn't want to protect its own interest? But there's certainly a distinction in promoting oneself above others.
The very concept of a national interest is somewhat nationalist, but then I don't believe that "nationalist" always implies "to the detriment of other nations". It often does, due to zero-sum thinking, but it's not intrinsically necessary to the concept of nationalism.
(also, exercising nationalism against a colonial power may be to its detriment but also be morally good. This obviously does not apply in the case of France, which itself is a colonial power)
I was looking up nationalism on Ambrose Bierce's Devil's Dictionary, but didn't find it (probably too sensitive a subject at the time), so here's its definition of politics:
> POLITICS, n. A strife of interests masquerading as a contest of principles. The conduct of public affairs for private advantage.
This is hardly relevant, but I'm using the occasion to share the great piece of satire that's Devil's Dictionary. Here's a few others:
> OCEAN, n. A body of water occupying about two-thirds of a world made for man — who has no gills.
> POLITENESS, n. The most acceptable hypocrisy.
> PERFECTION, n. An imaginary state or quality distinguished from the actual by an element known as excellence; an attribute of the critic.
Edit:
> PREJUDICE, n. A vagrant opinion without visible means of support.
You might be right, I wouldn't know. I guessed that because I found that a satirical dictionary not having an entry for words nationalism or nation more difficult to believe.
NATIONALISM,n. Discrimination which is based on geography and thus obviously superior to RACISM and SEXISM which are based on biology. Can be further refined to NEPOTISM and ultimately SELFISM.
I work in a French public lab, and the policy here (and in many if not most other public labs) is to produce FOSS based on our research. It has always been more or less a fact, but this is becoming an official policy, AFAIK: make it FOSS unless you have a good reason not to.
Regarding privacy: not my field of expertise, but France is far from paradise here, thanks to the terrorist attacks a few years ago.
Also last October ANSSI, the National Cybersecurity Agency of France, released the sources of CLIP OS, a Gentoo-based hardened, multi-level operating system. https://clip-os.org/en/
My first use case of FOSS was with Framasoft. Back in 2009. I had my first USB key, and downloaded all the needed softwares on my key[0] , notably SumatraPdf, OpenOfice and Mozzilla.
We had a big teletext offering in France too at some point. Minitel is not it. Minitel was a modem+terminal in your house. So, it was bidirectional, secure, and had incorporated billing. You were able to do all kinds of things with it: enter chatrooms, order stuff (like train tickets), register/check the results for some exams, etc.
The British counterpart to Minitel was not Teletext (a one-way system that was present throughout Europe anyway), but Prestel. It wasn't hugely popular, not on the scale of Minitel, but it did have the UK's first highly publicised hacking case leading to changes in the law: https://www.bbc.co.uk/news/technology-36306419
France also wants to break Internet and culture sharing (and code). There is a new law project in EU that will give the power to big companies to control what we have the right to publish, and that makes the host platform legally responsible of what users post.
There is lot of private initiatives to make great things, but no state vision to make things right. The only value they see is economical, but not for the people.
I don't think it was, she was playing Mitterand on emotions, which most french guys have way too many and are easily controlled by them (I see it every single effin' day around me in many ways).
If she would go nuclear on Argentina due to that skirmish and few marines dying in regular acts of war (however sad it is, this is business-as-usual during war), she would have alienated UK to every single country in the world, destroying it on many levels. And also go down in history as one of the most horrible rulers in history of mankind.
Not something any power-and-approval-hungry sociopath (sorry, 'leader of the nation') wants to leave behind.
Oh, the nuclear threat was in retrospect almost certainly a bluff, what I was more questioning was whether the conversation happened, and whether Mitterand did in fact hand over any kind of remote disarm codes for Exocet missiles.
> she would have alienated UK to every single country in the world, destroying it on many levels.
That really isn't realistic. Some allies might have been unhappy with Thatcher for normalising the use of nuclear weapons, and might even have openly criticised the UK. But France, the US, the Commonwealth nations would not just desert an important ally: how would that benefit them? They would have retconned the story and we'd all believe now that Galtieri was the next Hitler and would have subjugated the whole hemisphere if not for Thatcher's brave initiative.
They can't, but they also can't afford to have a fighter that's significantly inferior to their adversaries. So they find the country that can offer what they need, which they can trust most (or don't trust least, depending on your perspective).
depends on how the intertwining is done, a lot of international instability is due to foreign companies taking a bit too much advantage of other places
It's a slightly different problem as those countries that buy the Rafale do so because they don't have (or aren't willing to develop) the means to build their own planes.
So to them it's mostly a matter of choosing which foreign entity to trust and at which cost, between the US, Russia, China, France, and a handful of other states with lower performing but cheaper equipment.
Arguably it is easier to check a few jets you buy once than software used by many thousand persons on different machines with differnt versions and monthly updates.
I am pretty sure that especially in weapon systems it is quite common for customers to demand special changes, services and insight.
There's also big economic incentive for many countries to just go to FOSS solutions for their needs. It alleviates the need for self-sufficient local private corporations or huge public programs. Nothing speaks louder to a politician than saving on their budget. Or making administration easier (which is likely to be incredibly important in a country with a bureaucracy as Byzantine as France).
Now that the big hacker/open source FUD is mostly done for, I think you'll see a lot more countries deploying FOSS tech as a matter of fact an not as an ideological statement or an avant-garde trial.
France also recruits hackers as part of their beta.gouv.fr community, they are pushing things forward to more open source from the inside of the government. Many of them are not only at betagouv, but also at laquadrature or framasoft and the like.
I like the idea behind Matrix, but hosting it is really a pain. I've given up on it until it's a simple `docker-compose up -d` away from running a full instance.
To get back on topic, France has really got its FOSS movement moving. There are a TON of Mastodon and Peertube instances located there. It's admirable.
By default, it sets up Synapse and a bunch of other services around it that are necessary to really make it useful (Postgres instead of the default under-preforming SQLite; mxisd as the identity server; STUN/TURN server for WebRTC calls; riot-web; various bridges; etc)
I ran a little test last weekend. I got a 1 CPU / 2GB RAM virtual machine from a cloud provider and deployed Matrix/Synapse on it with spantaleev's Ansible script.
I created 100 accounts for chatterbots. (This is not federated to the main Matrix network -- just local.)
The VM showed some lag when the chat bots connected and started inviting each other to their channels. But once all the invite sending/accepting settled down, it's been pretty smooth. It's randomized, but I think each channel has about 18 or 20 users.
The whole thing is using about 900 MB of RAM, and that's including everything -- CentOS, several containers, the Postgres database, Synapse, nginx, etc.
the RAM usage depends on the size of rooms the users join, not the number of users. synapse typically takes around 1GB of RAM (allocate 2 to be safe), but we are working on that.
I think it is perfectly reasonable for a client to use more RAM than a server, having to display a GUI and all. I'm thinking of IRC servers vs. clients. (Certainly not 2 GB, but that's another matter.)
There are a few alternative server implementations under development. Personally I'm hopeful for Dendrite (written in Go): https://github.com/matrix-org/dendrite
I've been running two matrix (synapse) instances for about 2 years and it's been pretty painless. My "personal" instance is hosted on a dedicated server running Ubuntu, and the package works just fine. The other one uses a slightly modified version of the code, and installing/updating it via pip is trivial. What part of the process did you find tedious ?
we’ve bundled official docker for synapse for a year or so now, and it really is as simple as docker-compose up -d? would be good to understand what’d going wrong.
I apologize for commenting on it before checking the situation: I retried it now, and it seems the situation has improved a lot from last time I tried. It's still far from a simple `docker-compose up -d` (I had a few issues with TLS because I didn't understand how to generate the key, opted to disable it and reverse proxy it via Apache2+letsencrypt), but it's doable in a relatively short time. All that I have left now is to setup a frontend (ie. Riot).
Footnote:
IMO, the barrier for adoption for this kind of services has to be the lowest possible if it wants to gain any kind of traction. Mastodon and Peertube are good examples of this: docker-compose.yml in the project root, and in < 1 hour I got everything working by just setting a couple configuration values that were already in the environments section.
I figure that there is a lot of work going on right now so this might not be in the top priorities, but I really hope Matrix gets there soon.
You really should try out the guy's Ansible playbook linked elsewhere in this thread. It automates setting up the database, the reverse proxy, the Let's Encrypt certificates, pretty much everything. You run a couple of git commands, a couple of ansible commands, and you're done. It's amazing.
Could you elaborate on what kind of troubles you have with the hosting? So far I host only an XMPP server but I would like to know what kind of trouble I have to expect if I wanted to host a Matrix server too.
> Because Matrix is inherently decentralized, no single server "owns" the conversations; all traffic is replicated across all of the involved servers. [...] Matrix is more like Git than XMPP, SIP, IRC, or many other traditional communication protocols.
The Matrix protocol is well worth the read. JSON-LD is a bit of a nightmare to work with, but the gist of it is a solid concept; it has drastically changed my approach to software design.
The very high-level view is that Matrix is a set of protocols for syncing messages and state between servers. Matrix is to XMPP what NNTP is to SMTP. This makes multi-device and disconnections much easier to handle, because all you need to do is to wait for the messages to eventually arrive; this is in contrast to XMPP which favors direct routing of a message and synchronization is second.
In my own view it's a much more robust way of architecting communication: the server(s) should assume that remote parties will be off, and remote parties will come and get what they want at their own pace and time. Maybe they won't receive a few messages immediately but can immediately retrieve multiple when needed. With a stretch you could see a parallel with Kafka: instead of trying to send stuff to consumers as soon as it is produced, just store it, and when clients are up they'll process stuff.
I agree. One could use the Matrix specs to build some sort of message queue (using rooms) where human (text, markdown) and machine (json-ld) could communicate and interact..
It federates itself like SMTP does, I guess? If you translate and rotate their solution (abstractly speaking) you arrive at some very interesting ways to create a federated website/app/thing. Inspiration is always a really hard thing to nail down.
From a technical standpoint, there are six specifications (Matrix, Mastodon, XMPP, SIP, SMTP, Microdata) that have gotten the "future of the internet" partially right, in my opinion. Some union of the them, excluding the unfortunate bits, is likely the email/Twitter/Facebook/what-have-you killer. Putting that in consumers' hands and getting them to use it is another story, but we do have the starts of a technical/back-end answer.
For example, you could embed text document edits inside of Matrix messages as Microdata (ignorantly spamming someone aside with thousands of character edits aside). Is your spouse doing their taxes? Send them a chat message with Microdata explaining to the form where the attached document goes.
As a general goalpost, WeChat (having circumvented federation problems) in China is a really great example. You can pay for food at a hotdog stand on the street with chat. Uber merely facilitates communication between taxis and commuters. Whatever the project(s) you are referring to, software usually ends up solving communication problems. Recursively simplify your problem, ultimately realize how communication fits into it, then work your way back up to your initial idea. Federated IM is ludicrously powerful and, especially with graceful degradation, can lead to some sales leads.
One problem with upvoting comments instead of saying “+1” is the parent can’t see your upvote. But I’d like to explicitly say: I am also very interested in the answer to this question, if you have the time.
well, perhaps someone unaffiliated with Matrix or XMPP should update the wikipedia page to explain. https://news.ycombinator.com/item?id=19223963 is a very good summary, for instance.
From our perspective, the room replication is absolutely critical - it means that the network can partition and the servers can come up and down without the room being disrupted at all. It's the opposite of a MUC, where if the server hosting a MUC is inaccessible or goes down, you're screwed.
It can even be bad for security: e2e encrypted messages are still replicated and stored on the servers. 30 years from now they might be decrypted by faster CPUs.
Encrypted 1:1 messages should not be stored on servers!
They should be sent between clients p2p stile or at least forwarded by servers without storing them.
If you recall that the NSA is already storing large amounts of internet traffic for later decryption, whether or not some server stores it is mostly irrelevant. Maybe you're worried about other lower-tech attackers, but I don't think that Matrix servers are going to keep 30 years of chat history (I imagine most Matrix servers are going to eventually use default retention policies). Not to mention you can run your own homeserver if you don't trust the operators of public homeservers.
Storing 1:1 messages (noting that Matrix doesn't differentiate between group chats and 1:1 chats) on a server is beneficial because you might not want to lose your entire private chat history with your family and friends whenever you lose a device (source: this happened to me multiple times with Signal -- which has an awful backup system that I didn't use because it simply doesn't work properly).
Now, there is obviously cases where you don't want the server to keep your messages forever -- and then you might want to have retention policies and so on. But I don't really agree with the security argument, since the most obvious attackers already likely have your messages, and it sacrifices a lot of convenience that most people expect (my partner didn't expect to lose all her Signal messages when her phone died unexpectedly).
the reasons you need encrypted messages stored on the server are:
* to synchronise them between multiple devices
* if you lose your device, to have a hope of recovering your history
* to be able to search them (either homomorphically or via a search bot you run)
I finally got around to brushing off the year's worth of dust that had accumulated on my Matrix account and signed in to Riot on my phone, as well as their web client. I was pretty pleased with how easy it was to connect to a Freenode channel. So far it seems to be a decent experience, I'm looking forward to using it over the next little bit.
Things are still going strong for open source in France (despite de occasional setbacks) since France was rated in 2008 the no 1 country in the world in terms of open source adoption by Georgiatech:
It's quite subjective, but my view is Matrix is what XMPP would like if it was written today.
The main advantages are it is using JSON instead of XML, and HTTP instead of custom protocols so it can work directly from browsers and with lightweight mobile clients. It also has a lot built into the core protocol, where as to get XMPP to do anything useful you will need to use a lot of extensions (and ensure the server and all clients support them).
The only con is it's still a relatively young project. I'm not sure I would want to rely on it as my main form of communication in a company just yet, but for personal usage it is fine.
Also, what custom protocol are you talking about? XMPP works on top of TCP/TLS (or Websocket). Those are the IETF standards. In fact XMPP doesn't require an additional layer of HTTP at all.
> with lightweight mobile clients
Where are they? Anything even remotely comparable battery-wise with Conversations (an XMPP client)?
Not to mention that Matrix has a terrible server implementation which requires several GB of RAM just to join matrix.org room.
> It also has a lot built into the core protocol, where as to get XMPP to do anything useful you will need to use a lot of extensions (and ensure the server and all clients support them).
I fail to see how having a monolith core versus splitted specs has to do anything with code written to support that. Of course, initially every implementation will strive to implement full core (that was in XMPP in 2000s), but when the core evolves you have absolutely no guarantee that every developer will implement all new parts of the core. How is that addressed in Matrix?
Well that's quite easy, since hosting a server is a resource hog, most people are still on matrix.org, which gives it a special status in the ecosystem (even more special than jabber.org has been in the early 2000s fox XMPP). This allows them to "move fast and break stuff" on short notice (a few months), to bring the protocol forward and force people to upgrade. In the federated XMPP ecosystem, they essentially have to come to a community consensus between developers, servers operators and all other relevant actors to write a manifesto or a new spec that says "stop using $thing at $date".
In my opinion matrix, while being open-source, federated and easy to write clients for, is still a half-locked platform because essentially the matrix.org server is "too big to fail", and the matrix team is the only one who can e.g. offer consultancy over the protocol because nobody else can have a long-term view of its future evolutions (of course the matrix people are nice, and you can discuss with them, but that is still not a standards body).
> is still a half-locked platform... but that is still not a standards body
Exactly. That's why I always stress the importance of the IETF. The whole point of the IETF is that you cooperate with people, deal with opposite opinions, accept criticism, come to agreement, develop a compromise and produce a high quality absurdly documented standard. In Matrix bubble (and any others, see cryptocurrency or p2p community for example) they are the only one who makes the decision. They don't care on other opinions. If you disagree with them you're asked to stop "fighting", "focus on interaction", "understand their goals" and other meaningless stuff like "let the best standard wins" (when in reality the whole point of the standard is to cooperate). Formally speaking they try to substitute a "standard document" with an "open document" and people kinda swallow this because they don't see the difference.
> In Matrix bubble (and any others, see cryptocurrency or p2p community for example) they are the only one who makes the decision. They don't care on other opinions.
> You can see our governance model at https://github.com/matrix-org/matrix-doc/blob/matthew/msc177.... and see that we do everything we can to ensure that the wider community can contribute to the spec and steer it in the right direction... And fwiw, we'd be perfectly happy to contribute the spec to IETF or W3C or whoever once it's relatively stable, just like XMPP did.
I'm not a lawyer to read such documents. Just "contribute" your core to the IETF, prove me wrong.
I might be mistaken, but from what I read the main addition is that all peers replicate the full state.
If you have a dominant xmpp server (like gmail was) that removes xmpp support, its users have the start using other clients to connect to it or start a new social structure from scratch. In essence this makes the xmpp server a dominant player with leverage.
If gmail had used matrix when it pulled the plug all interactions (who knows who, how to route traffic, chat history) would have been replicated at the peers so it would just have removed google’s servers from the equation. The people who had been using it would continue uninterrupted.
In both cases, if users have an account on gmail and are using it, and gmail pulls the plug, then they can't use it anymore and can't migrate. The history is still there in the case of matrix, but they can't reuse the same account.
However if another user is homed on another server, they would still keep the knowledge and history on their side: gmail did pull the plug on xmpp, yet people are still using it. Their server still know who their contacts are, what room they're usually in, etc...
Matrix does have the advantage that the chat history is fully replicated on all homeservers so it makes history retrieval much saner, but that's it. Matrix doesn't route traffic (messages go from sender's homeserver to recipients' homeservers, that's it) and doesn't share client's information with the whole world.
> The people who had been using it would continue uninterrupted.
I'm not sure about that. If the main matrix server disappeared today that'd be problematic. Yes, you'd have history locally but the same can be said for any native client that stores history locally.
As far as I know there is no way to migrate matrix history now. Is there? (genuinely curious)
> I'm not sure about that. If the main matrix server disappeared today that'd be problematic
This ^^
Currently a large amount of users (I'm told around a half, but I'm not sure) have matrix.org as their home server. So Matrix is effectively building a power-law network with all its drawbacks: when the "power node" of the network goes down the whole network falls apart.
To be fair, this is somewhat inevitable in the initial stages, before a reasonable spec is released. Many people, like me, are just "sitting on the fence" and test-driving Matrix via their matrix.org server, until there are reasonable assurances that deploying our own Matrix server will come without too much hassle.
After Synapse 1.0 is released (sometimes next month, IIRC), I'm definitely deploying my own homeserver, and federating it with the rest of the world.
FWIW, I've been running Synapse since 0.20 or so (for at least 2 years now), and there has never been a breaking change in the protocol as far as I'm aware. I had to read release notes at some points to get the upgrade to work, but it was mostly Python-library-related stuff IIRC.
Well they are making one big instance nothing else. Also unfortunately it means that you can't possibly federate with matrix.org. I've been running small otherwise perfectly functioning instance for few years for my circle/work as slack alternative on small vps. One time i did the amazing mistake of turning on federation with matrix.org. It immediately killed my servers performance especially when i joined some popular channel. The channels probably have more messages than my whole server combined. And it works the other way too - matrix.org is like sponge sucking other instances.
I guess this is the real problem for me - i would love to federate but i can't possibly police or enforce what servers/channels are small enough that my users can join them.
This isn’t anything to do with the size of the matrix.org server; just that synapse needs to be more resource efficient and we need to limit the sizes of rooms small servers try to join. we are doing both.
I can't see any advantage in using JSON and HTTP for a protocol. JSON shines for ad-hoc, untyped, structured message payloads rather than the strongly-typed semistructured text payloads possible with XML/SGML, and HTTP wasn't designed for federated protocols. It seems more like a fashion thing to me.
I kind of agree with you, but I'll add that XMPP usage of XML is weird enough that it makes it hard it use a normal XML parser / producer. Honestly I really wanted to like XMPP. I read all the specs at the time, even started to write some code, but all I can say is that it really sucks. I haven't looked at matrix yet, I hope it's better
Indeed! I was in the same boat - also started writing a client, but wasted too much time on the stupid XML stream idea.
Basically, chatting is message oriented, but the XMPP inventors thought it would be neat to start the connection with a tag like <beginconversation> which would then be dangling for the whole connection, preventing the use of a simple DOM XML parser (remember this is many years ago) for each message.
Can it handle plaintext XML suddenly becoming TLS encrypted? Because that's also what happens on any XMPP connection. If it can, then great but I guess it's more an exception than the rule
You don't have to implement all the modules :p
There is some basic ones that you need (see XEP-0412: XMPP Compliance Suites 2019 - https://xmpp.org/extensions/xep-0412.html) and you have already an up to date client and server. The rest if for specific use cases.
I dislike JSON, but it's a step in the right direction from XML. XML is an inelegant, verbose, over-specified mess, a relic of 90s thinking. JSON is definitely an improvement.
HTPP's fine, I guess. It's certainly available everywhere, and saves one from writing a bunch of tiresome parsing code. But that's really an indictment of the current state of our technology. Popular languages should make it easy to read structured data out of a socket (with some sort of max length to prevent DDoSes) & write structured data to a socket. Since they don't, HTTP is an okay compromise. It's a bit heavyweight, but it gets the job done.
Well, technically both are valid approaches which get messages from one user to another in a federated way. Besides that, XMPP is an IETF standard which has proven it can adapt to changing requirements. Matrix, on the other hand, is a young project with more momentum and more consistent software landscape.
That said, I have quite a biased view on the topic, as I kinda blame the Matrix devs for splitting the federated communication community. XMPP is quite capable of delivering what everyone expects it to do. But lately, developers seem to be more interested in the new Matrix protocol (just because it is new). At the same time, many XMPP clients do not implement all of the latest features the standard has to offer and I wonder what the world would look like if the Matrix devs would have spent their energy on improving existing XMPP clients instead of inventing another protocol.
we really don’t, fwiw. we have zero money assigned to marketing and nobody working on it, unless you count me chatting on HN and twitter, or our designer or the guy who updates the matrix.org/blog?
It is possible to consider them different categories of things. XMPP solves the IM problem but conferences with lots of users are a bit awkward if you use a XMPP MUC server. Conferencing is to some extent a bag on the side of XMPP. You would probably be better off just using IRC.
Matrix is primarily about dealing with the issues of conferences with lots of users... I see it as more of an improved IRC than a replacement for XMPP.
The federation requires a publicly accessible server to work. I got a cheap domain name, pointed it to my public IP (with DDNS), and port-forwarded to my server. Works fine for me.
Is anyone else increasingly uncomfortable with the "we'll solve the certificate problem by deferring to centralized registrars that surely keep their keys private from state actors."
I mean, this is potentially not a risk if there is a recognizable way of communicating low-bandwidth fingerprints of the next encryption level, like ZRTP verification on voice. But note how WebRTC has done the same thing? And efforts to solve the problem are talked about and then, somehow, nothing ever happens with the standards.
Matthew's talk at FOSDEM [0] was really nice. I've been using Matrix (mainly trough Riot) for a while, and encouraged my technically-minded friends to jump on it.
However, I would like to get my family to use something else than WhatsApp (which I refuse to use). I'm planning to do so, once I can sort out the following:
- Riot is nice if you have a lot of high-density rooms (Fractal's "Banquet" use-case [1]), but not really there in terms of UX for small rooms with my family members
- I would like to self-host if possible. However, I need to ensure that the server is reliable enough, and synapse seems to be quite resource-hungry.
Regarding the first issue, it seems that France's Tchap would solve it nicely, from what we were shown at FOSDEM. Unfortunately, the Readme in their repo is still Riot's, and it would seem that I have to build it myself [2]. I'll look a bit more into that nevertheless, and it should improve by June, from the article.
Regarding the second one, someone recently linked to this Gnome mailing list archive [3] where (in the reply) Matthew details a bit more his (then) long-terms plans for homeservers. Having one homeserver per device would solve most of my issues pretty neatly. I am not sure how far it is in the roadmap.
I am also curious to know what's the status on that specific discussion topic: I was discussing just this the otherday on #postmarketos-offtopic:matrix.org [4]. I was interested in having a unique matrix daemon on a phone operating system to provide push support, maybe as well as a Matrix protocol broker.
Otherwise, for self-hosting with ~10-200 users, it looks like synapse has shed a lot of weight recently, and other homeservers implementations seem to be picking up steam, so we'll see how that goes. I am not sure how synapse would handle a dynamic IP
For now, my gripes with the ecosystem are the following:
- There doesn't seem to be easy ways of migrating: accounts, homeservers (including address and implementation, ex. migrating to/from synapse, Dendrite, Ruma...).
- No easy way to manage multiple identities: work, home, etc. Multi-account clients or community-bound identities could probably help solve this. Ideally, it would be the later, and my account would be on multiple homeservers (backup plan for availability).
- The search functionality is really lacking on most clients. No way to search my own messages, or at a specific time, in a specific community, etc.
It's also kind of fun to have both COI (chat over IMAP) and Matrix making the front page at the same time :)
A bit off-topic, but my registrar doesn't provide an API to update the DNS records on their servers. As a workaround, would there be a free dynamic DNS with an API out there? I don't care what the address would look like, as I would just use it as a CNAME record.
On the riot side, we're trying to do our best to make it support both Barbecue as well as Banquet use cases (assuming that's not a contradiction in terms).
In terms of other points:
> Having one homeserver per device would solve most of my issues pretty neatly. I am not sure how far it is in the roadmap.
> - There doesn't seem to be easy ways of migrating: accounts, homeservers (including address and implementation, ex. migrating to/from synapse, Dendrite, Ruma...).
The only advantage Matrix currently has comes from it's relative obscurity. It has ONE implementation. Once things start inevitably emerge, it'll run into all the same problems that truly distributed protocols have.
it's true that there's only one implementation that's production ready. however, there are several which work sufficiently that they can federate with it (dendrite, construct) which look to be on the right path. it'll be interesting to see if that all falls apart when they come of age; let's see :)
This probably is my own problem but I totally hate threadless communication for whatever that goes beyond a personal chat for 2 people. IMHO every meaningful collaboration needs threads.
I realize this is a somewhat dismissive answer, but the entire point of Matrix is that it's an open specification. The Matrix team is putting a ton of work into guides that show you how to build support into your own apps. The protocol is being designed, from the ground up, to be easy to implement.
I'm not saying you personally have to build a mobile app. I am saying, in the grand scheme of things, if this is genuinely something that matters to a bunch of people, any one of them can build a mobile app and solve your problem.
There are tons of people on HN that hate Electron. If this is actually a real problem, then someone will eventually solve it, and it'll be fine. On the other hand, if a large, sizable community of native developers with tons of experience on the platforms they want 1st-class solutions for don't ever get around to solving it... then it's probably not a real problem.
Riot-web is a really nice app. Drop it on any web server and you're done. I use it all day long to talk to my family on a self-hosted, non-federated matrix instance. If you use linux, Fractal is a pretty good option for a desktop application. The latest release is "beta" but very usable.
Curious if there was a reason you chose to self-host as opposed to using a public one on just starting your own room (I assume this is possible in the same way channels are in IRC)?
What was the drive to use 1, self-host and non-federate an instance of Matrix over another platform, and 2, why? With family especially, I would assume a simple WhatsApp/Signal group would have been easier for adoption.
My extended family of 16 which ranges in age from 5 to 85 uses this Matrix instance. We didn't want pictures of our young kids on Whatsapp (Facebook) servers. These young kids and grandparents don't have smartphones so Signal isn't an option. Also, many of us access Matrix on other devices and computers other than phones.
Thanks. I've been tossing up setting up a forum of sorts for some close friends, but I've been going back and forth on the two extremes; an obscure telnet-only accessible BBS for the nostalgia, or a Matrix/Riot page for the ease of use.
the only reason we release the electron app is because it’s practically zero work (and it was a community contribution in the first place). in practice much of the team work on the native mobile clients. hopefully proper native desktop apps will mature from the community, or worst case we’ll get involved as the core team.
I haven't tried Matrix yet, but I've tried some other chat platforms like Telegram and Discord, and was really disappointed with them compared to IRC.
I had to use their closed-source, bloated, binary blob GUI clients, couldn't logs the channels I was in (and so relied on having to log in to their servers to get backlogs, which was super annoying), and needed invites to get in to channels.
Apart from the superior multimedia capabilities of these clients, I saw absolutely no advantage of them over IRC clients (which could do useful things like logs all mentioned URLs and mentions of my nick to separate, logged tabs, and which I could run from the terminal and even from within Emacs).
I really hope Matrix is better in this regard, and I'm trying to keep an open mind, but so far attempts to create next generation chat services have been really underwhelming.
I find it compares favorably to IRC and XMPP. File transfers and offline messages and encryption "just working" without having to check if my client, other persons client and the server(s) support it (or having to bring helpers into the mix) is worth a lot.
using matrix via weechat using the new python weechat-matrix (https://github.com/poljar/weechat-matrix) plugin should give a very convincing IRC on steroids experience; it even has e2e encryption landing. The emacs matrix client (mclient.el) is also in active dev again.
Riot is also good, but probably too bloated for your tastes :)
It's a shame that the Matrix website listing clients[1] don't mention weechat-matrix and instead mentions the outdated Lua plugin[2] that doesn't support Megolm at all.
I've been using Riot for a few years and it's nice, but it would've been nice to know that there is a modern Weechat plugin implementation (I was half considering writing one myself).
It's also super neat to see that they wrote their own Python Matrix client library[3], which is something I also needed for another idea I'm working on (the library linked to from the Matrix site also seems to be less suitable than this one).
Thanks for pointing this out - the website is updated now to include poljar's work. (We did feature it on the blog but important to keep the projects list updated too!)
There are several competing Python libraries, those you mentioned plus https://github.com/tulir/mautrix-python. We'll do a round-up and review of the options soon.
Looking over the list of Matrix-related projects [0], what I'm finding a bit concerning is that only one of the server implementations (the official Synapse codebase) appears to be anywhere close to production-ready. All the others look like they're either abandoned experiments, or barely in early dev (Dendrite).
The feature blurbs and API specs make it sound relevant to a project I'll be working on, but I'm concerned that there's only one viable-ish server implementation. I'd feel a lot better if there were several valid working servers in various languages by now.
The reason why alternative server implementations are lagging behind is because there was a very recent push to 1.0 the entire spec (specifically because of the French government deployment discussed in TFA). They said they'd emphasise alternative implementations afterwards in the FOSDEM talk Arathorn gave earlier this month.
Up until very recently we'd been postponing work due to immaturity of both Rust and the Matrix spec. Now that all the Matrix specs have had stable releases, the main blocker is the maturity of async/await and support for it in the library ecosystem. Since Ruma uses nightly Rust currently, we don't need async/await to be stabilized to proceed, but it does need to be far enough along that it has been adopted by all the major components of the Rust HTTP ecosystem. I'm guessing we've got about six months left until this happens.
Putting my "tech lead evaluating tools" hat on, I like the idea of a single-file binary that can be easily deployed. That said, seeing that the last commit was 2 years ago isn't encouraging :( Given that I'll likely be seriously evaluating potential approaches for our system design within the next 2-3 months, it doesn't look like Ruma would be a viable option for our situation.
Matrix is totally open sourced. Server side and the official client (Riot) can be deployed anywhere under your own control.
Also, deploying a bridge you can connect Matrix and IRC rooms, creating a hybrid channel mixing Matrix and IRC clients in the same room. It's pretty cool.
While most of your complaints is valid for Discord, it doesn't hold for Telegram, which IMO has high quality clients, in terms of native look&feel, lightweight, and general UX.
Matrix on the other hand is like having everything half-baked. This made it an non-option for daily use and I ended up moving to other IMs and a bouncer for IRC.
In my small bubble of tech news, France has popped up a few times. Found out recently that they are officially[0] using the privacy-respecting Qwant search engine. Several weeks ago, I learned that they have planned obsolescence laws[1] which makes them a pioneer in this area (from what I understand).
There's also an active non-profit organization using FOSS to create alternative, privacy-respecting, solutions to Google products (framasoft[2]). I mention this last one because I haven't come across a similar major undertaking (or similar mindset) in too many other countries.
Now they are evaluating Matrix for their communications needs. I can understand the importance of countries, nowadays, not relying too much on the services of companies tied to a specific country (namely the US) but I wonder what else is different about France? What else are they engaged in re: FOSS, privacy?
Or am I reading too much into this?
[0] https://en.wikipedia.org/wiki/Qwant
[1] https://www.bbc.com/news/world-europe-42615378
[2] https://framasoft.org/en/
French citizen here. For as long as I can remember, there's been a strong will in the French FLOSS communities to develop local alternatives to the ever-expanding reach of the FAANG/GAFAM, for many reasons. The obvious one being the export of data outside actionable jurisdiction, but it could also be explained by differences in ideology.
As for what else we're doing, there's La Quadrature du Net (LQDN)[1] which took part in the recent Google €50m fine, some projects by concerned citizens to keep a watch on politicians[2] and tracking in mobile apps[3], but one of my favourite things comes from the increasing will to release "OpenData" (public data sets from various sources)[4] to let collectivities, regions and smaller units build tools to solve their local problems.
[1] https://www.laquadrature.net/en
[2] https://projetarcadie.com/ (in French)
[3] https://exodus-privacy.eu.org/en/
[4] https://www.data.gouv.fr/en/
I would also add that there's a rich ecosystem of extremely well-trained engineers coming from the Grandes Écoles system.
The result is a lot of top-notch contributors who get involved in FOSS projects in their 20s.
France's position on this is essentially nationalist; local surveillance of the internet is strong following various terrorists attacks, and there isn't quite German levels of distrust of state security apparatus. But on the other hand they are outside the five eyes, run an aerospace and tech industry that has to deal with US industrial espionage, and are aware of the cultural hegemony of English language media.
(People seem to think that France doesn't have a tech industry; it very much does but little of it is consumer facing)
Protecting one's interest is not nationalist, as long as it's not to the detriment of other nations.
>Nationalism is a political, social, and economic ideology and movement characterized by the promotion of the interests of a particular nation,[1] especially with the aim of gaining and maintaining the nation's sovereignty (self-governance) over its homeland.
https://en.wikipedia.org/wiki/Nationalism
>a sense of national consciousness exalting one nation above all others and placing primary emphasis on promotion of its culture and interests as opposed to those of other nations
https://www.merriam-webster.com/dictionary/nationalism
Oh, that makes more sense. The first definition seems nearly self-evident; what nation state doesn't want to protect its own interest? But there's certainly a distinction in promoting oneself above others.
The very concept of a national interest is somewhat nationalist, but then I don't believe that "nationalist" always implies "to the detriment of other nations". It often does, due to zero-sum thinking, but it's not intrinsically necessary to the concept of nationalism.
(also, exercising nationalism against a colonial power may be to its detriment but also be morally good. This obviously does not apply in the case of France, which itself is a colonial power)
I was looking up nationalism on Ambrose Bierce's Devil's Dictionary, but didn't find it (probably too sensitive a subject at the time), so here's its definition of politics:
> POLITICS, n. A strife of interests masquerading as a contest of principles. The conduct of public affairs for private advantage.
This is hardly relevant, but I'm using the occasion to share the great piece of satire that's Devil's Dictionary. Here's a few others:
> OCEAN, n. A body of water occupying about two-thirds of a world made for man — who has no gills.
> POLITENESS, n. The most acceptable hypocrisy.
> PERFECTION, n. An imaginary state or quality distinguished from the actual by an element known as excellence; an attribute of the critic.
Edit:
> PREJUDICE, n. A vagrant opinion without visible means of support.
Nationalism was definitely not considered a sensitive subject in Bierce's time. It was considered the default.
You might be right, I wouldn't know. I guessed that because I found that a satirical dictionary not having an entry for words nationalism or nation more difficult to believe.
Here's my suggestion:
NATIONALISM,n. Discrimination which is based on geography and thus obviously superior to RACISM and SEXISM which are based on biology. Can be further refined to NEPOTISM and ultimately SELFISM.
I work in a French public lab, and the policy here (and in many if not most other public labs) is to produce FOSS based on our research. It has always been more or less a fact, but this is becoming an official policy, AFAIK: make it FOSS unless you have a good reason not to.
Regarding privacy: not my field of expertise, but France is far from paradise here, thanks to the terrorist attacks a few years ago.
Also last October ANSSI, the National Cybersecurity Agency of France, released the sources of CLIP OS, a Gentoo-based hardened, multi-level operating system. https://clip-os.org/en/
They also have recently opened a public discussion on how to build secure apps in Rust: https://github.com/ANSSI-FR/rust-guide
My first use case of FOSS was with Framasoft. Back in 2009. I had my first USB key, and downloaded all the needed softwares on my key[0] , notably SumatraPdf, OpenOfice and Mozzilla.
[0] https://framakey.org/
I also used it a lot in high school, just for escaping the pre-installed Internet Explorer it was worth it.
I agree. Check this: https://en.m.wikipedia.org/wiki/Minitel
I think other European countries had their own minitel, UK had https://en.wikipedia.org/wiki/Teletext for example
We had a big teletext offering in France too at some point. Minitel is not it. Minitel was a modem+terminal in your house. So, it was bidirectional, secure, and had incorporated billing. You were able to do all kinds of things with it: enter chatrooms, order stuff (like train tickets), register/check the results for some exams, etc.
The British counterpart to Minitel was not Teletext (a one-way system that was present throughout Europe anyway), but Prestel. It wasn't hugely popular, not on the scale of Minitel, but it did have the UK's first highly publicised hacking case leading to changes in the law: https://www.bbc.co.uk/news/technology-36306419
France also wants to break Internet and culture sharing (and code). There is a new law project in EU that will give the power to big companies to control what we have the right to publish, and that makes the host platform legally responsible of what users post.
https://juliareda.eu/2019/02/article-13-worse/
There is lot of private initiatives to make great things, but no state vision to make things right. The only value they see is economical, but not for the people.
The gendarmes have also switched to linux. IIRC, the main reason was that is is cheaper.
Outside of costs, an army / police using a foreign-develop proprietary operating system for their everyday internal need is insane.
I always wonder why foreign countries by the French Rafale. Same problem: What can we trust from a foreign entity?
I always wonder if the Mitterand / Thatcher / Exocet story is true: https://www.theguardian.com/world/2005/nov/22/books.france
I don't think it was, she was playing Mitterand on emotions, which most french guys have way too many and are easily controlled by them (I see it every single effin' day around me in many ways).
If she would go nuclear on Argentina due to that skirmish and few marines dying in regular acts of war (however sad it is, this is business-as-usual during war), she would have alienated UK to every single country in the world, destroying it on many levels. And also go down in history as one of the most horrible rulers in history of mankind.
Not something any power-and-approval-hungry sociopath (sorry, 'leader of the nation') wants to leave behind.
> emotions, which most french guys have way too many
Gross generalization.
Oh, the nuclear threat was in retrospect almost certainly a bluff, what I was more questioning was whether the conversation happened, and whether Mitterand did in fact hand over any kind of remote disarm codes for Exocet missiles.
> she would have alienated UK to every single country in the world, destroying it on many levels.
That really isn't realistic. Some allies might have been unhappy with Thatcher for normalising the use of nuclear weapons, and might even have openly criticised the UK. But France, the US, the Commonwealth nations would not just desert an important ally: how would that benefit them? They would have retconned the story and we'd all believe now that Galtieri was the next Hitler and would have subjugated the whole hemisphere if not for Thatcher's brave initiative.
They can't, but they also can't afford to have a fighter that's significantly inferior to their adversaries. So they find the country that can offer what they need, which they can trust most (or don't trust least, depending on your perspective).
It's not like every country has the capacities to produce fighter aircrafts on its own.
Also, having intertwined economies is supposed to help maintain peace and foster prosperity.
depends on how the intertwining is done, a lot of international instability is due to foreign companies taking a bit too much advantage of other places
Dassault already won the trust of half the world with the Mirage.
It's a slightly different problem as those countries that buy the Rafale do so because they don't have (or aren't willing to develop) the means to build their own planes.
So to them it's mostly a matter of choosing which foreign entity to trust and at which cost, between the US, Russia, China, France, and a handful of other states with lower performing but cheaper equipment.
Arguably it is easier to check a few jets you buy once than software used by many thousand persons on different machines with differnt versions and monthly updates.
I am pretty sure that especially in weapon systems it is quite common for customers to demand special changes, services and insight.
There's also big economic incentive for many countries to just go to FOSS solutions for their needs. It alleviates the need for self-sufficient local private corporations or huge public programs. Nothing speaks louder to a politician than saving on their budget. Or making administration easier (which is likely to be incredibly important in a country with a bureaucracy as Byzantine as France).
Now that the big hacker/open source FUD is mostly done for, I think you'll see a lot more countries deploying FOSS tech as a matter of fact an not as an ideological statement or an avant-garde trial.
France also recruits hackers as part of their beta.gouv.fr community, they are pushing things forward to more open source from the inside of the government. Many of them are not only at betagouv, but also at laquadrature or framasoft and the like.
slight counter point, I think I recall education having a recent contract with Microsoft which wasn't super OSS to say the least.
I like the idea behind Matrix, but hosting it is really a pain. I've given up on it until it's a simple `docker-compose up -d` away from running a full instance.
To get back on topic, France has really got its FOSS movement moving. There are a TON of Mastodon and Peertube instances located there. It's admirable.
Being similarly frustrated with how complicated it is to set up, I've created an Ansible playbook to automate it all (and run all services in containers): https://github.com/spantaleev/matrix-docker-ansible-deploy
By default, it sets up Synapse and a bunch of other services around it that are necessary to really make it useful (Postgres instead of the default under-preforming SQLite; mxisd as the identity server; STUN/TURN server for WebRTC calls; riot-web; various bridges; etc)
Thank you for this. Very easy to use. Easily saved me a few hours of work.
That is really useful. Thank you!
I dont know... i have been runing one instance for about 3 years and it is just
apt install matrix-synapse
and changing one yaml config to suit my needs
i am sure there is a dockerized version
How much RAM does it require for 1-2 users? I have small VPS and can afford 10-20 MB of RAM, but Python terrifies me.
I ran a little test last weekend. I got a 1 CPU / 2GB RAM virtual machine from a cloud provider and deployed Matrix/Synapse on it with spantaleev's Ansible script.
I created 100 accounts for chatterbots. (This is not federated to the main Matrix network -- just local.)
The VM showed some lag when the chat bots connected and started inviting each other to their channels. But once all the invite sending/accepting settled down, it's been pretty smooth. It's randomized, but I think each channel has about 18 or 20 users.
The whole thing is using about 900 MB of RAM, and that's including everything -- CentOS, several containers, the Postgres database, Synapse, nginx, etc.
the RAM usage depends on the size of rooms the users join, not the number of users. synapse typically takes around 1GB of RAM (allocate 2 to be safe), but we are working on that.
2 GB of RAM for a chat server?!!?
From what I've heard here from people using the Slack desktop client, 2GB is now normal for a chat client
I think it is perfectly reasonable for a client to use more RAM than a server, having to display a GUI and all. I'm thinking of IRC servers vs. clients. (Certainly not 2 GB, but that's another matter.)
There are a few alternative server implementations under development. Personally I'm hopeful for Dendrite (written in Go): https://github.com/matrix-org/dendrite
Yeah i am also terrified by python. Before synapse was in apt i had to instal it using pip and virtual env and it was nightmare for me.
I run it on some 3usd vps i dont remember 1gb ram i think and use sqlite (its very portable this way). For about 20 people it works great.
It is not exactly efficient but overall still cheaper and better than other solutions ive found.
I've been running two matrix (synapse) instances for about 2 years and it's been pretty painless. My "personal" instance is hosted on a dedicated server running Ubuntu, and the package works just fine. The other one uses a slightly modified version of the code, and installing/updating it via pip is trivial. What part of the process did you find tedious ?
we’ve bundled official docker for synapse for a year or so now, and it really is as simple as docker-compose up -d? would be good to understand what’d going wrong.
I apologize for commenting on it before checking the situation: I retried it now, and it seems the situation has improved a lot from last time I tried. It's still far from a simple `docker-compose up -d` (I had a few issues with TLS because I didn't understand how to generate the key, opted to disable it and reverse proxy it via Apache2+letsencrypt), but it's doable in a relatively short time. All that I have left now is to setup a frontend (ie. Riot).
Footnote: IMO, the barrier for adoption for this kind of services has to be the lowest possible if it wants to gain any kind of traction. Mastodon and Peertube are good examples of this: docker-compose.yml in the project root, and in < 1 hour I got everything working by just setting a couple configuration values that were already in the environments section.
I figure that there is a lot of work going on right now so this might not be in the top priorities, but I really hope Matrix gets there soon.
Keep up the good work!
You really should try out the guy's Ansible playbook linked elsewhere in this thread. It automates setting up the database, the reverse proxy, the Let's Encrypt certificates, pretty much everything. You run a couple of git commands, a couple of ansible commands, and you're done. It's amazing.
woo, glad that it's getting better. riot should be as simple as cd /var/www/html && wget https://github.com/vector-im/riot-web/releases/download/v1.0... && tar -xzvf riot-v1.0.1.tar.gz :)
Could you elaborate on what kind of troubles you have with the hosting? So far I host only an XMPP server but I would like to know what kind of trouble I have to expect if I wanted to host a Matrix server too.
> Because Matrix is inherently decentralized, no single server "owns" the conversations; all traffic is replicated across all of the involved servers. [...] Matrix is more like Git than XMPP, SIP, IRC, or many other traditional communication protocols.
The Matrix protocol is well worth the read. JSON-LD is a bit of a nightmare to work with, but the gist of it is a solid concept; it has drastically changed my approach to software design.
I'm considering evaluating Matrix for some upcoming projects I'll be working on. Thus far I've just skimmed the front page and the FAQ.
Could you expand on what you found particularly compelling about the protocol / API, and also how that's changed your software development approach?
The very high-level view is that Matrix is a set of protocols for syncing messages and state between servers. Matrix is to XMPP what NNTP is to SMTP. This makes multi-device and disconnections much easier to handle, because all you need to do is to wait for the messages to eventually arrive; this is in contrast to XMPP which favors direct routing of a message and synchronization is second.
In my own view it's a much more robust way of architecting communication: the server(s) should assume that remote parties will be off, and remote parties will come and get what they want at their own pace and time. Maybe they won't receive a few messages immediately but can immediately retrieve multiple when needed. With a stretch you could see a parallel with Kafka: instead of trying to send stuff to consumers as soon as it is produced, just store it, and when clients are up they'll process stuff.
I agree. One could use the Matrix specs to build some sort of message queue (using rooms) where human (text, markdown) and machine (json-ld) could communicate and interact..
It federates itself like SMTP does, I guess? If you translate and rotate their solution (abstractly speaking) you arrive at some very interesting ways to create a federated website/app/thing. Inspiration is always a really hard thing to nail down.
From a technical standpoint, there are six specifications (Matrix, Mastodon, XMPP, SIP, SMTP, Microdata) that have gotten the "future of the internet" partially right, in my opinion. Some union of the them, excluding the unfortunate bits, is likely the email/Twitter/Facebook/what-have-you killer. Putting that in consumers' hands and getting them to use it is another story, but we do have the starts of a technical/back-end answer.
For example, you could embed text document edits inside of Matrix messages as Microdata (ignorantly spamming someone aside with thousands of character edits aside). Is your spouse doing their taxes? Send them a chat message with Microdata explaining to the form where the attached document goes.
As a general goalpost, WeChat (having circumvented federation problems) in China is a really great example. You can pay for food at a hotdog stand on the street with chat. Uber merely facilitates communication between taxis and commuters. Whatever the project(s) you are referring to, software usually ends up solving communication problems. Recursively simplify your problem, ultimately realize how communication fits into it, then work your way back up to your initial idea. Federated IM is ludicrously powerful and, especially with graceful degradation, can lead to some sales leads.
One problem with upvoting comments instead of saying “+1” is the parent can’t see your upvote. But I’d like to explicitly say: I am also very interested in the answer to this question, if you have the time.
(Matrix is just JSON, we don’t use JSON-LD)
I got my wired crossed. I'll leave the comment up, as I do think that Matrix is a masterpiece in protocol design.
Not even https://en.wikipedia.org/wiki/Matrix_(protocol) describes big, meaningful benefits over XMPP.
Yes, it does eventual consistency replication, like NNTP, but that's not an incredibly important feature.
well, perhaps someone unaffiliated with Matrix or XMPP should update the wikipedia page to explain. https://news.ycombinator.com/item?id=19223963 is a very good summary, for instance.
From our perspective, the room replication is absolutely critical - it means that the network can partition and the servers can come up and down without the room being disrupted at all. It's the opposite of a MUC, where if the server hosting a MUC is inaccessible or goes down, you're screwed.
It can even be bad for security: e2e encrypted messages are still replicated and stored on the servers. 30 years from now they might be decrypted by faster CPUs.
Encrypted 1:1 messages should not be stored on servers! They should be sent between clients p2p stile or at least forwarded by servers without storing them.
If you recall that the NSA is already storing large amounts of internet traffic for later decryption, whether or not some server stores it is mostly irrelevant. Maybe you're worried about other lower-tech attackers, but I don't think that Matrix servers are going to keep 30 years of chat history (I imagine most Matrix servers are going to eventually use default retention policies). Not to mention you can run your own homeserver if you don't trust the operators of public homeservers.
Storing 1:1 messages (noting that Matrix doesn't differentiate between group chats and 1:1 chats) on a server is beneficial because you might not want to lose your entire private chat history with your family and friends whenever you lose a device (source: this happened to me multiple times with Signal -- which has an awful backup system that I didn't use because it simply doesn't work properly).
Now, there is obviously cases where you don't want the server to keep your messages forever -- and then you might want to have retention policies and so on. But I don't really agree with the security argument, since the most obvious attackers already likely have your messages, and it sacrifices a lot of convenience that most people expect (my partner didn't expect to lose all her Signal messages when her phone died unexpectedly).
the reasons you need encrypted messages stored on the server are: * to synchronise them between multiple devices * if you lose your device, to have a hope of recovering your history * to be able to search them (either homomorphically or via a search bot you run)
however, we're adding message retention configuration currently to let you limit how long your messages get persisted for (whether they're encrypted or not): https://github.com/matrix-org/matrix-doc/blob/matthew/msc176...
Forgot about json ld.. something is odd. in the xml days there was xlink/xpath.. now it's the same but with json trees. We're looping over syntax
The FOSDEM video: https://fosdem.org/2019/schedule/event/matrix_french_state/
I finally got around to brushing off the year's worth of dust that had accumulated on my Matrix account and signed in to Riot on my phone, as well as their web client. I was pretty pleased with how easy it was to connect to a Freenode channel. So far it seems to be a decent experience, I'm looking forward to using it over the next little bit.
Things are still going strong for open source in France (despite de occasional setbacks) since France was rated in 2008 the no 1 country in the world in terms of open source adoption by Georgiatech:
https://web.archive.org/web/20090424052832/http://www.redhat...
https://web.archive.org/web/20090520231136/http://www.redhat...
More info (in French): https://cnll.fr/media/etude-2017.pdf (with figures for the FR, DE, UK and rest of EU markets on slide 4).
Recently I'm hearing more about Matrix. Does anyone have any input as to the pros and cons of Matrix vs xmpp?
It's quite subjective, but my view is Matrix is what XMPP would like if it was written today.
The main advantages are it is using JSON instead of XML, and HTTP instead of custom protocols so it can work directly from browsers and with lightweight mobile clients. It also has a lot built into the core protocol, where as to get XMPP to do anything useful you will need to use a lot of extensions (and ensure the server and all clients support them).
The only con is it's still a relatively young project. I'm not sure I would want to rely on it as my main form of communication in a company just yet, but for personal usage it is fine.
> It's quite subjective, but my view is Matrix is what XMPP would like if it was written today.
That's indeed a subjective view.
> The main advantages are it is using JSON instead of XML, and HTTP instead of custom protocols
The Matrix dev said a day ago that "It's NOTHING to do with HTTP+JSON": https://news.ycombinator.com/item?id=19217412
Also, what custom protocol are you talking about? XMPP works on top of TCP/TLS (or Websocket). Those are the IETF standards. In fact XMPP doesn't require an additional layer of HTTP at all.
> with lightweight mobile clients
Where are they? Anything even remotely comparable battery-wise with Conversations (an XMPP client)?
Not to mention that Matrix has a terrible server implementation which requires several GB of RAM just to join matrix.org room.
> It also has a lot built into the core protocol, where as to get XMPP to do anything useful you will need to use a lot of extensions (and ensure the server and all clients support them).
I fail to see how having a monolith core versus splitted specs has to do anything with code written to support that. Of course, initially every implementation will strive to implement full core (that was in XMPP in 2000s), but when the core evolves you have absolutely no guarantee that every developer will implement all new parts of the core. How is that addressed in Matrix?
> How is that addressed in Matrix?
Well that's quite easy, since hosting a server is a resource hog, most people are still on matrix.org, which gives it a special status in the ecosystem (even more special than jabber.org has been in the early 2000s fox XMPP). This allows them to "move fast and break stuff" on short notice (a few months), to bring the protocol forward and force people to upgrade. In the federated XMPP ecosystem, they essentially have to come to a community consensus between developers, servers operators and all other relevant actors to write a manifesto or a new spec that says "stop using $thing at $date".
In my opinion matrix, while being open-source, federated and easy to write clients for, is still a half-locked platform because essentially the matrix.org server is "too big to fail", and the matrix team is the only one who can e.g. offer consultancy over the protocol because nobody else can have a long-term view of its future evolutions (of course the matrix people are nice, and you can discuss with them, but that is still not a standards body).
> is still a half-locked platform... but that is still not a standards body
Exactly. That's why I always stress the importance of the IETF. The whole point of the IETF is that you cooperate with people, deal with opposite opinions, accept criticism, come to agreement, develop a compromise and produce a high quality absurdly documented standard. In Matrix bubble (and any others, see cryptocurrency or p2p community for example) they are the only one who makes the decision. They don't care on other opinions. If you disagree with them you're asked to stop "fighting", "focus on interaction", "understand their goals" and other meaningless stuff like "let the best standard wins" (when in reality the whole point of the standard is to cooperate). Formally speaking they try to substitute a "standard document" with an "open document" and people kinda swallow this because they don't see the difference.
this is categorically not true.
> In Matrix bubble (and any others, see cryptocurrency or p2p community for example) they are the only one who makes the decision. They don't care on other opinions.
You can see our governance model at https://github.com/matrix-org/matrix-doc/blob/matthew/msc177... and see that we do everything we can to ensure that the wider community can contribute to the spec and steer it in the right direction.
And fwiw, we'd be perfectly happy to contribute the spec to IETF or W3C or whoever once it's relatively stable, just like XMPP did.
Rather than burning all this energy spreading FUD about Matrix, perhaps it might be better spent improving XMPP? :/
> Rather than burning all this energy spreading FUD about Matrix, perhaps it might be better spent improving XMPP? :/
Yeah, didn't I say above about such kind of arguments?
> You can see our governance model at https://github.com/matrix-org/matrix-doc/blob/matthew/msc177.... and see that we do everything we can to ensure that the wider community can contribute to the spec and steer it in the right direction... And fwiw, we'd be perfectly happy to contribute the spec to IETF or W3C or whoever once it's relatively stable, just like XMPP did.
I'm not a lawyer to read such documents. Just "contribute" your core to the IETF, prove me wrong.
That's when committees and standards bodies work well.
When they don't, you get OAUTH2.
https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45...
I might be mistaken, but from what I read the main addition is that all peers replicate the full state.
If you have a dominant xmpp server (like gmail was) that removes xmpp support, its users have the start using other clients to connect to it or start a new social structure from scratch. In essence this makes the xmpp server a dominant player with leverage.
If gmail had used matrix when it pulled the plug all interactions (who knows who, how to route traffic, chat history) would have been replicated at the peers so it would just have removed google’s servers from the equation. The people who had been using it would continue uninterrupted.
You're both right and wrong.
In both cases, if users have an account on gmail and are using it, and gmail pulls the plug, then they can't use it anymore and can't migrate. The history is still there in the case of matrix, but they can't reuse the same account.
However if another user is homed on another server, they would still keep the knowledge and history on their side: gmail did pull the plug on xmpp, yet people are still using it. Their server still know who their contacts are, what room they're usually in, etc...
Matrix does have the advantage that the chat history is fully replicated on all homeservers so it makes history retrieval much saner, but that's it. Matrix doesn't route traffic (messages go from sender's homeserver to recipients' homeservers, that's it) and doesn't share client's information with the whole world.
Too bad. Well consider this a feature request then ;)
> The people who had been using it would continue uninterrupted.
I'm not sure about that. If the main matrix server disappeared today that'd be problematic. Yes, you'd have history locally but the same can be said for any native client that stores history locally.
As far as I know there is no way to migrate matrix history now. Is there? (genuinely curious)
for rooms which span servers, the history is already migrated by nature of the protocol being decentralised.
for everything else we’re working on decentralised accounts via MSC1228.
there are also migration scripts and tools to move you between accounts on different servers today (like email).
> I'm not sure about that. If the main matrix server disappeared today that'd be problematic
This ^^ Currently a large amount of users (I'm told around a half, but I'm not sure) have matrix.org as their home server. So Matrix is effectively building a power-law network with all its drawbacks: when the "power node" of the network goes down the whole network falls apart.
To be fair, this is somewhat inevitable in the initial stages, before a reasonable spec is released. Many people, like me, are just "sitting on the fence" and test-driving Matrix via their matrix.org server, until there are reasonable assurances that deploying our own Matrix server will come without too much hassle.
After Synapse 1.0 is released (sometimes next month, IIRC), I'm definitely deploying my own homeserver, and federating it with the rest of the world.
FWIW, I've been running Synapse since 0.20 or so (for at least 2 years now), and there has never been a breaking change in the protocol as far as I'm aware. I had to read release notes at some points to get the upgrade to work, but it was mostly Python-library-related stuff IIRC.
Well they are making one big instance nothing else. Also unfortunately it means that you can't possibly federate with matrix.org. I've been running small otherwise perfectly functioning instance for few years for my circle/work as slack alternative on small vps. One time i did the amazing mistake of turning on federation with matrix.org. It immediately killed my servers performance especially when i joined some popular channel. The channels probably have more messages than my whole server combined. And it works the other way too - matrix.org is like sponge sucking other instances.
I guess this is the real problem for me - i would love to federate but i can't possibly police or enforce what servers/channels are small enough that my users can join them.
This isn’t anything to do with the size of the matrix.org server; just that synapse needs to be more resource efficient and we need to limit the sizes of rooms small servers try to join. we are doing both.
I can't see any advantage in using JSON and HTTP for a protocol. JSON shines for ad-hoc, untyped, structured message payloads rather than the strongly-typed semistructured text payloads possible with XML/SGML, and HTTP wasn't designed for federated protocols. It seems more like a fashion thing to me.
I kind of agree with you, but I'll add that XMPP usage of XML is weird enough that it makes it hard it use a normal XML parser / producer. Honestly I really wanted to like XMPP. I read all the specs at the time, even started to write some code, but all I can say is that it really sucks. I haven't looked at matrix yet, I hope it's better
Indeed! I was in the same boat - also started writing a client, but wasted too much time on the stupid XML stream idea.
Basically, chatting is message oriented, but the XMPP inventors thought it would be neat to start the connection with a tag like <beginconversation> which would then be dangling for the whole connection, preventing the use of a simple DOM XML parser (remember this is many years ago) for each message.
Any XML parser that I know can parse XML in a stream, that's all you need to handle an incoming XMPP stream.
Just an example, here is the XML parser that I wrote in PHP https://github.com/movim/movim/blob/master/lib/moxl/src/Moxl... (127 lines), it basically handle the stream as an input and fire SimpleXML (can also be DOM XML) on the other hand.
This can handle thousands of XMPP messages (called stanza) per second :)
Can it handle plaintext XML suddenly becoming TLS encrypted? Because that's also what happens on any XMPP connection. If it can, then great but I guess it's more an exception than the rule
fwiw, in Matrix, to send a message, it's:
and to receive messages it's: Hopefully this ends up being quite easy to work with :)and for XMPP
No need for a token, the socket you're in is already authenticated :)Also flexibility can be good but XMPP is way too modular.
You don't have to implement all the modules :p There is some basic ones that you need (see XEP-0412: XMPP Compliance Suites 2019 - https://xmpp.org/extensions/xep-0412.html) and you have already an up to date client and server. The rest if for specific use cases.
Part of their rationale is explained in their FAQ: https://matrix.org/docs/guides/faq#why-http%3F-doesn't-http-...
I dislike JSON, but it's a step in the right direction from XML. XML is an inelegant, verbose, over-specified mess, a relic of 90s thinking. JSON is definitely an improvement.
HTPP's fine, I guess. It's certainly available everywhere, and saves one from writing a bunch of tiresome parsing code. But that's really an indictment of the current state of our technology. Popular languages should make it easy to read structured data out of a socket (with some sort of max length to prevent DDoSes) & write structured data to a socket. Since they don't, HTTP is an okay compromise. It's a bit heavyweight, but it gets the job done.
Well, technically both are valid approaches which get messages from one user to another in a federated way. Besides that, XMPP is an IETF standard which has proven it can adapt to changing requirements. Matrix, on the other hand, is a young project with more momentum and more consistent software landscape.
That said, I have quite a biased view on the topic, as I kinda blame the Matrix devs for splitting the federated communication community. XMPP is quite capable of delivering what everyone expects it to do. But lately, developers seem to be more interested in the new Matrix protocol (just because it is new). At the same time, many XMPP clients do not implement all of the latest features the standard has to offer and I wonder what the world would look like if the Matrix devs would have spent their energy on improving existing XMPP clients instead of inventing another protocol.
Edit: For completeness, you might like to take a look at the Matrix FAQ https://matrix.org/docs/guides/faq.html#what-is-the-differen...
From the point of view of an XMPP server developer, the main advantage of Matrix seems to be that they have a well-funded marketing department.
we really don’t, fwiw. we have zero money assigned to marketing and nobody working on it, unless you count me chatting on HN and twitter, or our designer or the guy who updates the matrix.org/blog?
There's a comparison between the two from the Matrix team's point of view in their FAQ: https://matrix.org/docs/guides/faq#what-is-the-difference-be...
It is possible to consider them different categories of things. XMPP solves the IM problem but conferences with lots of users are a bit awkward if you use a XMPP MUC server. Conferencing is to some extent a bag on the side of XMPP. You would probably be better off just using IRC.
Matrix is primarily about dealing with the issues of conferences with lots of users... I see it as more of an improved IRC than a replacement for XMPP.
> the 0.99 version of the home server code is ACME-capable and can get a certificate directly from Let's Encrypt;
How does this work? I assume a home server doesn't have a public DNS name, so what is used as the subject of the certificate then?
"home server" is the term for the server your account lives on in Matrix, not for "server you run at home", although you can of course do that.
The federation requires a publicly accessible server to work. I got a cheap domain name, pointed it to my public IP (with DDNS), and port-forwarded to my server. Works fine for me.
DNS is required for wildcard domains.
To issue a certificate for a specific subdomain, you just need to have an http server and serve the secret under the .well-known directory.
Is anyone else increasingly uncomfortable with the "we'll solve the certificate problem by deferring to centralized registrars that surely keep their keys private from state actors." I mean, this is potentially not a risk if there is a recognizable way of communicating low-bandwidth fingerprints of the next encryption level, like ZRTP verification on voice. But note how WebRTC has done the same thing? And efforts to solve the problem are talked about and then, somehow, nothing ever happens with the standards.
It's enough to drive one paranoid.
Matthew's talk at FOSDEM [0] was really nice. I've been using Matrix (mainly trough Riot) for a while, and encouraged my technically-minded friends to jump on it.
However, I would like to get my family to use something else than WhatsApp (which I refuse to use). I'm planning to do so, once I can sort out the following:
- Riot is nice if you have a lot of high-density rooms (Fractal's "Banquet" use-case [1]), but not really there in terms of UX for small rooms with my family members
- I would like to self-host if possible. However, I need to ensure that the server is reliable enough, and synapse seems to be quite resource-hungry.
Regarding the first issue, it seems that France's Tchap would solve it nicely, from what we were shown at FOSDEM. Unfortunately, the Readme in their repo is still Riot's, and it would seem that I have to build it myself [2]. I'll look a bit more into that nevertheless, and it should improve by June, from the article.
Regarding the second one, someone recently linked to this Gnome mailing list archive [3] where (in the reply) Matthew details a bit more his (then) long-terms plans for homeservers. Having one homeserver per device would solve most of my issues pretty neatly. I am not sure how far it is in the roadmap. I am also curious to know what's the status on that specific discussion topic: I was discussing just this the otherday on #postmarketos-offtopic:matrix.org [4]. I was interested in having a unique matrix daemon on a phone operating system to provide push support, maybe as well as a Matrix protocol broker.
Otherwise, for self-hosting with ~10-200 users, it looks like synapse has shed a lot of weight recently, and other homeservers implementations seem to be picking up steam, so we'll see how that goes. I am not sure how synapse would handle a dynamic IP
For now, my gripes with the ecosystem are the following:
- There doesn't seem to be easy ways of migrating: accounts, homeservers (including address and implementation, ex. migrating to/from synapse, Dendrite, Ruma...).
- No easy way to manage multiple identities: work, home, etc. Multi-account clients or community-bound identities could probably help solve this. Ideally, it would be the later, and my account would be on multiple homeservers (backup plan for availability).
- The search functionality is really lacking on most clients. No way to search my own messages, or at a specific time, in a specific community, etc.
It's also kind of fun to have both COI (chat over IMAP) and Matrix making the front page at the same time :)
[0]: https://fosdem.org/2019/schedule/event/matrix_french_state/
[1]: https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-bar...
[2]: https://github.com/dinsic-pim/tchap-android
[3]: https://mail.gnome.org/archives/desktop-devel-list/2017-Sept...
[4]: https://matrix.to/#/!VTQfOrQIBniIdCuMOq:matrix.org/$15496441...
A bit off-topic, but my registrar doesn't provide an API to update the DNS records on their servers. As a workaround, would there be a free dynamic DNS with an API out there? I don't care what the address would look like, as I would just use it as a CNAME record.
There's already people doing unofficial builds of Tchap which work against the public Matrix network rather than the .gouv.fr deployment - e.g. https://github.com/14mRh4X0r/tchap-android and https://git.snt.utwente.nl/14mRh4X0r/tchap-proxy, although I'm not sure it's useful yet as more than an interesting experiment.
On the riot side, we're trying to do our best to make it support both Barbecue as well as Banquet use cases (assuming that's not a contradiction in terms).
In terms of other points:
> Having one homeserver per device would solve most of my issues pretty neatly. I am not sure how far it is in the roadmap.
It's in the 'further still' column - we published the roadmap last week at https://matrix.org/blog/2019/02/15/publishing-the-backend-ro... - look for the card labelled 'p2p homeservers'.
> - There doesn't seem to be easy ways of migrating: accounts, homeservers (including address and implementation, ex. migrating to/from synapse, Dendrite, Ruma...).
There are scripts to do it, but it's a bit crap (similar to migrating between IMAP servers). We're working on fixing it properly via MSC1228 (https://github.com/matrix-org/matrix-doc/pull/1228)
> No easy way to manage multiple identities
Multiaccounts are next up for Riot.
> The search functionality is really lacking on most clients
yeah, we need to fix this.
The only advantage Matrix currently has comes from it's relative obscurity. It has ONE implementation. Once things start inevitably emerge, it'll run into all the same problems that truly distributed protocols have.
it's true that there's only one implementation that's production ready. however, there are several which work sufficiently that they can federate with it (dendrite, construct) which look to be on the right path. it'll be interesting to see if that all falls apart when they come of age; let's see :)
Does it support conversation trees like we do here on HN? Does it let you edit your messages?
no, threading isn't there yet. editing isn't either, but coming soon (https://github.com/matrix-org/matrix-doc/pull/1849)
This probably is my own problem but I totally hate threadless communication for whatever that goes beyond a personal chat for 2 people. IMHO every meaningful collaboration needs threads.
I wish they stop wasting time by developing this Electron abomination and focus more on the native and mobile clients.
I realize this is a somewhat dismissive answer, but the entire point of Matrix is that it's an open specification. The Matrix team is putting a ton of work into guides that show you how to build support into your own apps. The protocol is being designed, from the ground up, to be easy to implement.
I'm not saying you personally have to build a mobile app. I am saying, in the grand scheme of things, if this is genuinely something that matters to a bunch of people, any one of them can build a mobile app and solve your problem.
There are tons of people on HN that hate Electron. If this is actually a real problem, then someone will eventually solve it, and it'll be fine. On the other hand, if a large, sizable community of native developers with tons of experience on the platforms they want 1st-class solutions for don't ever get around to solving it... then it's probably not a real problem.
Riot-web is a really nice app. Drop it on any web server and you're done. I use it all day long to talk to my family on a self-hosted, non-federated matrix instance. If you use linux, Fractal is a pretty good option for a desktop application. The latest release is "beta" but very usable.
https://matrix.org/docs/projects/client/fractal.html
Curious if there was a reason you chose to self-host as opposed to using a public one on just starting your own room (I assume this is possible in the same way channels are in IRC)?
What was the drive to use 1, self-host and non-federate an instance of Matrix over another platform, and 2, why? With family especially, I would assume a simple WhatsApp/Signal group would have been easier for adoption.
My extended family of 16 which ranges in age from 5 to 85 uses this Matrix instance. We didn't want pictures of our young kids on Whatsapp (Facebook) servers. These young kids and grandparents don't have smartphones so Signal isn't an option. Also, many of us access Matrix on other devices and computers other than phones.
This is how the internet is supposed to be.
Thanks. I've been tossing up setting up a forum of sorts for some close friends, but I've been going back and forth on the two extremes; an obscure telnet-only accessible BBS for the nostalgia, or a Matrix/Riot page for the ease of use.
I know about Fractal. My point it is not the reference client and not enough love is done for mobile clients also.
Personally the clients are OK. They might not be the most well designed since that is always problem for projects like that but they are OK.
So do i really have to build it?!
the only reason we release the electron app is because it’s practically zero work (and it was a community contribution in the first place). in practice much of the team work on the native mobile clients. hopefully proper native desktop apps will mature from the community, or worst case we’ll get involved as the core team.
Good to hear this, thanks for the answer!
I haven't tried Matrix yet, but I've tried some other chat platforms like Telegram and Discord, and was really disappointed with them compared to IRC.
I had to use their closed-source, bloated, binary blob GUI clients, couldn't logs the channels I was in (and so relied on having to log in to their servers to get backlogs, which was super annoying), and needed invites to get in to channels.
Apart from the superior multimedia capabilities of these clients, I saw absolutely no advantage of them over IRC clients (which could do useful things like logs all mentioned URLs and mentions of my nick to separate, logged tabs, and which I could run from the terminal and even from within Emacs).
I really hope Matrix is better in this regard, and I'm trying to keep an open mind, but so far attempts to create next generation chat services have been really underwhelming.
I find it compares favorably to IRC and XMPP. File transfers and offline messages and encryption "just working" without having to check if my client, other persons client and the server(s) support it (or having to bring helpers into the mix) is worth a lot.
Except you do have to check, as almost no clients support encryption fully.
using matrix via weechat using the new python weechat-matrix (https://github.com/poljar/weechat-matrix) plugin should give a very convincing IRC on steroids experience; it even has e2e encryption landing. The emacs matrix client (mclient.el) is also in active dev again.
Riot is also good, but probably too bloated for your tastes :)
It's a shame that the Matrix website listing clients[1] don't mention weechat-matrix and instead mentions the outdated Lua plugin[2] that doesn't support Megolm at all.
I've been using Riot for a few years and it's nice, but it would've been nice to know that there is a modern Weechat plugin implementation (I was half considering writing one myself).
It's also super neat to see that they wrote their own Python Matrix client library[3], which is something I also needed for another idea I'm working on (the library linked to from the Matrix site also seems to be less suitable than this one).
[1]: https://matrix.org/docs/projects/try-matrix-now [2]: https://github.com/torhve/weechat-matrix-protocol-script [3]: https://github.com/poljar/matrix-nio
Thanks for pointing this out - the website is updated now to include poljar's work. (We did feature it on the blog but important to keep the projects list updated too!)
There are several competing Python libraries, those you mentioned plus https://github.com/tulir/mautrix-python. We'll do a round-up and review of the options soon.
Looking over the list of Matrix-related projects [0], what I'm finding a bit concerning is that only one of the server implementations (the official Synapse codebase) appears to be anywhere close to production-ready. All the others look like they're either abandoned experiments, or barely in early dev (Dendrite).
The feature blurbs and API specs make it sound relevant to a project I'll be working on, but I'm concerned that there's only one viable-ish server implementation. I'd feel a lot better if there were several valid working servers in various languages by now.
[0] https://matrix.org/docs/projects/try-matrix-now
The reason why alternative server implementations are lagging behind is because there was a very recent push to 1.0 the entire spec (specifically because of the French government deployment discussed in TFA). They said they'd emphasise alternative implementations afterwards in the FOSDEM talk Arathorn gave earlier this month.
The Rust server isn't dead at all, the maintainer is active but not proceeding until async / await is fully stabilized.
I'm the creator of Ruma, and so I can confirm this. :}
For anyone interested, a detailed list of what is blocking or slowing progress can be found here: https://github.com/ruma/ruma/issues/189
Up until very recently we'd been postponing work due to immaturity of both Rust and the Matrix spec. Now that all the Matrix specs have had stable releases, the main blocker is the maturity of async/await and support for it in the library ecosystem. Since Ruma uses nightly Rust currently, we don't need async/await to be stabilized to proceed, but it does need to be far enough along that it has been adopted by all the major components of the Rust HTTP ecosystem. I'm guessing we've got about six months left until this happens.
I appreciate the update.
Putting my "tech lead evaluating tools" hat on, I like the idea of a single-file binary that can be easily deployed. That said, seeing that the last commit was 2 years ago isn't encouraging :( Given that I'll likely be seriously evaluating potential approaches for our system design within the next 2-3 months, it doesn't look like Ruma would be a viable option for our situation.
Matrix is totally open sourced. Server side and the official client (Riot) can be deployed anywhere under your own control.
Also, deploying a bridge you can connect Matrix and IRC rooms, creating a hybrid channel mixing Matrix and IRC clients in the same room. It's pretty cool.
While most of your complaints is valid for Discord, it doesn't hold for Telegram, which IMO has high quality clients, in terms of native look&feel, lightweight, and general UX.
Matrix on the other hand is like having everything half-baked. This made it an non-option for daily use and I ended up moving to other IMs and a bouncer for IRC.
you may be surprised at how much it's improved in Riot 1.0, but ymmv :)
I don't think you need to use binary blog GUI clients for Telegram. Here's the source to many clients: https://github.com/TelegramOrg