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

[Ted Smith]

On Sun, 2010-03-28 at 18:35 -0400, Sean Corbett wrote:
> > 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 is generally the layout I've had in my head since I started
> thinking about how GNU Social would be implemented; definitely agree
> that this is the best course of action.
> 
> >  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
> >
> I'm confident this scheme would be functional, however the possibility
> that someone's data just isn't available everywhere would still exist.
> If one of my friends posts a link and some commentary, and a few hours
> later one of my coworkers tells me to check it out, and it turns out
> that data isn't available to me because I wasn't online while it was
> cached somewhere, I'd be ticked. Or would this not happen?
> 
If your co-worker checked it out, it would be cached on their node,
unless they had disabled that. In the general case, if everyone enables
some caching, it won't happen, which gives everyone an incentive to
enable caching :-)

> Also, why is push delivery better than pull? (The following probably
> stems from some misunderstanding) If I have a few hundred friends spread
> across a hundred cores in the network, and there's also a lot of people
> using this core, wouldn't the server running my core get bogged down?
> Wouldn't it just be more efficient to serve that data on a per request
> basis, and cache it at a remote server once this happens? So, if one of
> my friends on a remote node in the example above requests my data, and
> another on the same node requests it, that server can deal with the
> second request directly (provided other updates haven't happened in the
> meantime).
> 
I'm not trying to say that push is better than pull; I think my
structure works with both models. I think that's outside of this
particular discussion (since it is part of the design of the high-level
GNU Social protocol).

signature.asc
Description: This is a digitally signed message part