Re: Federating by Commune design idea

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
>

Received on Friday, 14 June 2013 16:22:43 UTC