Re: Federating by Commune design idea

Mikael Nordfeldth

great listing of features. I will finish the thoughts on a new thread.




On Fri, Jun 14, 2013 at 12:21 PM, Appelquist Daniel (UK) <
Daniel.Appelquist@telefonica.com> wrote:

> Hi Mikael -
>
> Great post - I'm wondering if you've had a chance to take a look at the
> OneSocialWeb open source project (see http://onesocialweb.org) which
> implements a plug-in to the OpenFire XMPP server to demonstrate how an
> XMPP-based federated social web could work. Project now shelved and there
> are no active nodes (that I know of) still in operation, but the code is
> still there on github and could be picked up as a staring point.
>
> Dan Appelquist
>
>
> On 12/06/2013 19:01, "Mikael Nordfeldth" <mmn@hethane.se> wrote:
>
> >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
> >
>
>