Federating by Commune design idea

Hello, I have written together an idea or proposal regarding how I
believe federated communities may be successfully formed (and
interoperable) with existing technology and protocols:

   http://blog.mmn-o.se/2013/06/12/federating-by-commune-design/

I know this is a list for the World Wide Web, but I firmly believe the
internet as a whole - and a successful "federated social web" -
reasonably consists of more than the HTTP protocol :)

I'm copy-pasting my entire blog post as-is below (without fancy
formatting or hyperlinking). Updates will be made on the blog but I
prefer it if discussion is kept here (or other appropriate discussion
places):

Federating by Commune design
============================
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 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 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.

    "That new supercool web-only feature you want? Well, The Simpsons
already did it. And e-mail too."

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 writing one from scratch, we build upon existing, well-established
networks. It is sort of 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:

    "Swift, Empathy or irssi+bitlbee for IM/MUC? How about Roundcube for
your webmail, with a Candy XMPP chat plugin? Otherwise there’s
Thunderbird as a hefty all-in-one."

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 “Full archive of RIAA intellectual
property”.

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!

Post scriptum
-------------
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.

Thanks for reading. Please discuss.

-- 
Mikael Nordfeldth
http://blog.mmn-o.se/
Xmpp/mail: mmn@hethane.se