Cross-signing and end-to-end encryption by default | Hacker News Reader

Cross-signing and end-to-end encryption by default

matrix.org

615 pointsthanksforfish186 comments

Both are asynchronous messengers.

Signal: + protects metadata + protects the content (e2e encryption) - is not anonymous - is not resilient against regulations

Matrix: - does not protect metadata + protects the content (e2e encryption) + is anonymous + is maybe, potentially resilient against regulations (federated, not centralized architecture)

You could argue that Matrix does protect metadata if you run your own server - and in extremis, one way of running your own server and protect metadata is to go P2P and embed it into your client (which is one thing we're currently working on).

That said, there are some other pretty big differences between Matrix & Signal; the biggest one is probably that Matrix is an open standard and open network, encouraging 3rd party clients, servers, bridges, bots etc - optimising both for freedom/liberty as well as encryption. Signal optimises for privacy at all costs and doesn't allow 3rd party clients or services. See https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom for more.

That's not really a reasonable argument. Signal makes a profound UX tradeoff to protect metadata by not requiring servers to store it in the first place: it drafts off people's phone contact lists, and thus everyone who uses it needs to be identified by a phone number.

Matrix doesn't have any special way of avoiding that tradeoff. It just takes the other end of the trade: Matrix servers are exposed to valuable metadata, so that people can use whatever identifier they want.

And, of course, the flip side of Matrix's "freedom and liberty" federalized design is that it is May 7, 2020, and the project is just now announcing E2E by default for private conversations. This is exactly why, years ago, Moxie Marlinspike wrote his post arguing about the downsides of federalization. It sure looks like his predictions were borne out!

I think both of these projects are valid and important, and that they have different goals and audiences, and we do people a disservice when we pretend like they're in any kind of serious competition. Matrix is what you'd replace an IRC server with. Signal is what you'd tell an immigration lawyer to use for messaging.

> And, of course, the flip side of Matrix's "freedom and liberty" federalized design is that it is May 7, 2020, and the project is just now announcing E2E by default for private conversations. This is exactly why, years ago, Moxie Marlinspike wrote his post arguing about the downsides of federalization. It sure looks like his predictions were borne out!

I'm skeptical that much of this particular delay has to do with federation, as opposed to things like differing priorities and general project velocity.

Why? Because Matrix is not yet as successful or as diverse as XMPP, the example Moxie gave in his blog post. My impression is that Matrix has one main server implementation (Synapse) that everyone uses, and one main client implementation (Riot) that E2E encryption was added to. And the company developing Synapse and Riot is also developing the spec, so it's completely coordinated. Alternate clients and servers exist, but they're very much "alternate"; I don't think anyone was waiting for them to implement anything before making this announcement.

I could be wrong. I'm not involved in Matrix development, or even a Matrix user. But that's my impression from some quick Googling.

If I'm right, the only real cost of decentralization at this point was having to (a) design the protocol itself to support federation and (b) document the protocol as part of the Matrix spec. That's not nothing, but it's small potatoes compared to the kind of massive ecosystem fragmentation Moxie was talking about.

My take on this is:

Yes, Matrix’s development would go way faster (6-10x is my estimate) if it wasn’t decentralised. Huge amounts of effort goes into designing a system where you have multiple servers (or peers in p2p) which can’t be trusted, and where the behaviour needs to be formally specified in a neutral public spec that can be independently implemented. You have to layer the spec into abstractions which ensure the lower layers are stable and relatively frozen such that folks can build on them confidently, but the higher layers can evolve and experiment as rapidly as possible.

However, we think this is an acceptable cost in exchange for building an open network / protocol / ecosystem like Matrix. Freedom is important.

As comex points out, we’ve tried to mitigate slowness by developing the core of Matrix (protocol and reference server and reference clients) by the same logical team rather than by vying factions - which has certainly helped, but only as an incremental factor.

The fact it took us 3 years to exit beta for E2EE and turn it on by default reflects more that we chose a large scope (interactive verif, cross-signing, encrypted key backups, etc all break new ground, afaik), had to make it decentralised, and also reflects prioritisation (encryption is not our only focus).

So yes, it takes longer to build Matrix than a centralised e2ee messenger. Or longer to build bitcoin than paypal. Or the Web than AOL. But we think it’s worth it.

I've been back-and-forth with 'Arathorn about this for a long time and I'm pretty comfortable with my diagnosis. For instance:

https://news.ycombinator.com/item?id=20315096

To add to this point, the goal for end-to-end encryption by default was January (said in December):

https://news.ycombinator.com/item?id=21765008

But there have been other times where "soon!" have been given over the past three years:

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

I like Matrix and think Signal makes some serious mistakes for no apparent reason, but yeah, the repeated "Matrix is just as good and more free we swear!" is...maybe not the right thing to say, yet.

I believe you consider phone numbers pseudo-anonymous identifiers, which I believe Matrix names also qualify as.

Is there any technical reason why Matrix servers would have to store contact lists?

Both Signal and Matrix would have store message metadata to deliver it.

I searched for what the significant difference is, but could not come up with a good document to read.

Phone numbers are the most identifying piece of information. They are precise identifiers not pseudo-anonymous. A non-burner phone can easily be converted to a complete background check on the person for under $50 ,for a higher price it can be converted to current realtime physical address.

> easily be converted

Could you link to a reputable resource for this? I've always imagined that phone number background checks were mostly scams with a bit of public information sprinkled on top.

I'd be very surprised to learn that I could purchase a burner phone, give you the phone number, and have you be able to tell me my address and criminal history.

They just said "non-burner phone."

> I'd be very surprised to learn that I could purchase a burner phone, give you the phone number, and have you be able to tell me my address and criminal history.

OK, so even if you pay cash, there's video surveillance in the store, and surveillance (license tag, video, etc) on the route. And that's linked to the number. Then there's the number that you call from to activate the burner phone account, which may have some identity information. Plus geolocation data for that, and for the burner phone.

When I was living in Brazil to buy any kind of SIM card you had to give your CPF or whatever it was called number from your residency card. I believe many countries have this rule as coiner terrorism measure or whatever. Of course for bad guys it’s trivial to go around those restrictions.

And that's a near best case scenario in the US, UK, etc. In most of Europe and many other countries, you have to officially register a SIM card with an ID/residence document to use it.

Huh. Is that more or less recent?

I guess that I'm a few years out of touch.

There's no ID requirement in the US, I think.

Right, I meant that the scenario described is a near-best case in a global context as many (most?) countries unlike the US/UK/etc. require ID verification.

No legal requirements, hence burners. But as a rule carriers enforce it.

I don't believe this is true. It's very trivial to find a prepaid SIM in the US that one can just purchase, activate, and top-up with reload cards (which in turn can also be purchased with cash). Postpaid plans do often require ID verification because of the credit that is being extended, which I think is more than reasonable.

For non-burner phones, just Google the phone number---you'll probably get a sketchy "look this person up for $XX.YY" telephone directory page that will contain their full name and age, if not their address.

So, I just Googled my phone number, and the phone numbers of several friends.

In each case I got dozens of the same flavour of site, which I've seen many times before, it has a paginated list of every possible phone number that could exist, and an advertisement. These sites are pretty cheap to build and presumably over their lifetime they bring in enough advertising revenue to justify renewal costs, hosting and so on.

But they don't offer (and couldn't deliver) personal information about any of us, since that isn't publicly available.

