Hi, Thanks for the input. I think you need to elaborate more on this for me though.
First you say: On Fri, 2016-11-04 at 17:58 +0100, carlo von lynX wrote: > This summer I reported https://gnunet.org/bugs/view.php?id=4625 > > > > > For many kinds of applications we need to authenticate incoming > > connections as coming from a certain person or at least from a > > certain peer. The exit daemon is currently not providing a way to > > find out who is calling. Resolving the virtual IP number would be > > the most backward compatible method. Best if it resolves to the > > same "hostname" as the matching outgoing <nickname>.gnu, or even > > uses the same virtual IP as an outgoing VPN tunnel would use. > Yes, this is what reverse resolution is for. The only thing you can know about the "caller" is his peerid/identity, at best. Now, the question is how you find a path from _your_ identities to that peer. The other way around not necessarily useful. > Apparently this has sparked an exciting philosophical debate on > social graph reverse resolution: https://gnunet.org/gns-reverse-ideas > > I would please ask you to come down from your ivory towers for the > following reasons: > > 1. Such a reverse resolution method *would* be a local operation > if gnunet-social and gnunet-psycstore were actually functional > and all the appropriate subscriptions in place. > In other words: You are re-inventing secushare. > So you fixed the issue in the bug in theory? Can you elaborate how? I don't understand... > 2. In that blog post you are discussing a "public" social graph > like PGP's. That is a not exactly futuristic idea and very > much inferior privacy-wise to the private social graph planned > by secushare. Well, reverse resolution by design is public. This is particularly useful for trust establishment scenarios. I.e. I have a webservice and identity X just logged-in -> reverse resolution to determine if I have a trust relationship to this person. I don't really care about _his_ trust relationship to me here. > > 3. To make GNS work with existing applications I simply asked to > teach gnunet-exit to return the same names that were used by > gnunet-vpn to build those tunnels in the first place. The rest > of the challenge is then dealt by secushare's pubsub structures. > This does not make sense or you need to explain it to me better. What use would it be to tell exit how the tunnel was built? Such (trust)paths (btw I do not agree here that the peers along the tunnel are in any way related to a social graph or GNS...) are usually not symmetric or bi-directional. There is no guarantee that this trust path is actually useful to the callee. > So all we need to move forward is: > > 1. The closing of that feature request by implementing just the > resolution of *known* addresses, in a simple and fast way. Define "known". A direct trust path? This is also included in the proposal btw. > 2. Fixing the bugs in gnunet-social or anything below so that we > can avoid having to use older software just because it works. > I have only read the thesis on social to be honest. But by that knowledge it do not see how it can solve the reverse resolution issue. BR Martin > Thanks a lot for the recent fixes in CADET, Bart. Haven't tried > out if they magically get everything working again, yet, but I am > hopeful. Who knows, maybe gnunet-social starts working. > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
