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 :)
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/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/.
Interesting - this is new to me (and ironic, given Aether was a candidate name for Matrix!). The projects seem very similar in some ways - both python/twisted/sqlite server stacks + angular frontend. The big differences seem to be that Aether is using AMP as its federation protocol rather than Matrix's HTTP/JSON federated DAGs, and is focused initially on forums rather than IM/VoIP. It's a bit strange that it advertises itself as entirely peer-to-peer though, when seemingly it is very much a client-server model (with server/server federation) just like Matrix, SMTP or XMPP. It's also slightly strange that the github repo is only showing certain drops from a private repo - I wonder why the dev isn't happening in the open. It's also hard to see what the actual decentralisation algorithm is, beyond replication. It doesn't seem to be using DAGs for eventual consistency or signing forum history.
In terms of anti-spam proof-of-work stuff, identity, sybil attacks and all the good stuff mentioned at http://blog.getaether.net/post/101566226287/a-few-updates-ab... it sounds like Aether & Matrix are at a fairly similar point. It would be super-cool to chat to Burak and get the two federated together (after all, Matrix is all about being glue between other communication media) - will ping him :)
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 :)