At any rate all of this misses the point; Signal doesn't use phone numbers because phone numbers are an especially good identifier, but as a UX tradeoff to keep metadata off their servers.

I have good reason to believe this UX "tradeoff" is being actively abused. Several vectors,but the main one has to do with contacts of a compromised target,or when a target adds you as contact.

In practice,it's worse than having to use your SSN. You don't need SSN to sign up with all the major apps and sites (including free email),but you do need a phone#.

Can you go into a little more detail (or link me somewhere that does)?

This sounds like an interesting trade off, but I'm not totally following how using phone numbers and contacts avoids the metadata on server issue.

I think it boils down to the fact that in Signal the server can't see which conversation messages belong to - and if sealed sender (aka secret sender) is enabled, the server can't see who they're from. (As far as I know, the server still tracks the phone number of accounts and thus the recipients though - looking at https://github.com/signalapp/Signal-Server/blob/2b987e6e9301...)

Unsure how this relates to contact lists though (other than that secret sender is apparently only available for messages from people in your contact list?)

Matrix on the other hand isn't a message-passing system like Signal (or IRC or XMPP or SMTP) - instead it's a way of securely storing your conversations (more like NNTP or IMAP). This means that when you log into a new Matrix client you can get at your conversation history, and it means that even if you lose all your clients you don't lose your history.

The compromise is that Matrix ends up storing the metadata of who spoke to when in the conversation history which is stored on the server.

However, we're working on mitigating this with P2P Matrix (where you run the server clientside, unless you explicitly want to pin that conversation to a serverside server), as per https://fosdem.org/2020/schedule/event/dip_p2p_matrix/ - and it even works :)

Did you pay? At least in the U.S., states release ridiculous amounts of information on people. It's "publicly available", but in practice states charge a high fee for the databases, which means most of this data exists behind paywalls. The data on sites like spokeo.com and intelius.com isn't great--not at all comparable to the breadth and quality of data LexisNexis offers with their 5- and 6-figure subscriptions--but it's amazing how many phone numbers, names, and addresses you can still match up.

Then there's all the "private" data about you that is commercially available. That's what credit agencies and similar companies do--buy your data from any company willing to sell it. Such databases are so deep and comprehensive that these companies have become extensions of intelligence organizations for all the business they do with government. In fact, just a year or two ago there was the "scandal" where it turned out cellphone companies were selling location data, which some savvy police departments started using to avoid dealing with warrants.

I said a non-burner phone

Signal's servers store no contact lists at all. It's not that phone numbers are some especially good anonymizing identifier; obviously, they are if anything the opposite. It's that everyone who uses Signal already has a local contact list keyed on phone numbers, which Signal's client applications can access, which means the server doesn't have to know about contact lists in the first place.

> It's that everyone who uses Signal already has a local contact list keyed on phone numbers ...

Well, that's precisely why I don't use Signal. In that I don't use smartphones. I could probably run Signal in an Android VM. But I have no way to get a phone number that's both adequately anonymous and adequately secure. Or at least, I don't yet know how to do that. Burner phones are too readily located, and hosted SIMs are too insecure.

Android x86 VMs now have functional virtual WiFi interfaces. But I'm not aware of a virtual cellular network implementation, which could theoretically (I imagine) allow virtual SIMs. That would be very cool. Or maybe it's doable with VoIP?

But this ostensible "Signal's servers store no contact lists at all" policy also incurs several serious risks:

* The Signal client regularly re-sends your complete local contact phone numbers to the Intel SGX contact-intersection code on Signal servers. So, potential flaws in that process would mean Signal servers continually receive, & could possibly log, far more metadata than competing systems that upload all your contacts' phone numbers.

* Signal leaks that your phone number has enrolled with the Signal service to anyone who chooses to query it.

You are comparing the possibility that something could go wrong and expose contact graphs to systems in which exposure of the contact graph is a foregone conclusion, because the servers store them, durably, online, in plaintext. The point of the Signal design is not having to do that thing, and, indeed, it doesn't, unlike other secure messengers that do.

No, I'm comparing Signal to desirable properties of a secure messenger for many important uses.

It's great that Signal has devised a system that, ostensibly, obviates the need for them to keep persistent lists of everyone's correspondents. But as that same system requires the constant, repeated uploading of phone-number-identifiers, and complete trust in Intel SGX™, it misses the primary thing most want from an end-to-end, open-source solution: no reliance on remote personnel or systems.

Signal's created a fancy 'Maginot Line' that ultimately reduces to the same core flaw as much-simpler architectures: if a small number of hard-to-monitor key people or servers are compromised, even temporarily, the metadata is also compromised.

You tout that "Signal's servers store no contact lists at all". But can you prove that? Signal's servers are still sent all the same data that would be required to do that.

Meanwhile, other secure messengers manage to:

* avoid ever knowing a users' phone number, or revealing a users' phone number to their correspondents

* avoid broadcasting the fact of a user's participation to anyone who cares to query

It's important to remember these caveats & tradeoffs when alleging Signal stores no contact lists at all.

Again: your argument is that, because someone at Signal could misbehave and log metadata, Signal is equivalent to systems that log metadata all the time, durably, by design. Given the choice, I'll take the system that can at least plausibly protect my metadata over the one literally premised on not doing that.

I'm not alleging 'equivalence', I'm emphasizing assumptions & tradeoffs.

I want readers to know that your headline claim, "Signal's servers store no contact lists at all", should be coupled with the important caveat that believing that claim still requires trust in Signal and Intel personnel/servers.

And even if someone, like yourself, assumes such trust in Signal & Intel, the metadata protection Signal does offer still requires other metadata tradeoffs. That's not 'equivalent' to other options, it's different in notable ways. For some users, like say an anonymous whistleblower without a 'burner' phone number, Signal's metadata handling is arguably worse than other extant options.

You find Signal a preferable, perhaps even dominant choice; I think they're a mixed-bag once aware of all the tradeoffs.

Thank you for this illuminating comment; it was helpful and imho exemplary.

Nobody ever seems to talk about Threema. :/

I've tried Matrix. The principle sounds great but the lack of quality client just put me off on whichever platforms I've tried with most popular clients.

The interface is just complicated for average people and the translations were half done and this will scare people off if I recommend for cross company chat.

