2010/3/28 Ted Smith <[email protected]> > 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 >
