Tag Archives: federated social web

Utveckling av “fedsocweb” både stagnerar och frodas

Jag har som bekant ett projekt aktivt med stöd från Internetfonden. Målet är att förbättra den existerande mjukvaran StatusNet, en fri mjukvara för federerade sociala nätverk – eller “federated social web” (fedsocweb). Källkoden jag publicerar går självklart att läsa och projektets resultat går förstås även att använda.

Tillgängliga, liknande mjukvaror

Mycket har hänt sedan jag påbörjade projektet, i detta inlägg ska jag fokusera kring de alternativa mjukvaror som finns inom fedsocweb.

Min utgångspunkt har varit StatusNet, som i mina ögon har en väldigt stor kodbas (228k rader faktiskt kod) som helt enkelt inte är särskilt smidig att uppdatera och bygga vidare på. Det är tydligt att mycket kod hänger kvar “från förr” och orsakar en del kompatibilitetsproblem och huvudvärk när man försöker skapa ny funktionalitet – och inte minst när man försöker standardisera och effektivisera koden.

Sedan november förra året, då jag tog mina första stapplande steg i kodstrukturen för detta stora projekt så har jag försökt bidra med buggfixar och har fått en del av dessa beviljade. Många fler har inte antagits, mestadels eftersom StatusNets huvudutvecklare arbetar på ett annat projekt, Pump.io. Detta nya projekt bygger även det på s.k. “ActivityStreams” och ska implementera OStatus fullt ut, fast i en mindre tungrodd infrastruktur på serversidan. I ett försök att “göra om göra rätt” kanske, men jag har inte hakat på det just det spåret.

Denna stagnation i utvecklingskraft på sociala federerade nätverk är inte unikt för StatusNet. Diaspora* verkar ha fått slut på sitt kapital och riktar in sig på en mer tumblr-remix-aktig satsning än Diaspora-projektets ursprungliga “Facebookdödande” inriktning. Deras nya projekt är helt enkelt nischat för specifika typer av användare och Diaspora* lämnades över “till communityn” i ett mycket ofärdigt skick, om än behändigare kodstruktur än exempelvis StatusNet.

Dessa två plattformer, StatusNet och Diaspora*, har varit de största att dominera sfären av federerad social media. En hittills mer lågmäld spelare har varit Friendica som har varit mer av en satsning på att binda samman separata nätverk för privat bruk än att fungera som en federerad plattform i sig. Sedan StatusNets utveckling stagnerade strax efter sommaren 2011 verkar mycket intresse från bidragande utvecklare ha gått över till Friendica istället. Tyvärr har Friendica en ännu större kodbas än StatusNet (>500k rader kod, mer än dubbelt så stor).

Mycket kod gör projekt jobbiga att sätta sig in i, underhålla och utveckla. Vilket är tre oerhört viktiga egenskaper att bibehålla för projekt med fri mjukvara. Ju högre tröskel in i utvecklingen, desto färre kommer att hjälpa till. Fokus borde alltså ligga på att underhålla lätta, smidiga kodbaser som gör vad de ska på ett enkelt sätt. Mitt mål har därför varit att kapa och meka i StatusNet för att underlätta underhåll. Ett direkt resultat i början var det enkla måttet på antal rader kod men sedan dess även utbyggbarhet och standardisering.

Att mäta resultaten

Jag passade på att nyttja kod-och-projekt-analysatorn på Ohloh för Free & Social, vilket inkluderar all historik från StatusNet (som också finns där). Det syns tydligt när jag började skära som hårdast, i månadsskiftet juni-juli 2012, där 70,000 rader så gott som onödig kod togs bort. Sedan dess har utveckling skett för att separera utseende från funktion, vilket i det stora hela inte lagt till särskilt mycket kod alls. Strax är jag dessutom redo att radera väldigt mycket kod som för tillfället endast ligger kvar som “fallback” om min kod inte täcker upp ett visst användningsområde.

Målet är att kunna byta ut den kod som är skriven i PHP mot något helt valfritt, modul för modul. Det ska bli lättare att köra sin egen StatusNet-instans, eller vilken mjukvara man vill, för att kommunicera federerat med OStatus-protokollet (och även andra förstås).

Det jag inte gjort hittills är att paketera Free & Social-forken för enklare installation på slumpmässiga datorer. Detta kommer när man inte längre behöver paketera hela frontend-motorn med allt vad det innebär för människor som t.ex. vill ha en installation man endast interagerar med via API och tredjepartsklienter.

Projektet tar absolut mer tid än jag hade förväntat mig. Fast då resulterar det även i en mycket större förbättring än vad jag först hade tänkt mig.

Conversations in “social” media (and why OStatus rocks)

So, what’s more social than having a conversation? Two or more participants in an exchange of words or acts that relate to a common subject. It’s called communication and as human beings we have a natural born talent for maintaining several subjects in our mind at once.