The server side may be great but it needs some work to have simple and elegant client on desktop and mobile clients.

Currently I use Mattermost and it seems to be doing ok but this has no built-in support for audio and video.

Personally I think this is a fundamental problem with matrix and why it will always only appeal to a certain segment of users. For those users, namely tech/security enthusiasts, it is appealing due to its federated architecture, privacy, etc. For anyone else, it’s too complicated. Even discord, often cited, suffers from this imo. The mass public does not want complicated. The mention of words like “e2e”, “server”, “bridge”, “decentralized”, might as well be from an alien language. That said, if it works well for their target demographic then it could have success in that space.

It can be solved with a simple client that hides the complexity but only shows what makes sense to average users.

So we are painfully aware that Riot’s usability still needs to increase, as per https://blog.riot.im/e2e-encryption-by-default-cross-signing... - although I’m not sure it’s quite as dire as the GP makes out.

All I can say is that we’ve hired three permanent kick-ass full time UI/UX designers for the team, put them charge of the product direction for Riot, and told all the devs that their job is to do nothing but implement their design iterations as efficiently and accurately as possible. Let’s see how it goes.

But there's no anonymity in Matrix by default, right?

Can Matrix servers be run as Tor onion services?

They can, but the tor servers cannot federate with non-tor -servers (how would the non-tor -servers connect to the tor-servers?)

One can run reverse Tor to clearnet proxies that are both anonymous and ~disposable. That is, knowing the proxy IP doesn't compromise the Tor onion server, and the proxy retains no PII, and can be readily replaced if taken down.

Signal has publicly threatened to shutter their US operations if EARN IT passes, so id say its relatively resilient. https://www.wired.com/story/signal-earn-it-ransomware-securi...

regardless, the e2e encryption debate seems largely settled by the key players at this point. I think any legislation that makes its way through is likely to see brinkmanship again. Theres no reason these services cant use darknets. At the risk of sounding like a cryptobro, theres also no reason they have to use a server at all with blockchain.

Having to leave a country is pretty much the opposite of 'resilient' in this context. They have to leave because it is a centrialized system and can be regulated like any other entitiy.

Matrix is federated and individual servers can be run by volunteers/individuals for whom EARN IT would not apply.

> Matrix is federated and individual servers can be run by volunteers/individuals for whom EARN IT would not apply.

It would apply to them if they were or served US citizens, which would mean that nobody in the US could get encryption, which is exactly what might happen with Signal.

> It would apply to them if they were or served US citizens, ...

Sure, but only if they could be identified. So obviously any such volunteers would make sure that they remained anonymous. Otherwise, they would suffer the consequences.

> At the risk of sounding like a cryptobro, theres also no reason they have to use a server at all with blockchain.

Can we stop saying blockchain for everything? You don't always need to, nor want to, audit your entire history.

> Signal has publicly threatened to shutter their US operations if EARN IT passes, so id say its relatively resilient.

So if every country passes something like EARN IT, Signal shuts down, how is that resilient?

I don't know how helpful it is to use the word resilient at all if we're talking about catastrophies like this. I mean, the International Space Station is pretty resilient, but if the population of earth is wiped out in a super volcano, it doesn't matter anymore, right? I'd still call the ISS resilient though.

> So if every country passes something like EARN IT, Signal shuts down, how is that resilient?

That's not a forgone conclusion. Maybe it is for Signal, but not for chat overall. There's this thing called Tor. If you're careful, you can remain anonymous. And there's the new onion routing network Loki, which backs the Session chat app.

If things got bad enough, there are more robust options. I can imagine a botnet that spread much like WannaCry, and which offered deniable messaging via covert channels. Data transmissions would be hard to detect, and running the network components would be deniable.

When should applications should fail-open when forced to pick between availability and security?

The obvious answer is decentralization, and Signal is not equipped at all to do this.

Only one appears to allow for E2E without the help of a third party. If person A and person B are technically capable and want to run their own servers and use their own clients, without involving a third party, then Matrix appears to allow for that. With Signal E2E is only available if persons A and B involved Signal in the process, including using Signal's software. Matrix appears to be just a protocol. Theoretically, there is no need for users to involve the Matrix organisation in their E2E communications.

Signal: - cannot run own server - writing clients discouraged; centralised control preferred

Matrix: + can run own server + writing clients encouraged

Ideally, what persons A and B might want is a protocol that allows for peer-to-peer connections without passing traffic through the third party. The server might be merely a point of rendezvous to enable one person to discover the network address of the other. For example, person A contacts person B's rendezvous server for person B's address, port, etc. Then person A makes direct connection to person B. Once that peer-to-peer connection is established there is no more need for the server. No traffic passes through it. It could even be shut down.

Tox. Each user runs a Tor onion service, and they talk to each other.

Maybe now it's time to refresh the research papers on Matrix/Riot privacy concerns. After reading these a few months back, I wasn't so sure anymore that Matrix/Riot is what I can wholehartedly trust: https://github.com/libremonde-org/paper-research-privacy-mat...

Those research papers are written by a person that is (was?) making a hostile fork of the protocol. That is not to say everything in there was wrong, but it was blown out of proportion from my perspective.

Also: they are fairly old by now, and most complaints that have merit have been addressed.

> Also: they are fairly old by now, and most complaints that have merit have been addressed.

This blog post goes into more detail https://matrix.org/blog/2019/06/30/tightening-up-privacy-in-...

Yeah, sadly the ‘research paper’ wasn’t updated after we fixed the issues it highlighted; see also https://matrix.org/blog/2019/09/27/privacy-improvements-in-s...

How does Signal protects metadata? I love Signal but that's not true. Your phone number, your IP, who you send a message to, at what time, etc. is sent to the server.

What metadata are you talking about?

Metadata is data /about/ data. A file with all 4 billion possible IPv4 addresses written out is not an unprecedented security hole it's just useless for example.

"Who you send a message to" is actually a relationship between two pieces of information, a sender and a recipient but Signal doesn't collect this in most cases.

Who the message they received is _to_ in the sense of which Signal account it's for, they need to know in order to store it and pass it on. But who you were they don't need in most cases because of their Sealed Sender feature.

When you converse with Alice your phone fetches profile data that it is able to unlock because Alice's phone agrees you're a friend and provided the key to do so. Alice's profile includes tokens that her friends can use to send her messages. Subsequently your phone presents a token authorising you to send messages to her, and so Signal does not ask it to identify itself when sending this message.

As a result Signal intentionally does not learn who sent these routine messages between friends and acquaintances even though the message recipient can determine who sent them.

> Who the message they received is _to_ in the sense of which Signal account it's for, they need to know

And, by extension, the exact real world identity and location of this person.

Signal promises not to store metadata, but definitively have access to it.

> And, by extension, the exact real world identity and location of this person.

