Group: GNU Social/Project Comparison
From LibrePlanet
| Line 98: | Line 98: | ||
|} | |} | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=== Federation of Servers approach === | === Federation of Servers approach === | ||
| Line 215: | Line 201: | ||
====Non-free P2P networks==== | ====Non-free P2P networks==== | ||
| − | + | {| border="1" | |
| − | + | ! P2P services | |
| + | ! Code maturity | ||
| + | ! Features | ||
| + | |- | ||
| + | | [http://lifesocial.org LifeSocial] | ||
| + | | Proof of concept | ||
| + | | Profiles, photos, etc. | ||
| + | |- | ||
| + | | [http://unite.opera.com/ Opera Unite] | ||
| + | | '''Production''' | ||
| + | | Photos, wall, music and filesharing | ||
| + | |} | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | * [http://esw.w3.org/topic/foaf%2Bssl FOAF+SSL] for RESTful p2p authentication - libraries in php, java, perl, python, and Apache module available. | ||
| + | |||
=== Social desktop applications === | === Social desktop applications === | ||
| Line 229: | Line 240: | ||
Projects | Projects | ||
| − | + | * [http://nepomuk.kde.org/ Nepomuk] for KDE | |
| − | * [http://nepomuk.kde.org/ Nepomuk] | ||
* [http://www.socialdesktop.org/ Social Desktop] | * [http://www.socialdesktop.org/ Social Desktop] | ||
Revision as of 00:57, 13 May 2010
Group:GNU Social Project Comparison
Contents
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 |
|---|---|---|---|
| StatusNet | Production | OStatus, OpenID | Microblogging |
| Crabgrass | Production | Invented | Collaboration tools including task list management, meeting scheduling, asset management, wiki, and decision making |
| Diaspora | Starting | - | Planned |
| Elgg | Production | None | Profiles, microblogging, streams, groups |
| Pinax | Production | OpenID | Wiki, groups, forums, bookmarks |
| Daisychain | Proof of concept | Proof of concept | Proof of concept |
| Partuza | Proof of concept | OpenSocial | Profile |
| The Appleseed Project | Development halted | Planned | ? |
| DiSo (Apache Shindig) | In development | ? | ? |
| Knowee | Alpha | OpenID, FOAF | Address book |
| Lorea | Brainstorming | ? | ? |
| Open Atrium | Production | Planned? | Blog, calendar, group collaboration, docs, case tracking |
| SIOC | Brainstorming | ? | ? |
| SMOB | Production | FOAF | Microblogging |
| HelloWorld | Brainstorming | OpenID | ? |
| BuddyPress | Production | None | Members, groups, blogs, forums |
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 |
|---|---|---|---|
| XMPP | Production | XMPP | Instant messaging, supports extensions |
| OneSocialWeb | Beta | XMPP | Microblogging, profiles |
| Google Wave | Beta | XMPP | Messaging, microblogging, instant messaging |
| Mycelia | Development | XMPP | Wiki, bookmarks |
| PSYC | Production | XMPP, IRC | Conferencing |
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.
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 |
|---|---|---|---|
| The Circle | Ceased development | Invented | IM, IRC |
| Syndie | Alpha | None | Forums |
| CSpace | Production | Invented | IM |
| Netsukuku | Not in production | Invented | Wifi mesh network |
| GNUnet | Production | None | Filesharing |
| Tahoe LAFS | Production | None | Filesharing |
| Angelapp | Beta | None | Filesharing |
| RetroShare | Beta | Invented | Filesharing, chat, forums |
Non-free P2P networks
| P2P services | Code maturity | Features |
|---|---|---|
| LifeSocial | Proof of concept | Profiles, photos, etc. |
| Opera Unite | Production | Photos, wall, music and filesharing |
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.
- FOAF+SSL for RESTful p2p authentication - libraries in php, java, perl, python, and Apache module available.
Social desktop applications
Pros
- allows for end-to-end encryption for people and groups
- 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
- Nepomuk for KDE
- Social Desktop
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
