Join the #webinar on the GNU Name System (GNS) and the road to publishing an RFC.
GNS is a decentralized and censorship-resistant domain name resolution protocol providing an alternative to DNS. In 2023 the GNS was published as RFC 9498. The authors of the #RFC Martin Schanzenbach & Bernd Fix will talk about GNS & the road to published an RFC.
Stephen Farrell of Tolerant Networks will talk about getting advice with #standardisation processes.
February 22 at 13.00 CET https://nlnet.nl/webinars/
it has many flaws. such as what to do with HTTP request HOSTNAME field and HTTP servers processing of it. browsers send not some gibberish guids but domain names. and to write normal regexp rules in HTTP server paths processing one also needs names. and that names must be unique across the net. usually sites have links to other domains. not to some guids, but to domains. and they must also be unique. then, banning domains, subdomains, etc - they also have a problem here: without it a multitudes of spammers, unwanted content, etc will thrive on such a net. and there're many more lesser problems as well. it does not look like usable.
@iron_bug @NGIZero IDK, it looks reasonable enough while staying generic enough to accomodate future usage.
It is more close to http://www.somehash.onion URIs than to ordinary DNS zones. Browsers work with GNS zTLDs just as fine.
The idea is very similar here - rely on public key cryptography directly instead of trust-based registries and certificate roots.
@iron_bug sorry, I'm not sure I'm getting what's exactly the problem here with nginx and regexps. Can you post a brief example?..
I hosted and proxied both ways quite a few sites with nginx, but can't figure out how it relates to name records.
if you think that administrating site where you've got some mad guids instead of domains - try to writr a simple regexp for, say, nginx. this will help to get rid of weird ideas. and then, as an extended exercise, try to write http server that serves some domains wirh subdomains.