Group: GNU Social/Ideas

From LibrePlanet
< Group:GNU Social
Revision as of 09:45, 6 May 2010 by Kxra (talk | contribs) (→‎Commodity webhosting approach)
Jump to: navigation, search

This is the development, work-in-progress spec/ideas space for GNU Social, otherwise known as Daisychain.

Functionality

A protocol and interface for decentralized social networking with Facebook-like web interfaces and native desktop applications. Integration with chat, messaging and file sharing welcome.

Goals

  • Privacy- users should be in control of their own data
  • Distributed- anyone can set up their own node or server to become part of the network
  • Portability- software should run on the widest array of hosts possible
  • Simplicity- simple to set up; a simple base installation to serve as a platform for a wide array of extensions
  • Extensibility- easy to implement and distribute new functionality
  • Scalability- the extended network should be able to scale to the same degree as the World Wide Web
  • Freedom (of course)

Feature Wishlist

  • Base system
    • Contacts + plugin API
    • Basic (removable) apps installed by default (messaging, etc.)
  • Something on par with Facebook's news feed (which has recently been patented...)?
  • Something on par with Facebook's Events application
  • Some thought could go into synchronizing several installs. All of these could be really easy if it's done right, right from the start:
    • Backups
    • Switching hosts
    • Having a local copy synchronized (both up -- posting a diary from the middle of a forest w/ no connection, appears once I connect -- and down -- finding a wi-fi hotspot and getting a week's load of updates before going off again to read them)
    • Maybe switching to different implementations of the protocol, for those that happen to dislike PHP, or there can be a proper desktop application
  • PHP for the front-end implementation language (portability; pretty much all hosting companies support it)
    • Back-end presents an issue; should be easy to install even on a third party host, if possible.
  • Average User Figures, not considering future growth

Design Choices

Architecture, Protocol and Scalability

Requirements:

  • true privacy: only my friends and me get to see what i want them to see - this requires at least end-to-end if not group encryption and should in part happen on the user's computer
  • send many events to many recipients in a shotgun fashion like a multiplayer distributed computer game
  • supports basic concepts of subscription, friendship, web of trust
  • easy addressing scheme that can be exchanged in a bar or a bus
  • encryption friendly on various levels
  • ability to share binary data with people?
  • data agnostic?

What are the candidates?

  • A P2P/DHT strategy with enhanced DHTs that support multicast subscription trees?
  • PSYC (native multicast support, binary transparent, lean)
  • XMPP (popular, verbose, no native multicast, no binary transfers)
  • various computer game protocols maybe?
  • Blaine Cook says it can even be done on top of HTTP

Questions

  • Can HTTP handle the traffic of a continous stream of social network events?
  • Can we do multicast on top of HTTP or how are we going to do one-to-many distribution without hitting our nose bleeding?
  • Can multicast subscription protocols be attached to nodes of a DHT infrastructure?
  • How good is PHP at UDP, TCP, HTTP. Can it communicate with a DHT? Can it handle pending subscriptions?
  • What are the advantages of using XMPP?
  • What are the advantages of using PSYC?

Architectures and Related Projects

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

Issues specific to this architecture

Open Profile / Browser Certificates approach

Pros

  • The browser can authenticate with a decentralized choice of web servers using a certificate.
  • Certain amount of encryption operations can take place in a regular web browser.

Cons

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

Projects

  • Open Profiles proposal using x287
  • FOAF
    • FOAF provides web scale profile system that is arbitrarily extensible
    • "I express my network in a FOAF file, and that is a start of the revolution." -- Tim Berners-Lee
  • FOAF+SSL for RESTful p2p authentication - libraries in php, java, perl, python, and Apache module available.

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

  • XMPP
    • "Message oriented middleware" -- should be useful for inter-server communication
    • Need to include an XMPP server in base install?
      • Is it possible to route what we need through an arbitrary XMPP server?
        • You can route whatever you want through the XMPP network, as long it is not binary data.
    • OneSocialWeb is a social network initiative on top of XMPP.
    • Google Wave
    • https://rhizomatik.net/mycelia
  • PSYC for push messaging and portability
    • native one-to-many distribution by multicast trees on top of TCP (or UDP when sufficient)
    • you can come up with your own protocol extensions and deliver binary data with it
    • some social network functions already built-in
    • dyne folks have one running http://hinezumi.im
    • rooms can be scripted to route messages also to JSON (web)
    • multicast encryption scheme (automated shared secrets among groups of people, respectful of optimal routing)

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

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

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
Retrieved from "https://libreplanet.org/wiki?title=Group:GNU_Social/Ideas&oldid=16114"