5 ms·
Author here. The draft is currently in ISE review (there was not enough interest at IETF or IRTF). If you want to engage or need more info gnunet-developers@gnu
by schanzen 5y ago
Author here. The draft is currently in ISE review (there was not enough interest at IETF or IRTF).
If you want to engage or need more info gnunet-developers@gnunet.org is a good place to start and ask questions.
A lot of work has been going in over the last years to separate the protocol properly from the underlying stack (gnunet).
We are currently also working on a spec for our DHT (which is a required basis for GNS).
One of the reasons we specified GNS first is because of the order of fundings we receive(d).
happy hacking
- southerntofu 5y agoThanks for working on GNS. It's genuinely the most exciting tech project i've heard about in the past few years and i'm sure many people would like to try it out or get involved given proper communications channel. A few questions: - are you people open to the idea of an IRC/XMPP chan or a weblog/gemlog? following from afar (without being on the ML) looks like there's not a lot of activity, although i can see with my bare eyes the draft spec has evolved a lot - how confident are you in your DHT spec/implementation for scalability and security? are other people working on different implementations? is there a testbed one can run scalability checks with? - are you actively cooperating with other non-profit projects such as Tor? GNS sounds like it could be the missing piece in such crypto-secure routing schemes without memorable names ; i understand that GNS is part of GNUNet, but i'm asking about other ties/cooperations - why is it called "hyper hyper" local root? maybe i'm missing some context (despite reading about RFC7706 and froot), but "local root" or "user-editable root" sounds clearer to me - did i faithfully represent the technics/politics of GNS in those posts? if not please let me know so i can avoid to repeat the same mistakes: https://news.ycombinator.com/item?id=30155773 https://news.ycombinator.com/item?id=30155773 https://news.ycombinator.com/item?id=30156097 https://news.ycombinator.com/item?id=30156097 https://news.ycombinator.com/item?id=30156175 https://news.ycombinator.com/item?id=30156175 - how can we support GNS and help make it a reality?
- schanzen 5y ago> - are you people open to the idea of an IRC/XMPP chan or a weblog/gemlog? following from afar (without being on the ML) looks like there's not a lot of activity, although i can see with my bare eyes the draft spec has evolved a lot Yes, the only reason why there are no posts on the ML and very little posts on the GNUnet news archive is that I do this in my spare time. Now, the draft is mostly(TM) finished. So I do not see a reason for blogging anymore. > how confident are you in your DHT spec/implementation for scalability and security? are other people working on different implementations? is there a testbed one can run scalability checks with? That is a good question. GNUnet is still figuring out the transport layer. Until that is in a state that we are satisfied with, we will conduct performance tests. That being said, looking at other DHT proposals out there we think that R5N (and especially the improvements we have planned) are far superior. It still has strong roots in Kademlia though. > are you actively cooperating with other non-profit projects such as Tor? GNS sounds like it could be the missing piece in such crypto-secure routing schemes without memorable names ; i understand that GNS is part of GNUNet, but i'm asking about other ties/cooperations Yes. I think there was some collaboration here: https://datatracker.ietf.org/doc/html/draft-grothoff-iesg-special-use-p2p-names-02 https://datatracker.ietf.org/doc/html/draft-grothoff-iesg-sp... But we are not in regular contact and tor seems to go their own route. There are, however, similarities: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n2135 https://gitweb.torproject.org/torspec.git/tree/proposals/224... > - why is it called "hyper hyper" local root? maybe i'm missing some context (despite reading about RFC7706 and froot), but "local root" or "user-editable root" sounds clearer to me As this was confusing, it is removed from the draft. I think you can still find it on some slides when you look for it. In general, what is currently explained in the draft should be correct and there is no need to think about this too hard ;) > - did i faithfully represent the technics/politics of GNS in those posts? if not please let me know so i can avoid to repeat the same mistakes: https://news.ycombinator.com/item?id=30155773 https://news.ycombinator.com/item?id=30155773 https://news.ycombinator.com/item?id=30156097 https://news.ycombinator.com/item?id=30156097 https://news.ycombinator.com/item?id=30156175 https://news.ycombinator.com/item?id=30156175 I think so. There seems to be an understandable conflation of the technical means of name resolution (the draft) and the governance issues related to zones and names. Governance of zones (but especially root zone governance) is out of scope of the draft. But it is of major importance for any real world use. > - how can we support GNS and help make it a reality? My usual response would be: Install GNUnet and run a zone. But, we are currently in the process of fixing some major bugs in GNUnet and it is just not yet ready. As you correctly assessed, we are a very small team at the moment.
- remram 5y agoMaybe we should try to hype it as a possible place to store those NFT JPEGs and get some web3 money behind it.
- imoverclocked 5y agoGiven all the issues surrounding utf-8 and visually similar characters, I’m surprised by the bare sentence: The labels in a name are separated using the character "." (dot). Any mention of what happens with other dot-like codepoints?
- schanzen 5y agoWell, there is a section where we note this as well: https://lsd.gnunet.org/lsd0001/#name-abuse-mitigation https://lsd.gnunet.org/lsd0001/#name-abuse-mitigation Abuse through name confusion is possible, of course. I do not think this can be solved while at the same time supporting i18n. The real question is: What is the attack vector and how can it be mitigated. A GNS deployment and the selection of root zones should eventually converge towards a trusted namespace (for each individual user). There is not really any incentive having a TLD zone in your configuration that would allow such odd labels as there is not much use beyond fraud in using them. The governance policies ("rules") of the zone are expected to "trickle down" the delegation chains or alternatively damage reputation of the parent zone.