What should the next chat app look like?(drewdevault.com)
drewdevault.com
What should the next chat app look like?
https://drewdevault.com/2021/04/07/The-next-chat-app.html
3 comments
> Let's quickly address the present state of the ecosystem. Matrix rates well in most of these respects, much better than others. However, their software is way too complicated. They are federated, but the software is far from reliable or robust, so the ecosystem tends to be centralized because Matrix.org are the only ones who have the knowledge and bandwidth to keep it up and running. The performance sucks, client and server both, and their UX for E2EE is confusing and difficult to use.
This sounds more an argument for improving work on some of the alternate Matrix server implementations that, on paper, should suck a bit less (Dendrite showing promise, though getting the C++ version up to speed wouldn't be a bad idea either).
A lot of the problems with the Matrix ecosystem are fundamentally problems with the reference homeserver implementation, Synapse, being written in Python - and being, as a result, a rather bloated, slow, hungry memory pig. No arguments from me, I run a Matrix homeserver and the thing is a pig (about 2 decades ago, I ran an IRC network on a pair of Mac SE/30s - yes, obsolete at the time, and worked just fine for the task). You can get away with a smaller homeserver host as long as nobody joins any gigantic rooms.
Federation is a minor pain to set up and keep working, but unless I've missed something, the biggest hassle is the lack of monitoring infrastructure (optional, of course). I can manually run the Federation Checker to see if my server is weird, but without a way to say "Hey, I'm the admin for this server, let me know if it goes wrong," it's up to admins to notice federation is broken. I have a number of users on my server, but apparently nobody actually talks outside my server, because my federation was broken for... longer than it ought to have been, and nobody noticed.
On the other hand, being able to stand up isolated servers for a family or something is quite nice. The downside, right now, is that Element (the flagship Matrix client) doesn't support multiple users in the way that Hangouts (and perhaps other clients, not as familiar with them) does. That would be a huge improvement.
I agree with the list of items presented, and at this point think Matrix is "some tweaks and improvements" away from being there, as opposed to "totally unable to get there." It is a somewhat heavy system to use for text based chat, but it also works, works fairly well, and isn't utterly impossible to set up on the sysadmin side. Once someone is running a homeserver, getting users added is quite straightforward for the users, and Element is just as well behaved as a client as Hangouts or Signal, in my experience (well, better than Signal, it's not phone number first).
This sounds more an argument for improving work on some of the alternate Matrix server implementations that, on paper, should suck a bit less (Dendrite showing promise, though getting the C++ version up to speed wouldn't be a bad idea either).
A lot of the problems with the Matrix ecosystem are fundamentally problems with the reference homeserver implementation, Synapse, being written in Python - and being, as a result, a rather bloated, slow, hungry memory pig. No arguments from me, I run a Matrix homeserver and the thing is a pig (about 2 decades ago, I ran an IRC network on a pair of Mac SE/30s - yes, obsolete at the time, and worked just fine for the task). You can get away with a smaller homeserver host as long as nobody joins any gigantic rooms.
Federation is a minor pain to set up and keep working, but unless I've missed something, the biggest hassle is the lack of monitoring infrastructure (optional, of course). I can manually run the Federation Checker to see if my server is weird, but without a way to say "Hey, I'm the admin for this server, let me know if it goes wrong," it's up to admins to notice federation is broken. I have a number of users on my server, but apparently nobody actually talks outside my server, because my federation was broken for... longer than it ought to have been, and nobody noticed.
On the other hand, being able to stand up isolated servers for a family or something is quite nice. The downside, right now, is that Element (the flagship Matrix client) doesn't support multiple users in the way that Hangouts (and perhaps other clients, not as familiar with them) does. That would be a huge improvement.
I agree with the list of items presented, and at this point think Matrix is "some tweaks and improvements" away from being there, as opposed to "totally unable to get there." It is a somewhat heavy system to use for text based chat, but it also works, works fairly well, and isn't utterly impossible to set up on the sysadmin side. Once someone is running a homeserver, getting users added is quite straightforward for the users, and Element is just as well behaved as a client as Hangouts or Signal, in my experience (well, better than Signal, it's not phone number first).
My beef with many chat apps is to have to authenticate with my telephone number or an email address. Both are hard to acquire in sufficient quantities for a 'normal' user.
So I came up with a decentralised authentication system.
It offers easy key exchange between total strangers. Once they create an private channel there is no way for authorities to take it back.
Here's the protocol:
Signup: - each site operates an automated CA; - an account is a nickname and public key; - the sites' CA creates a certificate binding the nickname, public key and site-root-CA together; - the user's User Agent does the hard work of the crypto.
Requirement: the nickname and public key have not been seen before, the CA rejects when either has seen before. This creates a one-to-one mapping between nicknames and public keys. This one-to-one relationship will be verified. All hell breaks lose for the automated CA that cannot comply with that simple requirement: uniqueness.
Posting messages: - users can create as many accounts at each site; - users can post public messages at that site, the messages are signed using the account's private key.
Reading messages: - the site publishes the message signature along with the message (perhaps hidden with CSS); - the user's user agent verifies the signature; - if the signature matches, (and the uniqness requirement holds) the agent offers the user the option to write a private message, encrypted using the public key that has been validated form the signature.
The reader then writes a private message to the writer of a post. The site delivers it (or not). But if yes, then we have a successful key exchange between two people who have never met in real life!
To repeat: This does not give any certainty about the person behind the signed message, all it offers is a key exchange between strangers.
This opens new avenues. Suppose the reader (of the message) starts a tor hidden service and sends the onion address to the writer. When the writer wants to, he connects to the reader, both authenticate using their private keys and set up a session key. They now have a secure channel, independent of the site. In fact, when the site gets censored, this channel remains.
I wrote a lot about it this on my site: https://eccentric-authentication.nl/
So I came up with a decentralised authentication system.
It offers easy key exchange between total strangers. Once they create an private channel there is no way for authorities to take it back.
Here's the protocol:
Signup: - each site operates an automated CA; - an account is a nickname and public key; - the sites' CA creates a certificate binding the nickname, public key and site-root-CA together; - the user's User Agent does the hard work of the crypto.
Requirement: the nickname and public key have not been seen before, the CA rejects when either has seen before. This creates a one-to-one mapping between nicknames and public keys. This one-to-one relationship will be verified. All hell breaks lose for the automated CA that cannot comply with that simple requirement: uniqueness.
Posting messages: - users can create as many accounts at each site; - users can post public messages at that site, the messages are signed using the account's private key.
Reading messages: - the site publishes the message signature along with the message (perhaps hidden with CSS); - the user's user agent verifies the signature; - if the signature matches, (and the uniqness requirement holds) the agent offers the user the option to write a private message, encrypted using the public key that has been validated form the signature.
The reader then writes a private message to the writer of a post. The site delivers it (or not). But if yes, then we have a successful key exchange between two people who have never met in real life!
To repeat: This does not give any certainty about the person behind the signed message, all it offers is a key exchange between strangers.
This opens new avenues. Suppose the reader (of the message) starts a tor hidden service and sends the onion address to the writer. When the writer wants to, he connects to the reader, both authenticate using their private keys and set up a session key. They now have a secure channel, independent of the site. In fact, when the site gets censored, this channel remains.
I wrote a lot about it this on my site: https://eccentric-authentication.nl/
>...if you want to support voice or video chat (please don’t), that’ll complicate things even more.
But not very much. If you define a method to securely establish a shared secret then this sort of thing can be an entirely different standard hopefully implemented as a separate binary running in a separate security context.