This is absolutely the type of system I've been hoping for for quite a while. I even started drafting up a spec to build it. I wanted a federated, http based message passing pub/sub type system with device synchronization - and (here's the kicker) - encryption optional.
So why don't I want encryption? Simple, my intended use is in amateur radio, where encryption is in fact restricted (basically, you can only use it to control a satellite).
In amateur radio, we have been developing this mesh network (basically wifi mesh, but we can use much higher power and alternate, non-line-of-sight frequencies like 440Mhz). With the HSMM-Mesh system, we have built in dhcp, dns, ability to advertise services (web, irc, etc) on systems that are usually completely isolated from the Internet at large. We run this on re-purposed routers, laptops, raspberry pis, etc. So you can setup an IRC, FTP, or web server on a pi, someone else can bring a node up within range of your wireless signal, see your node, get a list of services you offer, and use them.
An issue with this is that you want to make multiple "field nodes" and deploy them
So matrix would work really well here. Since each node has its own DNS name (based on our call sign), you could run a matrix server, set people up with the clients, and if we learn of another matrix server on the mesh, federate with it. The two matrixes become consistent eventually. If we bring a node (these would all be battery powered portable) into range of a more permanent fixed station, all the days activity could end up on that fixed station. The fixed station could federate with an Internet instance as well (which would require more extensive validation to ensure users are licensed operators).
A few issues would be user registration - we'd have to disable verification in the field as there won't be email. I don't think we'll have username conflicts. USER1@SERVER1 won't conflict with USER1@SERVER2. Since all users are government issued call signs, identity will be consistent across each matrix server.
I also wanted to point out that it would be easy to use something like twisted to write an IRC or XMPP gateway to a specific matrix server. Then you can utilize a common IRC or XMPP client (though message ordering might be a major issue in an occasionally connected environment).
This would be a really cool use for Matrix - the eventual consistency and offline operation stuff is a perfect fit :D
You don't need an email address to sign up currently - the way it works is that it's up to the homeserver to decide how to validate new users (if at all). So Matrix.org uses a CAPTCHA to check you're human, but otherwise just sends a username & password. We also let you optionally specify a mail address, mainly just to prove that we do support validating 3rd party IDs like email (and in future MSISDNs and other IDs).
For gatewaying, the main thing we've been missing is an Application Service (AS) API on Matrix which lets your gateway masquerade multiple users & rooms/channels from the remote protocol. Currently you can write a back-to-back bot which creates, per user, an IRC user on the IRC network and a Matrix user on the Matrix network and bridges them together - this is how the current Matrix<->IRC bridge works. This sucks if you want to easily project hundreds of users & channels from IRC into Matrix and vice versa, though - you need better server support, a bit like IRC Services' architecture.
So why don't I want encryption? Simple, my intended use is in amateur radio, where encryption is in fact restricted (basically, you can only use it to control a satellite).
In amateur radio, we have been developing this mesh network (basically wifi mesh, but we can use much higher power and alternate, non-line-of-sight frequencies like 440Mhz). With the HSMM-Mesh system, we have built in dhcp, dns, ability to advertise services (web, irc, etc) on systems that are usually completely isolated from the Internet at large. We run this on re-purposed routers, laptops, raspberry pis, etc. So you can setup an IRC, FTP, or web server on a pi, someone else can bring a node up within range of your wireless signal, see your node, get a list of services you offer, and use them.
An issue with this is that you want to make multiple "field nodes" and deploy them
So matrix would work really well here. Since each node has its own DNS name (based on our call sign), you could run a matrix server, set people up with the clients, and if we learn of another matrix server on the mesh, federate with it. The two matrixes become consistent eventually. If we bring a node (these would all be battery powered portable) into range of a more permanent fixed station, all the days activity could end up on that fixed station. The fixed station could federate with an Internet instance as well (which would require more extensive validation to ensure users are licensed operators).
A few issues would be user registration - we'd have to disable verification in the field as there won't be email. I don't think we'll have username conflicts. USER1@SERVER1 won't conflict with USER1@SERVER2. Since all users are government issued call signs, identity will be consistent across each matrix server.