I intend to present an idea heavily based on the marvellous proposals by rysiek and pettter. It is about breaking the garden walls and creating community servers (a “Commune” is the concept of a multi-user server setup with federating software) And it is up to us techies, the 1%, to do this for the rest of teh internets. I take no responsibility for any originality in this post (perhaps there is none), it is just a summary of great minds that think alike.
First, some background. There are about a zillion free, federating software implementations of federated social technology operating on various homegrown protocols and/or APIs. Few of these interoperate. If they interoperate, it is seldom a very reliable or user friendly experience. While we probably can live with this, and may find the debugging fun to do, the 99% are appalled and turn away. This far I believe everyone agrees.
The goal, in my opinion, is to have freedom not just with the choice of service provider but of course also with software. The benefits of an all-encompassing protocol is that anyone can implement it, making it possible to design implementations not just for web and desktop clients – but also embedded hardware that will build the future Internet of Things. I suppose most of you reading this are still on the same track. Except that we still can’t seem to “devise a single, workable protocol“.
Some of my personal preconceptions
Before I describe the idea, here is where I might diverge from the general line of thought, I wish to point out that my ideas are derived from reasoning regarding “Fedsocweb and the FreedomBox“. I strongly believe that there can’t be a single, global state (“I don’t have the full conversation from three federating nodes” etc.).
A last, important, detail is that I believe that the “federated social web” is not trying to protect rebels in dictatorships with this (like FreedomBox or TOR do). We’re trying to pass control of information closer to the originating party and away from a single hoarding third party – and be social while doing it! It may help from mass data analysis, but pure anonymity is a somewhat different business.
The simple idea of reusing technology
To sum it up, I believe we don’t have to design anything new. We already have the tools necessary, mostly fine-tuned and ready for federated services. Existing software, protocol and infrastructure performs just fine already, here are some of them. This is not an exhaustive list, and it’s in a pretty arbitrary order. I just wanted to get it out there in text:
- Sender/receiver authentication.
GnuPG is designed for this, though somewhat hard to use. However, if the GPG stuff is entirely handled by each respective software, having access either to the same keys or properly assigned subkeys, users don’t have to bother with the tricky interface.
- Visualize and enrich communication for the user’s liking.
HTML5, CSS (+JS in some occasions) do this. An e-mail can contain all of it and today’s clients support it out of the box. HTML is relatively easy to textify for anyone with a braille terminal or CLI-preferral-syndrome. XMPP clients generally support something like this too in messages.
- “Archival publishing”, media storage and sharing
WordPress is a blog tool, there are many more too. For publishing music and video – I believe the future is bright for MediaGoblin. For replacing the networked streaming I’m not as experienced, but anything mpd to the HTML5 player in ownCloud would probably do good.
- Asynchronous forum discussions, spanning over weeks or longer.
Mailing lists are splendid for this purpose. They even support modern technologies like images and hyperlinks! Heck, even referring to previous posts, threading, CCs and BCCs! It may require a more natural “start-a-discussion-group” interface to mailman however, to attract the 99%.
- Instant messaging/”status updates” with archiving.
XMPP + related XEPs. Granted that not all clients present it exactly like you want it, but this solution would motivate further such development. Especially archive negotiation is lacking in many clients today.
- Voice and video communication
XMPP’s Jingle specification does this. And browsers soon have WebRTC + PeerConnection by default, so you who lean that way can use the Jingle plugin to Strophe.js.
- Event planning and calendar synchronization.
Afaik e-mail combined with the iCalendar format (and CalDAV for synchronization) support this to a large extent already. Work must probably be done on user interfaces to properly present “attending” user identities etc. (relate them to extended metadata).
- Propagate your personal contact information.
VCards. E-mail and XMPP have natural affinities for this. Preferrably, this information is updated and propagated through XMPP and put into e-mail attachments whenever desirable.
- Evil integration of non-federating services
There exist modules and scripts for many XMPP servers that allow the heathens who communicate over, say, Skype or Facebook Chat, to integrate these network contacts into their “local” rosters. For use with any XMPP client.
A side note for those who suffer from “not invented here 2.0″, and don’t appreciate Real Software™ as much as I do: Yes. You can build an app for that. There are HTTP accessible APIs (or we build them!). You can have it running in the cloud. It’s buzzword-compatible. It’s extensible.
Concretely, how is it done?
The combination (tying together) of these technologies implies that we would essentially devise that single, workable “protocol” – but rather than building one from scratch, we build upon existing, well-established networks. It is sort of like building a meta-package for your favorite software packaging tool: configuration files for binding authentication/access together and giving users a personal choice of software:
Stuff that may differ with world views
I believe many may react strongly to my suggestion for GPG key usage. For one it’s not user-friendly enough, so I suggest that any Commune instance to make sure any local GPG private key is accessible – and recoverable – for the administrator. I think this is ok because you’d have to trust your administrator anyway (compare it to the big F’s control over the identities of the 99% today). And if you understand this risk thoroughly, you’re probably competent enough to run your own (private) Commune instance – where you keep a new, truly private, private key.
Remember also that you can have several identities with different rosters (“friends lists”), or you might categorize users within your roster – a native part of XMPP. Say for example that you create a group (or “aspect” or “list” or “filter”) – and then allow only these to access the media catalog you shared called “Full archive of RIAA intellectual property”. Your public share – if any – would perhaps be “My local cache of web.archive.org”
So how do, say, Commune and FreedomBox differ?
FreedomBox is trying to do the meta-package-thing as a specific .deb for APT in Debian, focusing on private individuals’ security and privacy. Commune would be designed for communities (or groups or organizations or even individuals), where the 1% are given the “trust of root” and the 99% happily use a working, federated service run by someone they trust.
A lot of federated communities each running their own instance of a “Commune” would increase the possibilities of integrating (and extending) functionality for client software. But until then, you’re at least not on a separate federated network – as anyone you’d communicate with by e-mail or IM are already using the protocols!
No, I haven’t put all of this together. There’s no Commune Demo Site. Sorry about that. But the idea has struck me several times while tying together my GNU Social-based Free & Social user database for postfix/dovecot for email and Prosody for XMPP. So I figured I’d type it all together at last.
Please keep discussions and commenting on the W3 fedsocweb CG mailing list in an appropriate thread. The comments on my blog (and WordPress in general) generally give a bad user experience after 3 replies or something. .)