2010/3/28 Ted Smith
<address@hidden>
In all these discussions about what the optimal structure of GNU Social
would be, my foremost care has been freedom. I don't yet know what a
fully free network service would look like, but I think that it would
have to have the following properties:
* Based on only free software (obviously)
* Federated, so that any user can run their own node if they wish
* NOT requiring or encouraging software as a service, or SaaS.
* Users totally control who can see their data.
Agree, tho I've got nothing specifically against SaaS, AGPL should solve most issues, from what I understand.
Ive added some comments to the previous topic, and as stated, I think the transport layer is not something that I have a strong opinion on, but I do think the power and scalability of HTTP(S), is often underestimated. So I think that would be a good one to look at, perhaps in conjunction with the other suggestions .
I think that the best design structure is one such that there is a core,
which handles interactions between nodes, and a user interface, which
communicates with the core over a defined protocol. This is inspired by
the structure of the Deluge BitTorrent client[1], and the GNUnet
system[2].
This optimizes for ease of installation and running a node on commodity
personal computing hardware - to set up a fully operational GNU Social
system, you should only need to install the core, and whatever user
interface you choose. This maximizes the user's freedom and
privacy/security, because they control the system their free software is
running on.
This doesn't significantly change the user experience for the majority
of users, which will (sadly) not care about the SaaS problem and use a
hosted solution for GNU Social. They will use a browser-based UI,
written as a web application, which will communicate with that instances
core. However, these users could transition to being autonomous peers by
installing two programs and transferring their account (which should be
a feature of the system from the start).
I think it's important to have an encapsulated, high-level protocol for
GNU Social, that is agnostic of data transmitted and how any given peer
sends or receives data. It's fine to implement sending text over HTTP or
video over BitTorrent, but the core shouldn't care about that -
transport modules or communication modules should. This allows us to be
more future-proof, and reduce the possibility of censorship. With a
modular transport system, the core does not send or receive anything,
but instead calls out to transport modules that send data to a peer in
whatever manner that peer specifies. If two peers cannot directly
communicate with one another (I only speak DNS, you only speak ICMP),
they should be able to route through an arbitrary number of third
parties until they are able to communicate. This is inspired by GNUnet's
transport architecture[3].
Running a node on personal computing hardware introduces the problem of
how to receive data when a node is offline. There are two ways to solve
this that I can see right now: the centralized way and the decentralized
way.
The centralized way is to have a persistent service running on $1 web
hosting that functions as a caching proxy for the PC-based node. The
node will advertise that proxy as its address, the proxy will send
requests for data to that node, and will cache the response. If other
nodes send data to the offline node, the proxy will cache those and send
them when its node gets back online.
The decentralized way is to presume that user's friends in the social
network will have recently requested and cached their friend's data on
their node. If a request to a given node fails, the request should be
forwarded to that nodes friends. Likewise, we should assume that friends
will be willing to deliver messages when their friends' nodes come back
online. This is inspired by "active migration" in GNUnet and the same
property of the Freenet network[4].
If we are caching our data on other nodes, we want to make sure that our
data is safe. I think the best way to do this is to create "groups" of
other users, and encrypt content we only want them to see to their GNU
Social public keys. For instance, let's say we want a status update to
only be visible to a certain group. That status update will be
transmitted as ciphertext and decrypted in the UI of the group members
who view it. That ciphertext can be cached anywhere without a loss of
privacy.
I don't care what language any of this is implemented in. In fact, no
individual component cares about what language any other component is
implemented in, either. The PHP UI will work just as well with the C
core as it will with the Erlang core as it will with the PHP core. If we
define the interfaces well enough, the core won't even care about what
language the transport modules (or daemons, now) are implemented in. My
concern is not about language or framework, but about the protocols used
to make the network itself run - not even which protocols are used for
actual social networking.
This design encourages the network to be secure, censorship-resistant,
privacy-enhancing, format-agnostic, and transport-agnostic. I think it's
the best way for GNU Social to go. That said, people obviously disagree
with me, and I'm sure they have very good reasons. I would be delighted
to hear them. :-)
- Ted Smith
[1] http://deluge-torrent.org
[2] https://gnunet.org
[3] http://gnunet.org/download/transport.ps
[4] http://freenetproject.org/index.html