I think rather then federation people need real P2P systems and not only clients to a server. Specially I don't think that heavy relying on HTTP makes sense here - in addition it implies that the encryption you get is SSL, which is awkward. Things like GnuNet are of course not ready, but as you can see with people using Tox right now for communication, P2P networks allow to start a new design with respect to a good cryption model and methods improving anonymity of communication flows.
A server can do a lot for you that a standalone client can't. It's a machine that's always on, easy to back up, lets users communicate in real time, and the coordination of different client devices per account comes practically for free.
I think one of the reasons federated systems (which once were the backbone of the internet) are being phased out while the huge monoliths like Facebook are winning is that, while people do want a federated alternative, they want this alternative to be philosophically pure in a way that makes the end user experience untenable.
I'm building an open source distributed social network quite similar to this Matrix thing, actually. It's simple, scalable, and it works. It provides a good user experience, too. But fellow geeks tend to hate it. JSON over SSL? Too simplistic. 'We want a VM that runs inside a JavaScript engine which implements its own crypto and _true_ P2P, nothing else will do.'
The trouble is we do know how to make simple and "awkward" solutions work quite well, whereas I have yet to see a "pure" option I'd want to use myself. Of course, that may be personal preference in the end, but I'm kind of hoping I'm not alone.
Multiple device support and history synchronization between devices really are table stakes to me, especially since I tend to spend a lot of time checking messages and chatting from mobile devices these days..
That distributed social network thing sounds quite exciting, and very much in a similar vein as Matrix. Does it have a website/github repo yet?
We've definitely found its not always easy to balance a philosophically pure/technically nice solution with one that actually has a usable UX. Although it sometimes seems that half the battle is figuring out what actually is a usable UX...
> Multiple device support and history synchronization between devices really are table stakes to me
I know where you're coming from.
We're working (well, it's just two guys for the moment) on the first version and we're planning to launch for early feedback soon. I'll be posting it as a Show HN, but in case it gets buried I can put you on our notify list - just shoot me an email.
Not yet, for the simple reason that the spec isn't stable yet. We're doing an early feedback launch soon, I can notify if you want. We'll put the reference implementation on GitHub, too.
One of the things that's important to me is the option for "3rd party software" to participate in the network as well, so we're keeping it as simple as possible to enable others to build stuff that integrates with it.
I guess even the offline thing may not be a problem as long as the messages are in a room that is hosted over an always-on server. The bundled server will be able to sync up its history from the always-on server.
