Distributed Crabgrass

There is rapid growth in APIs geared toward social networking interoperability. This page attempts to document the major initiatives and be a place to assess and discuss their relevance to crabgrass

distributed social protocols

DSNP: Distributed Social Networking Protocol – building private, decentralized and scalable social networks
DSNP is a protocol for distributed social networking. The goal is to allow you to host your identity in a place of your choosing, maintain ultimate control over your personal information, and interact with your friends and family in a secure manner.

FOAF+SSL is a secure authentication protocol that enables the building of distributed open yet secure social networks.
FOAF+SSL uses the SSL layer built into virtually every standard Web browser. It links a Web ID to a public key, thereby permitting the owner of the private key to be identified with the Web ID. Because the Web ID is a URI, it can be linked to using LinkedData principles. This allows trust to be expressed through the position of that Web ID in the global linked data network.

social protocols

OStatus lets people on different social networks follow each other. It’s transparent to your friends, colleagues and family which software or service you use. They can get your status updates on their own sites and reply, like, or re-post your updates. OStatus isn’t a new protocol; it applies some great protocols in a natural and reasonable way to make distributed social networking possible.

  • Activity Streams encode social events in standard Atom or RSS feeds.
  • PubSubHubbub pushes those feeds in realtime to subscribers across the Web.
  • Salmon notifies people of responses to their status updates.
  • Webfinger makes it easy to find people across social sites.

Open Data Definition allows you to copy your data from one social network to another, keep track of your friends network and synchronise your data across services. Simple to use and trivial to implement, this is your fastest route to true data portability.

With the Social Graph API, developers can now utilize public connections their users have already created in other web services. It makes information about public connections between people easily available and useful.

According to the description: OpenSocial defines a common API for social applications across multiple websites. With standard JavaScript and HTML, developers can create apps that access a social network’s friends and update feeds.

Opensocial seems to differ from socialgraph by being more about creating a standard api for “gadgets” and less about sharing social data. It does share some social data, to enable these add-ons, but i think it is google’s way to compete with facebook apps. That doesn’t mean it isn’t useful, though. Opensocial in Crabgrass

message protocols

PSYC is a protocol for a messaging infrastructure for text-based conferencing, but also enabling transparent binary data. It has learned from protocols such as IRC and XMPP and found an approach that should indeed scale globally, by generalizing the multicast concept beyond chatrooms to presence awareness, news- and friendcasting. It leers at decentralized privacy-driven social networking (using trust metrics), telephony and audio/video conferencing. Chatrooms are programmable, which enables for applications such as event notification.


An open protocol to allow secure API authentication in a simple and standard method from desktop and web applications. OAuth attempts to provide a standard way for developers to offer their services via an API without forcing their users to expose their passwords. OAuth allows you to share your private resources (photos, videos, contact list, bank accounts) stored on one site with another site without having to hand out your username and password.

OpenID eliminates the need for multiple usernames across different websites, simplifying your online experience. You get to choose the OpenID Provider that best meets your needs and most importantly that you trust. At the same time, your OpenID can stay with you, no matter which Provider you move to. OpenID is an open, decentralized, free framework for user-centric digital identity.

data formats

The Friend of a Friend (FOAF) project
The Friend of a Friend (FOAF) project is creating a Web of machine-readable pages describing people, the links between them and the things they create and do; it is a contribution to the linked information system known as the Web. FOAF defines an open, decentralized technology for connecting social Web sites, and the people they describe

microformats, RSS, WebDav, CalDav, iCal
friends in feed: one person’s attempt at developing a protocol to allow you to host your identity in a place of your choosing and maintain control over your personal information, yet at the same time interact with your friends and family in a secure manner.


The purpose of this project is to put all existing data portability technologies and initiatives in context and to promote viable reference implementations (blueprints) to the developer, vendor, and end-user communities.

Diki is a peer-to-peer (or better: friend-to-friend) network for social semantic web application. Think of it as an instant messenger program for social networks like del.icio.us, bibsonomy, citeseer, facebook or studivz. Unlike those social networks, diki does not have a central server that stores your private data. The idea of diki is to create a social network that respects the users’ privacy but giving them all functionality that server-based social networks have.

DiSo (dee • soh) is an initiative to facilitate the creation of open, non-proprietary and interoperable building blocks for the decentralized social web.

NoseRub only defines the social network and some basic content types like media, links, micropublishing and text. You can now add all your contacts to a NoseRub network and aggregate several social networks into just one

dead projects

I think a lot of the above links are actually dead.

crabgrass ideas

crabgrass syndication protocol
OK, this one doesn’t really exist. The idea would be that different crabgrass installs would be able share authentication and new page syndication. It might work like this:

  • you have a user account “blue” on server we.riseup.net
  • there is another server we.revolt.org that has a group you want to join. without creating a new account, you can login to we.revolt.org using your domain qualified login blue@we.riseup.net. Authentication is handled by we.riseup.net.
  • once logged into we.revolt.org, you are just like a normal user on that system. you can join groups and create pages.
  • any pages created or marked unread for you on we.revolt.org get their basic info syndicated to your home server, we.riseup.net. these foreign pages then show up in your dashboard/inbox, but when you click on them you jump to the server where they actually exist we.revolt.org (and are pre-authenticated using the account blue@we.riseup.net).
  • no doubt, such a system would rely heavily on oauth.
  • open questions: are groups syndicated? what about public pages? can pages be cross-posted to local groups and foreign groups?


Article on options for distributed social networking

Wired Mag -- Slap in the Facebook: It’s Time for Social Networks to Open Up

OpenSocial, OpenID, and OAuth: Oh, My!
Google I/O 2008 talk about latest technologies and how they can work nicely together


Will this help out people who, like the IMC-Alternatives Project and LPIMC plan on integrating crabgrass into their IMC? If not, is there an ongoing discussion with crabgrass dev you can point me to, or can there be a page topic specifically for sharing ideas related to this specific aspect of development? The programmers from IMC-Alt and LPIMC are both interested in this aspect of collaboration and at least one of them (Josh from IMC-Alt) is very interested in joining Crabgrass dev in part to help out, but also to learn how he can help with this aspect of developing the sites we plan to create-which will be new and completely unique as far as Indymedia goes.



Some of the keys for decentralization, imho, go into semantic enabling technologies plus secure api authentication.
We should manage the “decentralization” in a platform agnostic way, i.e., abstracting even from actual crabgrass code. SPARQL (if we manage to secure who acess what) points in that direction. You create data, and then the whole web is a huge database.

Then comes the problem of how decentralized is your architecture and how it can survive dropping of some of the nodes. The Autistici/Inventati Orange Book explains their “R plan”: R for Resilience. Basically, they deploy a network of trusted servers, thinking more about things like anonimized (i.e., no trace) mail servers and taking into account the changes that one or more of the servers are raided away by security forces. I understand anonimization as a key to not to have anything to handle if you are forced (activist sites are a candy thing to prosecute and farm), but on the other side I fear how can you effectively defend against attacks if you are not keeping logs of who is using and surely some of them abusing your site.

Digging deeper into securized/distributed networks, we have things like Tahoe: a distributed, encrypted and redundant file system. Disk cuotas and encription… what about running our databases over such a protocol?

There’s a lot to be thinked about… :)