Re: [Social-discuss] What I think GNU Social's structure should be

[Carlo von Loesch]

Ted Smith typeth:
|       * 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.

FULL ACK.

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

Fine with me.

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

Yes.

| 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,

... until some killer use of the application is tied to having a
real client app on a personal computing device. Or maybe because we
the developers make a political statement pro true privacy, which
means using encryption on the personal computing device, not a server
out there.

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

Like 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].

Interesting. I wouldn't want to end up on web hooks as lowest
common denominator all the time, either - or even settle for them
from the start.

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

That isn't centralized, it's just not distributed.

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

Hmm.. reminds me of a planned feature in PSYC.. GNUnet seems to be some
steps ahead in this field.

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

Not sure if you mean what I mean here, so I say what I mean. Groups
of people need a managing member that generates a symmetric encryption
key and sends it to each member, using each member's public keys just
once. Once a secret symmetric key is established, messages can be
distributed using regular multicast strategies as all members can
decrypt that. Only this spells true privacy within groups of people
and thus the social network.

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

D'accord.

| 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

I do not disagree at all.
I'm glad to hear a voice of wisdom.

-- 
___ psyc://psyced.org/~lynX ___ irc://psyced.org/welcome ___
___ xmpp:address@hidden ____ https://psyced.org/PSYC/ _____