Group:GNU Social/Project Comparison

Group:GNU Social Project Comparison

In "The Cloud"

Commodity webhosting approach

Pros

• Deployable on commodity PHP webhosting.

Cons

• Commodity webhosting happens on virtual machine farms. Encryption, security and privacy are not safe on virtual machines.
• A federation of such PHP-based servers cannot handle as much traffic as applications using optimized protocols rather than HTTP.

Projects

Commodity hosted services	Code maturity	Distributed protocols used	Features	Privacy support
StatusNet	Production	OStatus, OpenID	Microblogging	None
Crabgrass	Production	None	Social networking with a focus on collaboration within and between groups. Wikis, task lists, asset management, photo galleries, decision making. AGPL, Ruby on Rails. Primary emphasis is on privacy.	Seems OK
Diaspora	Starting	(OAuth, OpenID, ActivityStreams planned)	Planned	Planned
Elgg	Production	FOAF, Activty Streams, Pubsubhubub, REST API, Global Identifiers, RDFa	Profiles, microblogging, streams, groups, plugins	Excellent
Pinax	Production	OpenID	Wiki, groups, forums, bookmarks	Seems basic
Open Atrium	Production	Planned?	Blog, calendar, group collaboration, docs, case tracking	Seems basic
SMOB	Production	FOAF	Microblogging	None
BuddyPress	Production	None	Members, groups, blogs, forums	None
Daisychain	Proof of concept	Proof of concept	Proof of concept
Partuza (Apache Shindig)	Proof of concept	OpenSocial	Profile
The Appleseed Project	Development halted	Planned	Profiles, photos with tagging
Knowee	Alpha	OpenID, FOAF	Address book
Dutch	Alpha	OpenID	Group blogging
DiSo	In development	ActivityStreams
Safebook	Brainstorming
Lorea	Brainstorming
SIOC	Brainstorming
HelloWorld	Brainstorming	OpenID

Suggested protocols: MINE Project, NoseRub, OpenSocial for apps

Non-free software

• iSocial: supports OpenID, OAuth, OpenSocial, etc.

Federation of Servers approach

Pros

• Existing infrastructure of servers. Familiar traditional Internet architecture.

Cons

• Still putting a certain degree of trust into servers, but we don't want unencrypted trust networks stored on servers, and can we trust SSL keys to be safe on servers in future?
• Even if we only let them see encrypted messages, we would still trust our servers to carry our social graph.

A way to solve this dilemma is to allow for more servers to run on the user's computer – then it is fine if the server is involved in group encryption maths, storage of the web of trust and personal data of our friends or even private key encryption on the user's behalf. Essentially bringing XMPP and PSYC into a more P2P mode of operation. This works with PSYC – for XMPP it may need some tweaking.

Projects

Federated services	Code maturity	Distributed protocols supported	Features	Privacy support
XMPP	Production	XMPP	Instant messaging, supports extensions	Excellent
OneSocialWeb	Beta	XMPP	Microblogging, profiles	Seems great
Google Wave	Beta	XMPP	Messaging, microblogging, instant messaging	Seems great
Mycelia	Development	XMPP	Wiki, bookmarks
PSYC	Production	PSYC, XMPP, HTTP, IRC, some FOAF	Conferencing, messaging, microblogging, profiles, trust metrics	Yes

On Your Computer

Peer-to-peer (P2P) / Distributed Hashtable (DHT) approach

Pros

• No doubt peer-to-peer is the approach that respects privacy the best, as it allows any social interaction to be end-to-end or group encrypted. Some technologies even make it hard to observe who is communicating with whom.

Cons

• Needs a special strategy for message delivery when a source goes offline (servers, DHT and/or group communication redundancy)

Projects

P2P services	Code maturity	Distributed protocols supported	Features
GNUnet	Production	GAP	Filesharing, Chat
I2P	Production	I2P	Pseudonymous Publication, IRC, Filesharing
Tahoe LAFS	Production	None	Filesharing
CSpace	Production	Invented	IM
Angelapp	Beta	None	Filesharing
RetroShare	Beta	Invented	Filesharing, chat, forums
The Circle	Ceased development	Invented	IM, IRC
Syndie	Alpha	None	Forums
Netsukuku	Not in production	Netsukuku protocol suite	Wifi mesh network

Non-free P2P networks

P2P services	Code maturity	Features
LifeSocial	Proof of concept	Profiles, photos, etc.
Opera Unite	Production	Photos, wall, music and filesharing. Capability for groups or global news pages is quite limited

Social desktop applications

Pros

• allows for end-to-end encryption for people and groups, without browser
• heavy integration in the computer desktop experience
• allows for much richer interactions beyond traditional social networks (like file sharing)

Cons

• could be done in an unsafe client/server way, so be careful to get it right! Get it right probably means to do it in a P2P way (see section above)

Projects

P2P services	Code maturity	Features
Nepomuk for KDE	Beta?	Metadata sharing
Social Desktop for KDE	Beta?	Authentication to issue tracking services, KDE forums, news feed

In-browser profile + certificates approach

Pros

• Authenticate at any website using a secure profile stored in the browser.
• Profile is always stored locally; external websites can't fake it.

Cons

• Adds a layer of complexity without solving the problem, since creating a forum/microblogging still requires some kind of hosting.
• You need to surf to web sites to pick up profiles and information waiting for you, there is no real-time notification stream.
• You cannot do group encryption.

Protocols

• FOAF+SSL for RESTful p2p authentication - libraries in php, java, perl, python, and Apache module available.

Projects

• No browsers implement FOAF+SSL so no projects have been initiated

Distributed Node Architecture

This architecture entails separating an end-user's GNU Social node into five components. See here for more. This essentially brings all of the approaches (and thus existing solutions) mentioned above into a big picture and defines a framework for them to interact.

Pros

• Allows end-to-end encryption for people and groups and anything else
• Allows the use of arbitrarily many transport protocols such as HTTP, XMPP, or PSYC for relaying data between nodes
• "Future proofs" by defining protocols between components and not making assumption about the structure of other aspects of the node
• Allows users to access the same account using different client programs (web browser, dedicated app, MeMenu, etc.)

Cons

• Possibility of over-design

Projects

• Teddks' brainstorm