gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Reverse resolution of VPN/GNS


From: carlo von lynX
Subject: Re: [GNUnet-developers] Reverse resolution of VPN/GNS
Date: Sat, 5 Nov 2016 00:53:00 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, Nov 04, 2016 at 11:20:45PM +0100, Martin Schanzenbach wrote:
> I see now that the public part does not fit into social/psyc. But I do

No, no. It is no problem to do public applications using pubsub,
but I see no constructive use case for your technological idea.

> not fully agree with your social theory. Even if I did the reverse
> resolution of PKEYs is just logical. If I can use GNS to resolve

No it is not logical. It is in the tradition of the old Internet,
reconstructing structures that made us make a new Internet
in the first place.

> alice.bob.gnu to X then surely GNS should be able to map X to
> alice.bob.gnu. Imagine receiving a message from X.zkey and the
> application cannot map this to a previous conversation from alice. 

If Alice is in Bob's pubsub, then secushare can provide you with
that information.

> I think the common case for services is that I want them to be used by
> _anyone_. No exceptions. I know spam is a pain, but unsolicited

This is an ideological statement, not a use case, and it is
reiterating old mistakes done by the designers of the old Internet.

> messages from a person not (yet) in my social graph are not always

There are two kinds of communications on the Internet. Those from
people, and those from bots, spammers, phishers, spies and other
nasty cyberweaponry. People will always somehow be in your social
graph. Maybe not on your computer yet, but if they are trying to
talk to you, then they probably went to your website, read your
research paper and now ask to be able to interact with you. That
we gladly do with a proper rendez-vous protocol. But the "no
exceptions" thing you are talking about, like any spambot being
able to connect my SMTP port just by knowing my pubkey.. well,
that I think is a very bad idea.

Did you actually read the pages I linked? Did you actually watch
our presentation? Because you sound like you didn't and I have to
repeat things that were written years before. Consider that we
started thinking about social over pubsubs in 2003.

> spam. And maybe they do not want to join my social graph at all (how is
> a discussion between opposing parties supposed to be initiated? They
> need to become acquainted? By that logic you must "friend" anyone

Being in the social graph is not limited to being friends.
Any discussion between people first requires that some people
are guaranteeing that both sides are actually human, or
otherwise we'll have influencer bots controlling public
opinion on gnunet just as they are doing it on Twitter and 
Facebook.

> anyway, eventually). I do still want to know _who_ that is, though.

That's why not every contact is a friend. We're not Facebook.
Our sociologist does not go by the surname Zuckerberg.

> Maybe I have an (indirect) relationship. And for that I need to give
> his identity a readable name. To do that I need a reverse resolution of
> the identity information (PKEY). I cannot depend on my direct
> relationships for that and I do not want to.

But why should such a person get access to your VPN services?
First make some degree of contact, use a proper protocol for
that, then a .gnu can be automatically allocated. Nobody wants
to see a domain name for that anyway- social user interfaces
show names, not domains.

> Assuming the other option (social only, direct relationships or
> nothing) is the default it will inevitably create social bubbles that
> are even harder to break out from than it is today (case in point: news
> websites people read). 
> I have no hard evidence here, but I fear such a system will kill
> critical discourse as you just surround yourself with similar thinking
> peers, limit access to your services and are locked out from others.
> Sounds like a great way to implement digital "safe spaces".

On the contrary, only if there is a guarantee that the voices
you read are real humans there can be a discourse in the first
place, and only if those people are not anonymous but instead
need to be careful about their reputation in order to not lose
real-life friends, then they cannot engage in racism and homo-
phobia without paying a social price. This is exactly the pre-
condition for a reasonable and educated political discourse
for the reasons elaborated in http://my.pages.de/convivenza.
See also http://secushare.cheettyiapsyciew.onion/society

> > Are you telling me the local ego has no way to enumerate
> > their own GNS zone to find that person's pubkey?

I assume the answer is, yes the ego can.

> > Either we already know, or they do a proper introduction. It's like
> > ringing the door bell before coming into my kitchen.

Did you actually read this part? Because you answered
as if I hadn't said this.

> > In secushare I have pubsubs of all my social contacts. Each pubsub

"All my social contacts" - where did it say friends?

> > has a psycstore database. Depending on how much they like me and
> > into which social groups they add me, I receive pubkeys of people
> > they are connected to that I should be able to reach out to. See
> > last month's secushare video for details on this (in German). So
> > I already have my gnunet/secushare social graph in the psycstore
> > database and just need to SELECT over it. No need to consult any
> > DHT, let alone have it be public.
> > 
> > More on this in...
> >     http://secushare.cheettyiapsyciew.onion/rendezvous
> >     http://secushare.cheettyiapsyciew.onion/identity
> >     http://secushare.cheettyiapsyciew.onion/security
> >     http://about.psyc.eu/social_graph

These are the links you should have read before replying.


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]