3 ms·

IRC's longevity and appeal is fascinating - it seems like that the more constrained the bandwidth of communication, the more compact the configuration, and the

IRC's longevity and appeal is fascinating - it seems like that the more constrained the bandwidth of communication, the more compact the configuration, and the more quirky and charismatic everyone's favourite clients (be they irssi, weechat, mIRC, xchat...) the more staying power a comms medium has. My workplace started off life ~15 years ago as a channel on a small student IRC network - the company effectively evolved out of IRC. The importance of IRC bots (be they eggdrops, or pircbot, or whatever) also seems to have become core to IRC culture - a well implemented IRC bot can be an incredibly powerful tool for glueing a community together. All this makes it incredibly hard when considering what could come after IRC, if anything. XMPP's MUCs just don't seem to have the same sticking power, and meanwhile things like Slack and HipChat come along and risk hijacking all our comms into closed silos rather than the relative openness of IRC and XMPP. Regardless, after 15 years of addiction to IRC we're having a go at coming up with something better that still has some of the same appeal. The project is called Matrix.org, and the main differences to IRC are: * Open federation; anyone can spin up a server and join in. * Conversation history (i.e. scrollback) is the main building block - a room's history is stored (partially or completely) over all the servers who are participating in a room. So there's no single point of control or failure. * Compulsory cryptographically signed message history (necessary due to the open federation) * Simple HTTP/JSON client-server API. (Server-server API is also HTTPS/JSON) * Store arbitrary structured data in the room - not just text messages. So you can use it for setting up VoIP calls; whiteboarding info; random device telemetry, or whatever. * Built-in distributed file storage (no more DCC, for better or worse) * Strong identity and end-to-end encryption (via a variant of Axolotl; currently in dev) * Support for 3rd party IDs - contact people based on their mail address, phone number, or whatever details folks chose to identify themselves by. So if you like IRC and are interested in a fairly radical alternative, please drop by http://matrix.org/beta http://matrix.org/beta and say hi. It's in early beta, but it's fairly usable - we have Android and iOS clients and SDKs for python, perl, iOS, Android and an increasingly active dev community. Also, it's not frozen yet, so now is a great chance to get involved and make sure we get it right :)

laumars 12y ago
The signed messages history and end-to-end encryption sounds interesting, but largely from a "how is this going to work in public rooms" perspective. IRC is largely a broadcast tool in the same sense that many social networks are. With IRC, you generally chat in open channels where anybody can join. While encryption protects against MITM, the privacy arguments are moot given the broadcast nature of public chat rooms. So to combine that with server-held scrollbacks, and I'm left really curious about your intended usage / benefits of end-to-end encryption. So if you would you mind discussing a little more detail about that aspect of your chat protocol, I'd certainly be very interested in reading it :)
- Arathorn 12y ago
  So, signed-message history is purely for integrity, not privacy. The problem is that if all your rooms are completely decentralised, how do you stop a rogue server injecting false information about the past? All servers have a keypair that they use to sign messages they originate, and this signature includes pointers to the 'parent' message(s) that immediately precede them in the conversation. Thus every message asserts the integrity of the graph of messages in a room up to that point, and means that a rogue server can't start censoring history, or claiming its users have privileges, or whatever in retrospect. The full details for signing message history can be found at https://github.com/matrix-org/matrix-doc/blob/master/specification/11_event_signing.rst https://github.com/matrix-org/matrix-doc/blob/master/specifi.... End-to-end crypto is another matter. It can make sense both for private and public chat rooms (if you define public rooms as ones which any member of the public can be invited into by an existing member), as if you use perfectly forward secrecy even a public room ends up being a secure distribution channel for the members - each message has a unique key which can be discarded by the clients after that message is downloaded and decrypted, meaning that the history cannot be replayed by an attacker. However, there's obviously a compromise between deliberately replayable history (after all, Matrix is all about synchronised conversation history) and PFS. So we've tried to be pragmatic and give the user a choice per-room to decide how secure the history should be. At one end of the spectrum, you can pick a single key for the room which never changes - killing any PFS but meaning that any new client or device can read infinite scrollback for the room. At the other end of the spectrum you have pure PFS. In the middle, you have the ability to re-key the room for different criteria - e.g. changing the key whenever the membership state of a room changes, or applying different keys for different types of messages. This allows clients to cache as many keys as they need in order to replay the different classes of data (and for PFS, a client could chose to cache keys too to allow limited re-synchronisation from the server). The actual ratchet we're using to evolve the keys is a axolotl. All of the end-to-end crypto is currently in development, but we're just finishing the C++ axolotl implementation currently which will then be the reference implementation for all the various Matrix clients out there. And all of end-to-end crypto is optional: you can't join an encrypted room if your client doesn't do encryption, but we don't force clients or rooms to be encrypted if their users don't want them to be. There's a longer (high level) explanation of all this on http://lwn.net/Articles/634144/ http://lwn.net/Articles/634144/.

laumars 12y ago

The signed messages history and end-to-end encryption sounds interesting, but largely from a "how is this going to work in public rooms" perspective. IRC is largely a broadcast tool in the same sense that many social networks are. With IRC, you generally chat in open channels where anybody can join. While encryption protects against MITM, the privacy arguments are moot given the broadcast nature of public chat rooms. So to combine that with server-held scrollbacks, and I'm left really curious about your intended usage / benefits of end-to-end encryption. So if you would you mind discussing a little more detail about that aspect of your chat protocol, I'd certainly be very interested in reading it :)

Arathorn 12y ago
So, signed-message history is purely for integrity, not privacy. The problem is that if all your rooms are completely decentralised, how do you stop a rogue server injecting false information about the past? All servers have a keypair that they use to sign messages they originate, and this signature includes pointers to the 'parent' message(s) that immediately precede them in the conversation. Thus every message asserts the integrity of the graph of messages in a room up to that point, and means that a rogue server can't start censoring history, or claiming its users have privileges, or whatever in retrospect. The full details for signing message history can be found at https://github.com/matrix-org/matrix-doc/blob/master/specification/11_event_signing.rst https://github.com/matrix-org/matrix-doc/blob/master/specifi.... End-to-end crypto is another matter. It can make sense both for private and public chat rooms (if you define public rooms as ones which any member of the public can be invited into by an existing member), as if you use perfectly forward secrecy even a public room ends up being a secure distribution channel for the members - each message has a unique key which can be discarded by the clients after that message is downloaded and decrypted, meaning that the history cannot be replayed by an attacker. However, there's obviously a compromise between deliberately replayable history (after all, Matrix is all about synchronised conversation history) and PFS. So we've tried to be pragmatic and give the user a choice per-room to decide how secure the history should be. At one end of the spectrum, you can pick a single key for the room which never changes - killing any PFS but meaning that any new client or device can read infinite scrollback for the room. At the other end of the spectrum you have pure PFS. In the middle, you have the ability to re-key the room for different criteria - e.g. changing the key whenever the membership state of a room changes, or applying different keys for different types of messages. This allows clients to cache as many keys as they need in order to replay the different classes of data (and for PFS, a client could chose to cache keys too to allow limited re-synchronisation from the server). The actual ratchet we're using to evolve the keys is a axolotl. All of the end-to-end crypto is currently in development, but we're just finishing the C++ axolotl implementation currently which will then be the reference implementation for all the various Matrix clients out there. And all of end-to-end crypto is optional: you can't join an encrypted room if your client doesn't do encryption, but we don't force clients or rooms to be encrypted if their users don't want them to be. There's a longer (high level) explanation of all this on http://lwn.net/Articles/634144/ http://lwn.net/Articles/634144/.