@Hyolobrika @dpwiz
no, names in GNS are relative. there's never any conflict. if you link to example.com on a page you serve then it has to be resolved against your key. if I link to it on a page I serve then mine
there is no "global" namespace, only vendor defaults plus whatever you personally configure. but note that this is already the case. you can already, today, muck with your resolver or hosts file and do as you please. names are and will only ever be global by observance of convention
so as for convention. if GNS were to achieve widespread adoption the only sane path would be for ICANN centralized TLDs to remain exactly as they are and for vendors to ship them as the default. what you gain is security and autonomy in various ways. it decentralizes and hardens the underlying system design while still retaining the centralized defaults
no, names in GNS are relative. there's never any conflict. if you link to example.com on a page you serve then it has to be resolved against your key. if I link to it on a page I serve then mine
there is no "global" namespace, only vendor defaults plus whatever you personally configure. but note that this is already the case. you can already, today, muck with your resolver or hosts file and do as you please. names are and will only ever be global by observance of convention
so as for convention. if GNS were to achieve widespread adoption the only sane path would be for ICANN centralized TLDs to remain exactly as they are and for vendors to ship them as the default. what you gain is security and autonomy in various ways. it decentralizes and hardens the underlying system design while still retaining the centralized defaults
@roboneko @dpwiz But can't that cause confusion? If GNUnet e.V. won't include .foo for an illegitimate reason, someone can create it. But two people can create it at once with different PKEYs. If person A has one PKEY for .foo in their root zone and person B has another, then their systems will interpret different things by, say, https://www.bar.foo/. If person A wants to use the version of .foo that person B uses, then they'll have to import it as .foo2. But what if the server at www.bar.foo doesn't recognise the domain www.bar.foo2? That's what I meant by causing a problem with virtual hosts.
@Hyolobrika @dpwiz no. every url must be interpreted in the context of whoever published it. that's different from the current system
... ok it's not actually different. if I mess with my hosts or otherwise deviate from the ICANN system then urls I publish might lead somewhere different for me than for you
on client C, bar.foo on a page published by host A has to be resolved against key A while the *exact same url* on a page published by host B has to be resolved against key B. it's never resolved against key C even though C is the one doing the lookup in this scenario. the lookups are context sensitive by definition, instead of right now where they're *technically* context sensitive but everyone pretends they aren't and there's no formalized way to share local customizations beyond "here's an ip, stick it in your hosts and I'll let you know if it ever changes"
so anyway 99% of the time you would presumably still just use the ICANN system or one of the blockchains or whatever. the operators would serve them via the new protocol and keys would work a bit differently but on the surface everything is still the same
then in cases where you're only interacting with a closed group you don't need to bother with the centralized stuff anymore
or if your domain got pulled, you still control the private key. at any time prior to it being pulled people who visited via the "front door" could have copied off the key for themselves
maybe think of it as nomadic key based identity for DNS
... ok it's not actually different. if I mess with my hosts or otherwise deviate from the ICANN system then urls I publish might lead somewhere different for me than for you
on client C, bar.foo on a page published by host A has to be resolved against key A while the *exact same url* on a page published by host B has to be resolved against key B. it's never resolved against key C even though C is the one doing the lookup in this scenario. the lookups are context sensitive by definition, instead of right now where they're *technically* context sensitive but everyone pretends they aren't and there's no formalized way to share local customizations beyond "here's an ip, stick it in your hosts and I'll let you know if it ever changes"
so anyway 99% of the time you would presumably still just use the ICANN system or one of the blockchains or whatever. the operators would serve them via the new protocol and keys would work a bit differently but on the surface everything is still the same
then in cases where you're only interacting with a closed group you don't need to bother with the centralized stuff anymore
or if your domain got pulled, you still control the private key. at any time prior to it being pulled people who visited via the "front door" could have copied off the key for themselves
maybe think of it as nomadic key based identity for DNS
@roboneko @dpwiz Is it different or isn’t it?
it’s not different from the current system
Seems not to be. That’s basically what I was pointing out in the OP. What they’ve got seems to violate one of their stated design principles:
4: GNUnet must be self-organizing and not depend on administrators or centralized infrastructure.
As for
the lookups are context sensitive by definition, instead of right now where they’re technically context sensitive but everyone pretends they aren’t and there’s no formalized way to share local customizations beyond “here’s an ip, stick it in your hosts and I’ll let you know if it ever changes”
Can you explain further? What does “context-sensitive” mean in this context?
nomadic key based identity for DNS
What does this mean?
Follow
@Hyolobrika @roboneko Virgin DNS:
Requires shittons of tiered hardware and links to withstand hordes of users asking for the same set of names shoveled into a few root zones.
Has a central authority to govern the zones and appoint regional registrars.
Names are a scarce resource and most of the sane ones are squatted.
Requires parallel PKI infra to prevent hijacking and stuff.
Occasionally you lose your name and/or certificate to scammers and/or governments.
Chad GNS:
The more users there are, the more traffic it can handle.
The network itself is your "secondary".
Everyone can share their zone for free.
Content is authenticated and can be anonymised.
Isn't actually required for the rest of the ecosystem to function, but you can share your KVs with friends anyway.
@Hyolobrika @dpwiz Sorry, didn't get around to responding yesterday. Not sure if your questions are still relevant after you saw that document but I guess I'll answer anyway.
> What does “context-sensitive” mean in this context?
It means that example.com only maps to the same place for you and me because we happen to observe the same conventions when resolving the address. Where a particular author intended for a name to point is dependent on their local context. Everyone pretends there's only one way to do this but in reality I am free to hack on my system resolver and resolve .com differently than everyone else does. People just *don't* because it would be completely unmanageable at present.
Actually technically they do, GNS, ENS, and Tor are all examples of such. Try to resolve a .onion domain on a computer that isn't running tor and see how well it goes. That's context sensitivity.
Another example of this breaking down is if you pull up an old fedi message and try to follow a link for neckbeard.xyz. In the context of that message the author intended for that name to resolve to sjw's fedi instance but it no longer does. The current context is different and the link is now broken as a result.
> > nomadic key based identity for DNS
> What does this mean?
Right now a tld such as .com authorizes you to map a particular name to an ip address (or some other sort of DNS record, the exact details aren't important). To a third party visiting your website you *are* the name. But at the end of the day you don't really control that name, the respective tld does. How are you supposed to seamlessly handle a name change?
For GNS instead of the tld controlling "your" name they associate your key with that name and then you can map things under your key however you'd like. Instead of your name being your identity your name resolves to a cryptographic identity. And a user is able to save a copy of your key at any time, so if the tld changes things they can still resolve your stuff.
It might help to glance at the examples in this section of the docs. https://www.gnunet.org/en/use.html#gns_cli
I suppose an "evil" tld might hypothetically be able to refuse to publish your key and instead directly map ips for you. At least I assume - I don't know enough about the details so I might be wrong. But even if so, my understanding is that it's not intended to be used that way.
You'd still probably want "default" tlds like you have right now. And they'd still presumably be centrally controlled. Right now various certs come preinstalled with browsers and operating systems. I don't think that would change. What would change is that your domain becomes its own zone and people can alias it to whatever they want and there's a standardized way to share, install, and manage all these zone keys.
So to me it seems like blockchain DNS and GNS are somewhat orthogonal. Blockchain stuff is creating a new registrar that operates internally quite differently from the current ones and isn't subject to ICANN. GNS is about the protocol details of how you associate names with identities and sort of turns everyone into their own registrar. Then you register your registrar with another registrar under a name and everything is recursive.
Presumably an ENS domain under GNS would want to map to a zone key instead of an IP or whatever else. Since ENS already supports stuff like IPFS hashes I assume supporting GNS keys would be trivial but I don't actually know how it would all work.
> What does “context-sensitive” mean in this context?
It means that example.com only maps to the same place for you and me because we happen to observe the same conventions when resolving the address. Where a particular author intended for a name to point is dependent on their local context. Everyone pretends there's only one way to do this but in reality I am free to hack on my system resolver and resolve .com differently than everyone else does. People just *don't* because it would be completely unmanageable at present.
Actually technically they do, GNS, ENS, and Tor are all examples of such. Try to resolve a .onion domain on a computer that isn't running tor and see how well it goes. That's context sensitivity.
Another example of this breaking down is if you pull up an old fedi message and try to follow a link for neckbeard.xyz. In the context of that message the author intended for that name to resolve to sjw's fedi instance but it no longer does. The current context is different and the link is now broken as a result.
> > nomadic key based identity for DNS
> What does this mean?
Right now a tld such as .com authorizes you to map a particular name to an ip address (or some other sort of DNS record, the exact details aren't important). To a third party visiting your website you *are* the name. But at the end of the day you don't really control that name, the respective tld does. How are you supposed to seamlessly handle a name change?
For GNS instead of the tld controlling "your" name they associate your key with that name and then you can map things under your key however you'd like. Instead of your name being your identity your name resolves to a cryptographic identity. And a user is able to save a copy of your key at any time, so if the tld changes things they can still resolve your stuff.
It might help to glance at the examples in this section of the docs. https://www.gnunet.org/en/use.html#gns_cli
I suppose an "evil" tld might hypothetically be able to refuse to publish your key and instead directly map ips for you. At least I assume - I don't know enough about the details so I might be wrong. But even if so, my understanding is that it's not intended to be used that way.
You'd still probably want "default" tlds like you have right now. And they'd still presumably be centrally controlled. Right now various certs come preinstalled with browsers and operating systems. I don't think that would change. What would change is that your domain becomes its own zone and people can alias it to whatever they want and there's a standardized way to share, install, and manage all these zone keys.
So to me it seems like blockchain DNS and GNS are somewhat orthogonal. Blockchain stuff is creating a new registrar that operates internally quite differently from the current ones and isn't subject to ICANN. GNS is about the protocol details of how you associate names with identities and sort of turns everyone into their own registrar. Then you register your registrar with another registrar under a name and everything is recursive.
Presumably an ENS domain under GNS would want to map to a zone key instead of an IP or whatever else. Since ENS already supports stuff like IPFS hashes I assume supporting GNS keys would be trivial but I don't actually know how it would all work.
@Hyolobrika @dpwiz I assume so, since you are resolving mappings in a store.
@dpwiz @roboneko Thank you. This document (attached) helped me a lot anyway.