Not at all? Most likely what's happened here is that you don't understand what "by extension" does in a sentence.

Not unlikely. Feel free to explain further.

Hopefully the difference about having access to data and storing data is still clear?

More info on the sealed sender functionality which is IMHO one of the main distinguishing feature of Signal: https://signal.org/blog/sealed-sender/

Apart from that, group membership is also E2EE, which is a signifiant piece of metadata.

> is anonymous

How is this achieved? How can this be attacked? Are users at risk of deanonymization?

Matrix's anonymity comes from the fact that anyone can create an account on a public server on the network using an arbitrary username that doesn't have to be linked to a phone number or email or any other identifier. However, the server they use can see their IP address and their access patterns, and the other servers in their rooms will be able to see what rooms they are in and the metadata of their message history in those rooms. This could theoretically be used to deanonymise users - after all, the rooms where a user hangs out, the members they share rooms with, and their message frequency in those rooms is all sensitive metadata. As tptacek points out, Signal doesn't track that and just passes messages from A to B, whereas Matrix by design is about syncing conversation history between users & servers, and to do that it needs to record the conversation history (and thus its metadata).

We're mitigating this with P2P Matrix (https://fosdem.org/2020/schedule/event/dip_p2p_matrix/ etc), where there are no longer servers where metadata pools.

Signal's sealed sender reveals ip addresses of the sender as well. And if you use the same IP to log in to the signal service, they can figure out who you are easily. The data pools even more as Signal is centralized. You only have to get AWS give access to Signal's infrastructure. And guess what, the DoD has giant AWS contracts already and with that tons of leverage.

Wouldn't using something like tor mitigate the issue of servers seeing IP addresses?

sure, or any kind of anonymising vpn.

Matrix: community funded, clearly stated

Signal: ?Brian Acton?

(in the interests of accuracy: most core Matrix development is funded by New Vector, the company started by the Matrix team to try to keep the lights on, which in turn makes money via selling Matrix hosting at Modular.im and providing professional services at Vector.im. New Vector has also taken on investment funding - https://matrix.org/blog/2018/01/29/status-partners-up-with-n... and https://techcrunch.com/2019/10/10/new-vector-scores-8-5m-to-...)

That's a super weird bit of shade to throw, since Signal operated --- and gained most of its adoption --- for many years before Acton donated to the project.

Huh? What is super weird about following the money? I was looking for Signal business model and was not able to find it.

i have a solution in the works

Folks who have tried Matrix/Riot and Slack – how does the product quality compare?

Slack has many issues (little bugs, latency, notification issues, the shitshow markdown editor) but overall delivers a smooth product experience IME. When you self-host Matrix, do you typically get great perf without much effort? Is the product experience of the Riot client smooth and complete?

Historically, Riot's UI hasn't been as smooth as Slack's - for many years we didn't have any professional UX/UI designers contributing to the project, and we built up a lot design debt along the way.

Over the last year or so we've been progressively working through fixing it, and as of Monday we now have three(!) professional designers working full time on the problem. Having turned on E2EE by default, our next big project and single biggest priority is First Time User Experience - making sure that the app is at least as smooth as Slack and Discord, particularly on first impressions. https://blog.riot.im/e2e-encryption-by-default-cross-signing... has more details - and the sections before it show some of the UI/UX work which has been landing in the last few months.

First off, let me start with thanks :-) As an end user I lack an appreciation for what goes into this; but as someone who writes software, I know the amount of effort that goes into kicking out a polished piece for others to gawk at and comment on. So kudos, definitely.

Further, it is definitely worth taking inspiration from Discord. Newbies seem able to pick it up very quickly. Some Discord rooms feel about as alive as happening IRC channels from back in the day, and the interface+culture seems to do a great job of supporting that.

Fairly subtle, but important things like where the names are placed relative to the messages, and the size of the avatar/image, etc keeps the interface from becoming crowded (in comparison with the Riot desktop interface, for example). The Riot iOS interface gets several of these things right, btw :-)

