Re: Federating by Commune design idea

Hi there,

Sorry for replying so late. I wanted to go in-depth on it.

Dnia środa, 12 czerwca 2013 o 12:01:06 Mikael Nordfeldth napisał(a):
> 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 :)

+1

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

+1

> 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“.

+1, sadly.

> 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.).

+1

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

If I were a Marxist, I would say that with regard to media and information 
technologies (including social media) we are today in a similar situation that 
we were in the 19th century with regard to "means of production". They are 
(close to) necessary, (almost) everybody has to use them or face some level of 
ostracism, and yet they are almost entirely privately-owned and operated, with 
the users disenfranchised and without any control over their data, public 
image and lives.

While I do not entirely agree with Marx on many, many matters, I do believe 
that we should -- so to speak -- bring these "means of production" to the 
hands of the "producers". Users should control their own Internet presence and 
their own infrastructure as much as possible. or more.

> 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:
>
> (...)
> 
>   * 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%.

+1. I've been playing with the idea for some time. Basically, e-mail, forum 
post, blog comments, social network posts etc., all have similar data 
structure:
 - author
 - date
 - addressee (can be a group)
 - title (optional)
 - text
 - attachments (optional)
 - in-reply-to (optional)

There is no reason why it shouldn't be possible to create software that 
implements different interfaces to the same community. Some prefer forums, 
some prefer mailing lists. Let them use their favourite tool, but have a 
single discussion!

Another idea is to have "instant mailing lists". Sending e-mail to several 
people + a "nonexistant-list-name@lists.example.com" (provided there's a 
proper software set-up on example.com) could automagically create an impromptu 
mailing list with addressees automagically added. Any reply to the list with a 
new addressee in To or CC fields would add this address to the list.

There are several problems that I would need to solve before that could become 
a workable solution, but I do see a possibility of it happening.
 
> (...)
> 
> 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.

+1

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

+1

> 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."

+1

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

That's an interesting idea, and definitely a better approach than no GPG what-
so-ever. I have the same feeling about SSL -- it's better to have a self-
generated cert than no cert at all. At least you get random sniffers out (and 
then some).

> 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”.

+1, very interesting.

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

These two approaches complement one another. THe best route, I believe 
(although not the fastest one) is to build .deb packages with software 
configured to work as a Commune.

Or, VM images. Why not use VM images. That could be the quick and dirty for 
now.

> 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!

+1.

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

If you're interested in doing this, my Foundation will be happy to provide a 
publicly-accessible VM instance for you to play on, along with a mailing list.

I would help from time to time (depending on the current workload in other 
areas of my work). This is a serious offer.

-- 
Pozdrawiam
Michał "rysiek" Woźniak

Fundacja Wolnego i Otwartego Oprogramowania