On Sat, 2016-11-05 at 16:51 +0100, carlo von lynX wrote: > On Sat, Nov 05, 2016 at 01:02:30PM +0100, Martin Schanzenbach wrote: > > > > Hmm can you explain why you think that? I think what he tried to > > say is > > that basically GNS delegations are not needed in the secushare > > design > > as rendezvous/places are used for introductions leading to <x>.gnu > > names anyway. alice.bob.gnu is not a valid use-case then. > > After introduction you would end up with myalice.gnu anyway. As > > such > > translating k.zkey back to alice.bob.gnu is not reasonable either > > because it would directly translate to myalice.gnu. > > In fact, being able to link alice.bob.gnu across multiple paths (in > > the > > social graph) might be unwanted and lead to deanonymization. > > Yes, GNS was designed without secushare in mind.. but that is not > a problem. If you like alice.bob.gnu we have local db info to serve > up the reverse mapping. No need to trade any privacy. Grandpa end- > users we'll probably not be using this syntax anyhow, but we can > still support it.
Okay got. But then you don't need GNS. As in: at all. You just need a DB with name/key mappings. Any IM messenger today has that. You don't need a more sophisticated DHT-based decentralized name system. Our discussion hence is pointless and we should end it here. The reverse resolution was targeted at GNS, not secushare. > > > > > I think I know where it is going. But I do not find it particularly > > practical. > > I'd like to find the words to say this in a nice way, but I think > you haven't digged deep enough into the subject to know where this > is going. And it's no disgrace, most people haven't. Please don't > feel > offended by my harsh way of writing things and try to look into the > documents and the new video from Datenspuren at secushare.org to try > and catch up with ten years of development on our side. > > > > > @lynX: Btw. in response to the other mail: the one arguing > > ideologically here is you, not me. You think that reverse lookups > > are > > not useful _in your design_ and in your _"better" world_ of > > secushare. > > You can't just redefine the semantics of "ideological" to your > liking. > You made a political statement about any computer having a right to > communicate with any other computer, no matter if there is any social > connection between the owners. You said this is what it has to be and > provided no scientific rationale for that, just a use case that can > and needs to be solved differently than you think. That's why I am > saying your choice is ideological. > > I am saying it is unsafe for GNUnet to undertake the path of wrong > sociological design choices for ideological reasons, so what you are > trying to do, sacrificing privacy for a technical practicality, is > NOT just unuseful for secushare. It is wrong for GNUnet and humanity, > should humanity one day upgrade from the broken Internet. > > There is a whole background in sociology here, and since you are not > aware of it you think it's okay to simplify and call it ideology, but > that is just as profound as saying that "P2P" is ideology and there > is no scientific reason whatsoever not to use centralized servers. > > > > > So whenever you say reverse resolution is wrong or it has no use > > case > > you always have to say "for secushare". This is what irritated me > > as > > well. > > I didn't say that because I see it as wrong. If GNUnet replicates the > mistakes of the broken Internet we might as well fry the project. > GNUnet must also be about understanding the sociological mistakes > that > were made in TCP/IP. secushare just happens to be the name of the > project that went ahead in that area. I'd like to say we no longer > need > secushare as a project because it fully merged with GNUnet, but > GNUnet > isn't ready yet, technically and intellectually. > > > > _______________________________________________ > GNUnet-developers mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers
signature.asc
Description: This is a digitally signed message part
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