It also seems to be fairly easy to customize “Discord servers“ with different levels of organization — scaling from few users to 1000+ users. Not just the backend, but the interface also scales very well. From a pure usability standpoint (apart from privacy issues, centralized, etc the user experience in Discord is fantastic.

Let me just note that my beloved boomer parents did not find Discord easy to pick up quickly when the family tried to video chat. (My sainted mother installed Riot because I asked her to, and it's worked so far)

I just played around with Riot for the first time. Can you directly reply to a comment in a chat room like you can in Slack (like the sub chat thing, I'm not sure what to call it)? I actually find this an extremely useful feature that allows rooms to to be uncluttered with side conversations (which as room sizes grow, this becomes a HUGE benefit). I may be missing this or I can't do it in a room of only me?

We have 'replies' (which lets you post a message into the main timeline which refers to an existing message in the timeline), but we don't yet have 'threads' (which lets you branch the conversation into a sidebar).

The protocol actually has support for label-based threading (i.e. "hide all messages tagged #gif" or "only show messages/conversations in this room tagged #work") already, as per https://github.com/matrix-org/matrix-doc/blob/matthew/msc232.... But we haven't had a chance to hook this up into Riot yet, thanks to all the work spent on E2EE by default.

Proper threads will come in time however.

Hot take: slack-style threads are bad for long-form discussion. They encourage forking, when what you really want is everyone to be on the same page. Traditional forum-style threads, or "channels" on a chat app, is optimal for discourse, as it encourages continuous convergence and integration rather than splintering. Hiding tangents serves to lower the quality of conversation.

Optimal within the constraints of real time chat IMHO is slow-mode (5 to 15 seconds, or possibly greater) in a single channel.

IME tangents, while possibly fruitful, just lead people to skip the 30+ messages and so doesn't become helpful.

Hot take: make threading an option. If you don't want them, don't use them. If you want them, then they are available. This is clearly a personal difference with no right or wrong answer. So the solution is options.

Thanks for the reply! Yes, threads. That's what I'm thinking of. I find these super useful. I know some people don't like them, but they can just not use them if that's their preferred style. I would really just like threading a comment rather than having to label everything. I'll be honest, I'll just get lazy and not label. I doubt I'm the only one too, or in the minority.

> Proper threads will come in time however.

Awesome, this was really the only thing that makes me hesitant to switch. I can stand an ugly UI if I can get good conversational flow.

I find Zulips threading/topics UI brilliant for certain kinds of channels and discussions.

I hope that Riot will implement something similar, potentially as an individual or per-channel setting.

No, it looks like threads aren't (yet) supported in either Riot or the Matrix spec.

https://github.com/matrix-org/synapse/issues/2329

https://github.com/vector-im/riot-web/issues/2349

I believe those are threads and while I have no opinion on the subject because I don't really use slack anymore, I remember them being pretty controversial here.

In my experience, Matrix and Riot are great. I love the protocol and concepts around it, and Riot was much higher quality than I expected it would be. Since trying it out for a while a few months ago, I have since abandoned it, however, because operating my own Synapse server was just too much work.

Specific pain points were:

- setting up SSL - getting Let’s Encrypt certs onto a server without a web server was a pain, and keeping them up to date was even worse. I would love to see ACMEv2 support integrated into Synapse for painless SSL setup.

- TURN server - if you want to use voice chat, you need to set up a separate TURN server, which has its own set of challenges. Again, I would love to see a solution integrated into Synapse.

- Video chat - Even with a TURN server in place, video chat requires a separate plugin to work. Jitsi is recommended, I believe. Yet again, I want this integrated into Synapse and Riot.

- Federation - Federation is part of what makes the Matrix protocol so great, but it was a huge pain to configure in Synapse. I spent hours to get it working, and it still had quirks about matrix.mydomain.tld vs mydomain.tld. I would like to see this simplified.

Probably the thing I was happiest about is that a ton of administrative settings are easy to work with in the Riot web client.

Keep it up, guys! I hope Matrix takes over the world, and I hope to come back some day.

Sorry to hear that :( There are two things we've tried to do to fix it:

1) Running Synapse really isn't that hard if you follow best practices... but I think we've done a bad job of communicating those best practices; instead Synapse's INSTALL.md lays out tonnes of different options and expects folks to pick their poison. I tried to fix this a few weeks ago by sitting down and recorded a dorky video to try to steer folks through best practices for setting up Synapse + certbot + Jitsi: https://matrix.org/blog/2020/04/06/running-your-own-secure-c.... (I need to extend it to coturn, but again, coturn should be straightforward. I don't think we should be baking TURN into Synapse though!). You could also shove everything in Docker and forget about it.

2) Peer-to-peer Matrix will let you get up and running without even needing a server. This is progressing alarmingly rapidly at the moment - https://p2p.riot.im is a version of Riot/Web which installs a homeserver (Dendrite) in your browser as a WASM service worker. It's alpha, but it mostly works pretty well, and is hopefully the shape of things to come - to let people have autonomy over their comms without ever needing to understand SSL, TURN, etc.

Thanks for the reply! I understand not wanting to re-implement entire servers within Synapse. Maybe an installer util would go a long way towards making setup more manageable. A step to automatically download and configure coturn, for example, could be very helpful.

I also understand that making things too turn-key (no pun intended) can be extremely difficult to do well and can also impede advanced configuration. But there is somewhat of an incongruity between the Matrix philosophy of keeping private servers vs. the expertise required to actually get that done.

P2P sounds really cool! I’ll try it out.

I’m getting the following error when using the P2P instructions. Is this likely an from an outage?

https://photos.app.goo.gl/myGNh77ukXWgqaVX9

https://p2p.riot.im is a webapp and runs in browser.

For the SSL part , I have been looking at Caddy as it seems to have pretty simple reverse proxy over SSL setup.

Reverse proxy with Caddy to get mindless automatic TLS is incredibly easier than any other setup for something you want to just work. I wish more projects supported reverse proxy setups better.

Synapse is a beast. I am looking forward to a more compact server to become viable. Matrix is working on Dendrite (https://github.com/matrix-org/dendrite) and there is Conduit (https://conduit.rs) as well.

Dendrite is rapidly approaching the point where it could be considered beta rather than alpha. However, it doesn't have any of the richness of Synapse yet, and it'll be a while before it can be used as a Synapse replacement. Meanwhile, Synapse keeps shrinking and is getting a lot of performance love - so personally I'd give keep giving Synapse a go for now. It's a smaller cuter beast these days :)

I've just tried it again a week ago (last time was ~2 years ago).

While there's definitely lots of improvement, it's still painfully slow and eats lots (like, 40% of 1 core) of CPU time. Took me a two attempts and a couple minutes (!) to join a relatively crowded room at #synapse:matrix.org on a freshly installed Synapse. I get it that there are over 12k people in there, but I haven't seen any other platforms having similar issues.

And this just doesn't feel right, design-wise. It could take a long while loading user pictures, presence states, ancient chat history and extra fluff. But seeing the most recent messages* and having an impression of joining the room should be nearly instantaneous.

Still a huge improvement over what it used to be. I remember waiting for no less than 10 minutes in a similar scenario, and it used to consume nearly 100% of CPU available.

*) For some reason, previews never worked for me. Despite being able to join, when just trying to peek I always get either the never-ending "loading" spinner or "this room can't be previewed" message.

So the problem is that if you join a room with lots of different servers, your server has to go handshake with each one to check its signing key in order to verify the events the server has emitted. #synapse:matrix.org is almost by definition one of the worst rooms for this, given most people in there are joining from their own server.

Solving this is an interesting challenge - one option could be to opportunistically trust events. Another could be to opportunistically fetch server signing keys. A better one would be to implement MSC1228, which switches all our IDs for public keys, which should make verification much easier and less burdensome.

In terms of peeking rooms over federation - sadly this still isn't implemented yet. https://github.com/matrix-org/matrix-doc/blob/matthew/msc244... is the proposal to fix that however.

Ah, so the server that hosts the room is not fully authoritative and messages from participants are all signed by their respective server owners?

This makes sense. Thank you for explaining!

Yup, precisely. In Matrix, rooms are not hosted by any single server - instead, they're replicated over all participating servers, much like git. But you need to check the provenance of the original messages to stop spoofing, hence needing to go check signatures the first time you interact with messages from a given server. Once you're joined, things should be fast however.

Food for your UI folks' thought:

Basically it sounds like you can download the messages relatively quickly from any old server, but the first-time process of verifying takes awhile. Maybe there's a way to show that visually, so you can get the messages up on screen earlier, even if the content isn't trusted yet?

It also seems like there might be gains from prioritizing connections with servers whose members chatted more recently.

Oh, and there is construct as well, not to be forgotten (C++ homeserver). It federates, and works with most clients, though it lacks a few features (link previews, a couple others). I've interacted with a few of its users over federation, though I haven't tried it myself.

Compared to synapse's resource use, it seems completely anemic (I've read that the lead developer makes it run on a 800 MHz pentium, though that could have been a joke).

https://github.com/matrix-construct/construct

https://matrix.org/docs/projects/server/construct

Thanks for sharing! I’ll give them a look. As an aside, another protocol I would really love to see a simple implementation for is LDAP. Through my research, it seems that every LDAP controller server out there is just monstrous. I would love a cross-platform, turn-key solution that provides just the basics: user management, authentication, and replication. There has to be a better way to manage identities across internal networks.

Been self-hosting for a few weeks, and it's working exactly as expected. I find Slack to be slightly more reactive but not by much (I'm comparing a company-wide workspace of ~10 actually active people, vs a little channel of ~5 actually active people).

