[messaging] distributed social graph, was: collaborative random number generation

[carlo von lynX]

On Sat, Dec 12, 2015 at 09:26:37PM -0500, Karl wrote:
> This last message gave the impression that GNS is unnecessary.  The
> only other distributed solution to sharing identities I'm aware of is
> blockchains like namecoin.  Are there others?

Yes, distributed pubsub multicasting. I mentioned psycstore as an
example implementation of this concept.

> On 12/12/15, Trevor Perrin <trevp at trevp.net> wrote:
> > OK, so we're agreed GNS leaks social graph information to anyone who
> > knows your public key and can guess a bunch of "petnames".
> 
> Knowing the public key authorizes you to know its associated social
> graph.  That's not a leak.

Yes, what we need is maintenance of a plethora of public keys and
social graphs.

> > Selectively sharing this information is a good goal.  But there's
> > nothing technically hard about it (at its simplest, Alice could just
> > send Bob an encrypted message with a list of usernames and public keys
> > - no DHTs or "query privacy" protocols needed).
> >
> > The hard part is the UI.  So it's not clear what GNS offers here.

Maintaining thousands of snippets of social graph is a real challenge.
GNS offers a reasonable means to do so in a sybil-attack-resistant DHT.
psycstore offers to distribute changes to the social graph to all
interested parties and have them stored close to the application.
Not having any strategy for this quickly turns something "not technically
hard" into a hard problem - if you care to support Facebook-like usage
numbers.

> It sounds like GNS allow this to happen without requiring Alice or a
> central server to be online or communicate with Bob in any way, if Bob
> enters Alice's social circle and wants to learn the contacts she
> shares with that circle.

While GNS *is* the database for this information at any time, psycstore
keeps just the deltas in a distributed store-and-forward backend - which
happens to also be what it needs for asynchronous message storage. Both
approaches have their strengths.

> > You can do that with global names too, of course.  Global names are
> > better because you know that Jill, Peter, Paul, and Mary are claiming
> > the same Jack, because it's the same name.  The idea that everyone can
> > have their own Jack seems confusing, rather than helpful.
> 
> I guess it seems like the public key is the global name.  The
> advantage of obvious petnames is that no introduction to the value
> "Jack.Smith.1942.Boston" or "rocksmasher9" is necessary; people can
> find each other using what they already know.

And in fact they don't care for petnames. If the pubkey is the global
identifier, the UI can just display the display name provided by the
user and even tolerate users with the same name in the same way that
Facebook does. Nicknames are irrelevant on Facebook, they just allow
techie people to deeplink their profile.

> I imagine global names are much harder when there is no centralized
> server to reserve them.  (Namecoin and Qora though)

Yes. It's a hard problem that actually does not need to be solved.
If your entire social graph agrees which public key belongs to coca
cola, why ask an external authority?

> >>> The Tor HSdir mechanism is solving a different problem - it makes it
> >>> hard to become a DHT node that will store certain entries.
> >>
> >> Something GNS already provides, AFAIU.
> >
> > I don't think so, which is why Jeff started the previous thread.

Jeff is still getting started to know GNUnet. Safety against all sorts
of sybil attack methods was the founding concern of GNUnet and it has
the most advanced strategies to deal with those. I doubt very much
that GNS allows you to take a target's DHT place.

> I suppose it's mitigated by only being able to predict the storage
> nodes of entries you have access to.

Possibly, but that would mean that folks like coca cola have a problem
protecting against DoS. I doubt Christian hasn't considered such a
scenario. Maybe it's time to wake the giant and have him have his say
on the topic.

-- 
  E-mail is public! Talk to me in private using encryption:
         http://loupsycedyglgamf.onion/LynX/
          irc://loupsycedyglgamf.onion:67/lynX
         https://psyced.org:34443/LynX/