The conversation is very important for humans and our social life. We not only want to interact with others – we want to understand the context of a conversation we’re not immediatly being a part of. Be it a political debate, people on the street passing by or when reading posts on an internet forum. Quotations are a great example of how maintaining the intended context is important, as many phrases have multiple interpretations. With the age of books, physically printed literature, keeping the context has been a hard task – but with computers, the internet and hypertext on the world wide web it is no longer difficult.

So one may wonder why websites that are portrayed as “social” are so bad at presenting communication. Lately we have started seeing one-level threads that contain comments and mentions in the “social media”. Not much more than bulletin board systems did during the ’70s and ’80s. The visual representations, event the metadata, of these digitally stored conversations are limited to relatively short bursts of chaotic chatter in the realtime-adapted webservices. Not a very socially sustainable style of communication.

The two major players in the area of asocial media services in Europe and the US are Facebook and Twitter. Both fail to respect human conversation in their own particular way:

  • Facebook has a single-thread style conversation. A user initiates this with a post or link. This notation may be quite long and occasionally sparks an intense debate. However, any replies that are made are only linked to the original post.
    Should a thread get multiple conversation participants that reply on several invisible subthreads it doesn’t take long before it is too chaotic to follow. Even for a trained robot or human being.
  • Twitter conversations are built on reply-to notifications. An original tweet, limited to 140 characters, can often gain attention and be subject to discussions. Any replies to this post will be required to contain a multi-character mention (@username) of the user replying to, while still being subject to a character limit.
    Assuming, contrary to experience, that a 140 char-limit is enough the available characters are quickly reduced with conversation participant, effectively disorienting any third-party that tries to follow up.
    To make matters worse there’s not even a method of linking tweet follow-ups in metadata, which has caused some clients to add any “>>”-like signature to indicate humans to continue reading in the next tweet.

Compare it to mailing lists. Any mailing list or e-mail client can handle threads, replies, carbon-copies and even blind carbon copies since decades ago. That’s like space-age technology compared to the asocial media services’ scrapbooking kit which even lacks a proper glue.

Google+ also uses the single-thread style. There are of course also many other services out there, even some of which have learned from (or even incorporate) mailing lists. Usenet for example should reasonably be an early example of an open social media, lacking only a flashy front-end, a marketing department and better anti-spam measures to be successful.

WordPress is probably the best example of a social web media and sports appealing multi-threaded comments with proper computer-readable markup. However, WordPress currently lacks integrated federation. It’s more of a social oasis, where you park your camel and talk for a while before you head off to the next water hole. Besides, that structure is better used for the topic of a discussion rather than the place of a discussion.

So welcome OStatus, the federated social web protocol. Its main implementation, the software StatusNet (see it in action on identi.ca or freesocial.org), already does threading and proper in-context metadata. It has the backbone for cross-domain notifications and replying without clogging the post with the @-mentions. As opposed to WordPress, the social bit is integrated both up- and downstream so feeds you subscribe to get pushed into your timeline and from there you can post comments upstream and interact with replies.

The OStatus protocol is open and free for anyone to use, works across domain-names and gives you control over what you share, how your data flows and especially where it is stored. You’d never give up control of your “real” social life to someone else – so why give up the digital representation of it? OStatus is an easy solution to maintaining this control.

So if one wants a true social media service, I think it is important to choose one that is not only open and free as in speech but also compatible with how humans really interact with each others. A system that not only respects the user by keeping the user in control, but also something that understands our social interactions – where conversations are a very important part.

The social web is nothing but communication anyway, so why not make sense out of it and keep its context open, transparent and clear?

An e-mail to Google about enabling Webfinger

RCPT: info@google.com
FROM: mmn@hethane.se

Hello,
I’m mailing this social web feature request to the info@ address as it should reach some authoritative person at Google. At least according to some SMTP RFC I once read.

I’m a big fan of the federated social web and would very much like to see the Webfinger discovery protocol implemented on the gmail.com domain, mainly in order to find your users’ OpenID providers in a standardized way. (i.e. /.well-known/host-meta -> xrd lookup -> user data including OpenID server).

It would definitely help boost OpenID usage as a lot of people have a Gmail address – which is much easier to remember and type than the Google account OpenID provider url. It would also enable a federated web friendly version of the various “Connect” login options that the major asocial web service companies offer.

Update:

<info@google.com>: host aspmx.l.google.com[173.194.71.26] said: 550-5.7.1 The
user or domain that you are sending to (or from) has a policy that
550-5.7.1 prohibited the mail that you sent. Please contact your domain
550-5.7.1 administrator for further details. For more information, please
visit 550 5.7.1 http://support.google.com/a/bin/answer.py?answer=172179
ig6si37627458lab.30 (in reply to end of DATA command)