Personally though I can't stand the conversation view in Riot, the spacing between the nickname, the avatar and the text feels just wrong and I can't see in a glance who is talking and says what (yes, even with the compact view). It's minor, but it's the one I have under my eyes at all times so it's there. For now I'm using another snappier client (https://neo.pixie.town/) because of this issue.

Apart from this client-specific issue that doesn't say anything about the protocol itself, everything is fine.

The one thing I'm waiting for is rooms where participants are hidden, so that you actually get closer to a pubsub system. I have some ideas I want to try and play with, but this is needed if you want to keep some privacy

> Personally though I can't stand the conversation view in Riot, the spacing between the nickname, the avatar and the text feels just wrong

Does https://github.com/matrix-org/matrix-react-sdk/pull/4531 look any better? O:-)

> The one thing I'm waiting for is rooms where participants are hidden, so that you actually get closer to a pubsub system.

This is surprisingly hard (if you don't know what users are in a room, how do you know what servers to send messages to?) but we can provide at least a cosmetic solution (have the server filter out members below a given power level when relaying to the client). https://github.com/vector-im/riot-web/issues/6417 is the bug to upvote :)

> Does https://github.com/matrix-org/matrix-react-sdk/pull/4531 look any better? O:-)

Hey that's actually kinda sexy ! I'm not looking specifically for IRC-style <timestamp/nick/message>, I do like it when it takes a bit more space for the user, but I find this rendering nice to the eyes.

In the quote though, why is the user cast away on the right ? Would be more consistent to put it right next to the timestamp of the quoted text

Also, the nick is chopped at the end without any indicator that it is (like a [...] at the end or something)

All nitpicking, I know, I'll try this as soon as it lands because I already like it :)

> https://github.com/vector-im/riot-web/issues/6417 is the bug to upvote :)

I'm following it closely ! I can't wait to experiment around that, Matrix.org can be and needs to be much more than just a messaging protocol, there's everything needed to get rid of centralized silos of (micro-)blogging, status- or photo-based social networks, ...

BTW thank you for doing this and thank you for leading it all the way to it is today and to where it's gonna be tomorrow, there's a reason protocols fail or succeed and it's often not in the technical intricacies but definitely in the leadership that spearheads its spread. Matrix seems to be the one that has the biggest momentum for now :)

> In the quote though, why is the user cast away on the right ?

> Also, the nick is chopped at the end without any indicator that it is (like a [...] at the end or something)

These were just bugs in the first cut. I'll spin up a dev client and grab a screenshot of the final version (i think dev finished on it today!)

> BTW thank you for doing this

np. I just hope we realise the full potential of the project :) For what it's worth, I hope that Matrix can be to Slack/Discord what Linux was to Solaris/AIX. So, we just need to not screw up...

That looks a lot better, but I'd also like to be able to have timestamps and nicks on every line, like when the same person says 3 things in a row. This way if the first message were bumped off the screen, you don't have to scroll around to see who said it. (like irssi, hexchat, etc.)

> Does https://github.com/matrix-org/matrix-react-sdk/pull/4531 look any better? O:-)

Substantially better than the default Riot layout. I hope this gets merged and I get to switch to this soon.

That said, I'd still like a more compact version of the same that further reduces the spacing/padding to make more information fit on a single screen.

> > The one thing I'm waiting for is rooms where participants are hidden, so that you actually get closer to a pubsub system.

> This is surprisingly hard (if you don't know what users are in a room, how do you know what servers to send messages to?)

Can you expand on what your threat model is in this case? Because I assumed rakoo was just talking about a cosmetic change (possibly coupled with allowing pseudonymous users with low (read-only) permission levels, but you'd have to go out of your way to break that).

Not the parent, but I do think that looks better. I do think their client looks better than that, though. I'm a big fan of dark themes.

For the client experience, it's not even close: Slack's product experience is far superior. I love the idea of Riot as a decentralized e2ee group chat client, but the implementation is so buggy and far from being production-ready that any attempt to use it seriously is an exercise in frustration. In comparison, Slack is mildly annoying at worst, and usually just works.

If it were one or two little things, I'd file some bugs or even try to fix the issues myself in the Android app, but my experience has been that I have at least one experience-breaking bug or UX issue at least every other time I interact with the client. Especially if you have encryption enabled.

Thanks, that's helpful. When was the last time you used Matrix/Riot?

Today. I have a friend who insists on using either that or Snapchat, and Snapchat doesn't have a web client, so Riot wins for that reason alone.

True to form, I experienced yet another bug with the encryption moments ago: on web, search appears to be completely broken in e2ee rooms. It just says "No results", even for words that were said in literally the last message (and messages not far back in history from the previous day, so unlikely to be a caching issue).

E2EE search only works on Desktop currently. We need to spell that out in the UI.

Wow!

I don’t like slack having to use it for work. And riot/matrix has been slightly disappointing. At one point t I had everything flowing nicely; working fine until now the latest upgrade.

The verification within the client is confusing. The e2e cross signing has been an absolute headache. Meaning losing some encrypted messages because using your recovery key it throws an error (when it’s valid).

The potential is there but It does need work. My first impressions are that it feels like it’s all stringed together.

For example why have a button in the IOS app for resetting bootstrap only to display a message of “this button doesn’t work but will work in future”.

The default home server can be terribly slow. I get it, running your own server but still, I don’t want to do that right now.

It’s works when it wants to work. And when it does, it’s pleasurable and smooth.

https://github.com/vector-im/riot-web/issues/13519 expresses my frustration.

I think you hit the matrix.org server being completely overloaded immediately after we enabled cross-signing (https://twitter.com/matrixdotorg/status/1257695491497897988) - now fixed. You hit other teething bugs too where it didn't recover sufficiently from the overloaded server. Apologies :( The bug is open and on our radar, as you can see.

Any idea to when it might be fixed? I still can't verify any devices and using the Use Recovery Passphrase or Key method still responds with nothing.

If the whole premise of matrix is encrypted chat, and I can't verify myself, I'm hesitant in using the app. Luckily I am only using it to talk to a single friend so it's not a too big deal at the moment.

Sorry for this inconvenience. We're working on it, see linked issues to your issue.

I find Riot/Matrix to be very feature-poor compared to Discord and Slack, and not nearly as polished as Signal/WhatsApp for just pure chat purposes. Its best at nothing.

I find the lack of ability to group chat rooms, into discord "server" type things or Slack "workspaces" or whatever they're called, to be particularly deathknelling for Matrix's usefulness.

The matrix answer, "communities", are in the works, but who knows how good it will be.

I use it. It's extremely easy to setup your own server and I got mine running in about 30 minutes following their instructions. Aside from issues around key exchange in earlier versions, it's been great and on par with Discord or Slack, and with similar reliability.

I've been told the apps (Android/iOS) aren't as good as the Desktop version by coworkers.

Interesting - Riot is actually four entirely different codebases: Riot Web/Desktop (JS/TS/React), Riot iOS (ObjC/Swift), RiotX Android (Kotlin) and Riot Android (obsolete, Java).

Riot iOS has been a bit under resourced over the last few years, but other than some jank it's a decent native app, albeit trailing behind Desktop a bit. RiotX meanwhile is of very similar quality to Desktop, albeit beta (but exiting next month, hopefully). Finally, Riot Android is abandoned now and we'll replace it with RiotX when RiotX is ready. Many folks' bad impression of Riot on mobile is due to Riot Android having been abandoned in favour of RiotX or the last year - such is the cost of a rewrite :/

Do you know why the decision was made to rewrite rather than do an incremental migration, given the increased pain to users? I have some guesses from looking at the codebase, but I'd love to know the actual answer.

The old app had bad layering, and no explicit storage layer. We wanted to experiment with different storage layers, use rx for data flow, switch from java to kotlin, and use all the latest androidx/jetpack best practices. This amounted to a whole new app, and it was easier to start from scratch, despite the disruption to users.

I have to say riotx is miles ahead of riot android. If only it could do voice and video yet. For desktop I have to say riot has been really on and off. In particular voice/video calls are hit and miss. Sometimes it rings but one can't pick up, sometimes it just does not ring. I actually have been experimenting with some of the alternative clients (I particularly like nheko reborn) unfortunately non do voice video yet.

the 1:1 voip in Matrix has never been properly fleshed out. we’re planning to fix this over the next few months however.

Usable for technical people,but as they note at the end of the blog post, they have ways to go with respect to first time user experience.

I tried getting a team of tech savvy people to use it for backup encrypted comms, the UX was horrid, the key verification just didn't work at the time. Hopefully this is fixed.

I am hoping a commercial product comes out of this,so they have proper QA and UAT. The FOSS approach of filing an issue/bug when basic things fail does not translate well to a generic audience. The protocol and Riot are actually decent,but I think the UX has yet to catch up with the rich feature set.

Both Signal and Slack just worked. Slack has great UX, Signal is mediocre but from a security perspective, many things are non-obvious which to me feels like a dark pattern of insecurity,Riot maybe more painful but fails in more obvious ways.

> the UX was horrid, the key verification just didn't work at the time. Hopefully this is fixed.

This is what we've tried to fix in this release :) Meanwhile, as you note, first time user experience is our single biggest project now e2ee-by-default is shipped.

I've been trying it these days, I'd say Slack is much slicker, but the differences are bridgeable.

One thing I don't like is that your message shows in grey for a few secs in Matrix. What does it mean? I don't know. But what does it feel like? Like it's lagging.

On HN I'm always seeing a fight between Signal and Matrix. Can someone explain this to me? As far as I see it: Signal replaces SMS; Matrix replaces Slack/IRC. These seem like different products that work in different spaces.

Among technologists, the two most divisive aspects of Signal are that it requires phone numbers, and that it isn't (and likely won't ever be) federated --- that is, you can't run your own Signal server and be accessible to people using ordinary Signal clients.

Matrix doesn't use phone numbers, and is federated (that's what makes Matrix interesting), so it's naturally the "antidote" suggestion on threads when people bring up these aspects of Signal.

The fact is that they're not really comparable projects; they have different audiences and different goals. People have an innate narrative bias that constant hunts for horse races to spectate, and so you'll see a lot of "Signal vs. Matrix" arguments, but it's an artifact, not anything substantive.

I know you're just citing the arguments, but I can't help but respond.

I always see Signal as being "really good" crypto. Bulletproof? No, surely not. That doesn't exist. If I were a dissident or something I would be using gpg religiously and all that jazz.

But is signal significantly better than basically every mainstream sms-like thing? Absolutely! imessage, sms, mms, whatapp, facebook messenger, whatever google's current chat app is, etc. All of them don't even try to be a secure/privacy-respecting chat tool and reall y make no secret that they're usually totally the opposite (facebook messenger....).

So when it comes to getting my parents onto something that sends videos of the kids real good and also will make dragnet state surveillance efforts a bit harder, I pick Signal.

The cryptography in Signal is substantially better than that of GPG. You would have a very hard time finding a cryptography engineer that disagreed with that.

>The fact is that they're not really comparable projects; they have different audiences and different goals.

Agree on the second part, but two messaging solutions can and should be compared. 1-to-1 (text/voice/video) messaging is entirely possible with both Signal and Matrix, and evaluating that narrow use case is a reasonable way to compare the two.

Lots of technologists believe that everyone should use IRC, or some next-gen IRC-alike, to communicate. Anything you can do with a specialized messaging app you can do with a messaging relay network. But, of course, specialized messaging apps outstrip messaging relay networks by orders of magnitude; IRC itself has usage that is a rounding error of WhatsApp's. Most people do not perceive any value from being part of a federated relay network; the audiences are not, in fact, the same.

Again, I agree with you that the audiences are not the same. I specifically agreed with that statement in my comment.

Oh, I misread "the second part". Sure, you can compare anything, but I'd dispute that it's always productive to do so.

Well, actually, given the end to end encryption in Matrix, nothing is stopping users from completely replacing Signal with a Matrix client which acts exactly like it.

There's nothing about the Matrix protocol that makes it better for one or the other though; it's a pretty general messaging protocol. Riot looks more like Slack, yes, but there are other clients that look more like SMS apps, e.g.: https://dittochat.org/

That's a really great example for showing the difference between federated protocols and what Signal is doing, since according to their roadmap support for end-to-end encryption is still in the planning stages: https://ditto.upvoty.com/b/feature-requests/end-to-end-encry...

THANKS! This actually clears things up better than the other comments. Is there a list of these things somewhere so I can learn more?

This is probably the best place to start: https://matrix.org/clients

And of course more broadly, Matrix as a whole isn't even limited to only messaging apps, although that's where most of the focus has been thus far. There have been some fun demos/projects in the past though:

- Synchronized presentation slides: https://github.com/Half-Shot/matrix-presents

- MIDI over Matrix: https://github.com/McOmghall/midi-over-matrix

- VR videoconferencing: https://matrix.org/docs/projects/other/matrix-vr-demo

Well, https://matrix.org is a good place to start (but could use a face-lift for non-techies). There's a good list of clients, servers, SDKs, etc at https://matrix.org/docs/projects/try-matrix-now

And of course, there is the Matrix spec itself, but I learned most of what I know idling in matrix channels (#matrix:matrix.org and #synapse:matrix.org) and hosting my own synapse instance.

Damn, this looks good! Thanks for the link!

Fair warning, that one’s fairly early in development. What is implemented works well, but I wouldn’t say it’s a Riot replacement quite yet.

FluffyChat is similar, and seems to be a bit further along (it has basic e2e crypto support for example) -https://christianpauly.gitlab.io/fluffychat-website/en/

Thanks for the suggestion. It looks awesome!

But maybe people don't want to use different software for the same purpose: sending text to other people. No matter they are on a PC or smartphone. That's what botters me with Signal. Bound to a phone (number).

But Signal just works and is fast (though not as fast as WhatsApp)

Matrix in the default login also works, but when you choose the default open Matrix Server ... it is slow.

So I also will continue to use .. not only 2 but 6 different text sending applications. But in the future I would love to just use the Matrix protocol and one software.

I guess the difference I see is that texting I find useful for one on one conversation, or a small group. Slack I find good for big groups. I actually like to have two different apps for these because it lets me better compartmentalize my socialization, especially since the latter tends to be associated with work (I like to compartmentalize work from my social life).

I see Matrix as a sort of generalization of Signal. It's federated and decentralized, and they literally had to scale up the E2E system that Signal came up with. I use it for every form of digital communication (bridges are nice) including 1-to-1 but I think most would use it for group chats or organizations.

Well, I consider this a pretty accurate description.

Perfect timing: https://news.ycombinator.com/item?id=23102430 Congratulations!

Pretty sure the person posting the Matrix page knew this

Actually this was all released a couple of days ago, just took a bit of time for them to write the blog post.

Tox is:

* Still alive.

* Still open source libraries and most clients.

* Still mandatory e2e encrypted. (unlike matrix)

* Still always-on full forward secrecy. (unlike matrix)

* Still full p2p. (unlike matrix)

* Still works fine.

Just saying.

Why isn't Tox more popular? The difference has to be the amount of money/effort spent in marketing.

I remember back few years ago, they had some very serious foundational mistakes in their protocol, which they handwaved away and started blaming people for pointing them out, as in "it's more important to get something working than do it properly".

Not sure if they got better since then.

edit: yeah this issue

https://github.com/TokTok/c-toxcore/issues/426

and the discussion here (2017)

https://news.ycombinator.com/item?id=13392128

Acknowledged and handwaved aren't the same thing. It will be fixed at the first opportunity (change requires breaking the protocol, and they definitely want to get more done in one go when they do that).

And it's remarkable that the only issue cryptoanalysts found is this one which requires your private key to be stolen in order to fake messages from your friends to you.

Isn't tox the one from 4chan /g/?

Not to deride them just for coming from 4chan, but I really seriously doubt there's been thorough 3rd party auditing of the protocol and code.

IIRC signal has been audited?

Based on some quick searching, it looks like Tox doesn't support offline messaging. Not saying that is the reasoning, but I thought it was interesting. That said, it does looks like it's worth considering overall!

It does, in the same fashion Skype used to.

Message is saved on the sender's client until the receiver is online.

Relatively shitty client and poor mobile support? I am just guessing.

Full p2p implies a lot network traffic even when idle. Killer argument against mobile use.

How it work through NATs?

It implements hole punching.

Hole punching works for firewalls, but is unreliable for NATs. Note that most home routers are Linux based, and Linux uses symmetric NAT, where hole punching does not generally work reliably.

It also implements relays, if both sides can't be reached.

And it works with TCP, if it can't be made to work with UDP.

And it supports ipv6.

You're pretty much covered.

IPv6 fixes that for those cases where you have too much NAT on both ends.

See also https://news.ycombinator.com/item?id=23092269 and https://news.ycombinator.com/item?id=23088852 (these should be merged perhaps)?

For those looking to selfhost synapse and riot, we (cloudron.io) recently made both these packages stable. If you need help in setting them up, happy to help here (even if not on cloudron)

Is there a Python SDK that supports encryption well yet? I have a simple command line script to send a message to a Matrix room. About three months ago I tried to add encryption, but apparently the old matrix-python-sdk is deprecated in favor of matrix-nio, but encryption support in the latter was very marginal still.

matrix-nio's encryption is very robust now, but by far the easiest way to hook up a simple commandline script is to pipe it through pantalaimon (https://github.com/matrix-org/pantalaimon) - which acts as a daemon to offload E2EE from your script, using matrix-nio under the hood.

you should be able to get encryption working with nio now. nio-template is a good start https://github.com/anoadragon453/nio-template

Have you guys tried Olvid https://olvid.io/en/, they removed the servers principle entirely. Worth trying

Yay! This is the right move for their users.

There's still a ton of work left to do, but I'm thankful for all the hard work that went into making this possible.

w00t! my computer club hosts a homeserver and it's been running so smoothly since we upgraded.

How is memory consumption going? I'm waiting for improvement in this area or a stable release of Dendrite [0] (hoping it has a reasonable memory usage).

0: https://github.com/matrix-org/dendrite

I heard there's a telegram-like client for Matrix? Is it still around?

nheko is pretty similar to TG and is reborn and evolving well after a hiatus a few years back: https://github.com/Nheko-Reborn/nheko

Pattle maybe ? https://git.pattle.im/pattle/app

Does this use ephemeral secrets/is it forward secret?

Can see this info in the blog.

It depends on the layer. Matrix used Olm for device-to-fecice encryption, which is a clone of Signal’s double ratchet, and is PFS. For message history however we use Megolm, which is a simpler hash ratchet which is synchronised across the members of a group by sharing its state over Olm. You typically replace the Megolm ratchet every 100 msgs or 1 week, but depending on how fast you do that and how long you store the keys for, you can get PFS. The problem is that most users want to be able to access their chat history from the server, which is by definition incompatible with PFS as you have to keep the message keys around to decrypt the msgs.

How they made scalable webrtc end-to-end encrypted? I guess it is not scalable (~5 members max).

Multi-way video conferencing in Matrix isn't e2ee yet; the e2ee-by-default here refers to private group chats, DMs, and 1:1 video/voip calls.

Once Jitsi lands their E2EE support (hopefully using Matrix's E2EE for key management, c.f. https://news.ycombinator.com/item?id=22855407) then we'll get E2EE video conferencing too.

Until then, Matrix (but not Riot) also supports E2EE video conferencing via full mesh webrtc, but as you say, it scales to relatively few users.

Insertable streams are not going to help much since if it encrypts every frame this would mean that every frame will be encrypted and therefore couldn't be compressed. It doesn't make sense actually since you could just encrypt RTP payloads instead keeping service messages in plain text.

Insertable streams let you encrypt the compressed media.

WebRTC doesn’t give you hooks to re-encrypt the SRTP payloads.

How does this visualisations are done? How it could "decode" incorrect image and display as a demo in various articles?

I do not believe that video codecs are able to decode over "encrypted" data and produce some video stream.

the point of insertable streams is that you can hook into the compressed payloads and encrypt them after compression, and then decrypt them before decompression. The codec never sees encrypted data.

Reply on news.ycombinator.com