6 ms·

Sorry, but that reads a lot like "not invented here". You do realize that domains were invented so people could get to "places" instead of addresses, right? S

Sorry, but that reads a lot like "not invented here". You do realize that domains were invented so people could get to "places" instead of addresses, right? So pray tell, what would you replace domains with? And what advantage would your schema have over what exists now? Because, the addresses don't go away. Underneath whatever you come up with, will always be an IP address, and has to be, because you need a way to route packets. So whatever you want to replace domains with, has o solve the exact same problem: Wrap IP addresses in a nice, human friendly, hierarchically organized schema, that is easy to read, remember and type.

samatman 3y ago
Hierarchically organized is not a hard requirement. A domain could consist of nothing more than a unique Unicode string with no '/' or ' ' in it. It might do well to require a '.' be present, but even that isn't necessary. I'm quite content with what we have, however. A "unique string domain" regime has to pick between an anarchic landscape of independent registrars playing whack-a-mole with sniping and squatting, or a single central source of truth, neither of those strikes me as ideal. I don't think routing would actually be an issue though, given the power of today's servers and good algorithms for hashmaps in the many millions of keys.
- usrbinbash 3y ago
  > Hierarchically organized is not a hard requirement Technically correct, but in practical use, it is absolutely a requirement. Entities within domains are usually hierarchically organized, this already starts at the top level by having www.domain, mail.domain, dns.domain, file.domain, ... So if we implemented a scheme without built-in hierarchy, I can 100% guarantee that one of the first things admins will do, is implement their own hierarchy naming conventions on top of it, just to keep things organized. The difference then is, that we won't have one clear way to do that, but hundreds of different ones. > I don't think routing would actually be an issue though, given the power of today's servers Anything that relies on "worse solution offset by throwing more compute at it", is an instant "denied" in my book. That's how we ended up with electron apps.
  - samatman 3y ago
    You're greatly overstating the performance requirements here, DNS could just hash the string and farm out to 256 subservers running subsidiary hashmaps to the associated IP address. The multi-level schema is absolutely not a performance requirement, comparing this to Electron is silly, it is in fact much simpler than the DNS we have, with comparable demands in terms of memory and compute. We agree about the utility of heirarchy in domains on a social and administrative level, though.
    - usrbinbash 3y ago
      > You're greatly overstating the performance requirements here No I'm really not, I am simply saying that doing something in a way that requires way more compute for the same result, without ANY tangible advantage over the existing system, is a bad solution. It doesn't matter if its doable.

samatman 3y ago

Hierarchically organized is not a hard requirement. A domain could consist of nothing more than a unique Unicode string with no '/' or ' ' in it. It might do well to require a '.' be present, but even that isn't necessary. I'm quite content with what we have, however. A "unique string domain" regime has to pick between an anarchic landscape of independent registrars playing whack-a-mole with sniping and squatting, or a single central source of truth, neither of those strikes me as ideal. I don't think routing would actually be an issue though, given the power of today's servers and good algorithms for hashmaps in the many millions of keys.

usrbinbash 3y ago
> Hierarchically organized is not a hard requirement Technically correct, but in practical use, it is absolutely a requirement. Entities within domains are usually hierarchically organized, this already starts at the top level by having www.domain, mail.domain, dns.domain, file.domain, ... So if we implemented a scheme without built-in hierarchy, I can 100% guarantee that one of the first things admins will do, is implement their own hierarchy naming conventions on top of it, just to keep things organized. The difference then is, that we won't have one clear way to do that, but hundreds of different ones. > I don't think routing would actually be an issue though, given the power of today's servers Anything that relies on "worse solution offset by throwing more compute at it", is an instant "denied" in my book. That's how we ended up with electron apps.
- samatman 3y ago
  You're greatly overstating the performance requirements here, DNS could just hash the string and farm out to 256 subservers running subsidiary hashmaps to the associated IP address. The multi-level schema is absolutely not a performance requirement, comparing this to Electron is silly, it is in fact much simpler than the DNS we have, with comparable demands in terms of memory and compute. We agree about the utility of heirarchy in domains on a social and administrative level, though.
  - usrbinbash 3y ago
    > You're greatly overstating the performance requirements here No I'm really not, I am simply saying that doing something in a way that requires way more compute for the same result, without ANY tangible advantage over the existing system, is a bad solution. It doesn't matter if its doable.