Periodic reminder: you don't own your domain names -- you're just renting them from ICANN. Therefore, if you rely upon DNS, you don't fully control your stack.
@enkiv2 weirds me out how many tools /can't/ handle IPs, too, even among fairly nerdy tools.
It sort of makes sense if they're written in the era before the DNS system proper existed, when every site maintained its own /etc/hosts -- IPs are liable to change but you could keep names consistent. And then for a while everybody assumed DNS was cheap enough that everybody would keep their names in perpetuity (100% not true).
@enkiv2 Oh! That does make it make much more sense; I forgot about about like, local name resolution. Thanks.
@enkiv2 I mean, yes, but - you don't own your connection from your ISP either, and most people don't own their own netblock (Though I have a couple of friends jealously hoarding their personal class Cs even though nobody will route them anymore :)
How far down the rabbit hole do you want to go?
You can either let go of the need for full control or end up holed up in your own private compound at war with the world.
This is the slippery slope to the dark side.
@jollymnemonic @enkiv2 @feoh
Sure, but in this instance, the infrastructure is state-supported big capital with a wide variety of motivations to extract rent and/or demand content changes. The vulnerability here isn't 'other people' but 'arbitrary hierarchy' -- and we are at the bottom, with no potential for advancement.
@jollymnemonic @enkiv2 @feoh There's a difference between walling off from other equals you could form interactions that benefit everyone involved and walling off from domineering monopolies that make money off of surveillance and centralization. One of these hurts everyone involved and one is self defense
@forAll52 @jollymnemonic @enkiv2 Sure, I get it, and that's laudable. I guess what I was somewhat snarkily (and for that I sincerely apologize) poking at was that at some point the giant playground we all inhabit is in fact run by giant monopolies, and until we create the grand unified people's internet that's free of BigCorps, there is exactly NO way to get away from that. You can avoid ICANN by pretending DNS doesn't exist, but what's the point when your ISP can just turn you off?
@forAll52 @jollymnemonic @enkiv2 See now THIS is my point! If we're gonna go down the rabbit hole, let's do it right, shall we? There are several efforts out there that overlay an indie network on top of the internet that also extends out to multiple local mesh(es) with the idea that if the tubes were ever shut down, this thing could keep rolling and grow through sneakernet and the like. Yggdrasil is one example. You can see others here: https://github.com/redecentralize/alternative-internet#networking - why not invest effort in one of them?
@enkiv2 You could always run your own local DNS server. There are various simple implementations out there to choose from, or you could federate /etc/hosts.
This bugs me all the time. Is there a viable alternative?
@emsenn @ajroach42 @enkiv2 I'd certainly say DNS shows it's age and we could do better (though DoH/DoT don't go far enough to hold my interest). It's slow, doesn't protect privacy, and has crypto bolted on in a ugly and complex way. Plus requiring yearly doesn't mesh well when trying to make URLs last.
However I don't see how to move away from managing domains centrally if we want to be able to share and remember URLs.
@enkiv2 This shows where my head is at more than anything, but could it be handled better with package management tools of some sort? Rather than a presumption of centralizing, a presumption of active maintenance. Most folk's would be opaque, like the package manager on their phone, but it might make it easier... some of the problems to be addressed? (If this is bad feel free to just say so, I know enough to know I know nothing about this topic.)
Another interesting one is Tor Hidden Services.
Those essentially serve to cover all the edges of the unique/not-centrally-managed/memorable triangle we haven't managed to break for identifiers.
@emsenn @danyspin97 @enkiv2 @alcinnz @ajroach42 this is by far one of the most insightful discussions I've read a while. The approach of directly using the public key information to address locations is the one I favor (see onion and other services), mostly because of the single requirement to know who you want to talk to.
The issue still remains on how to "beautify" the URLs while not sacrificing security.
@ajroach42 That's about where I'd lean too - but with some user-tools for helping handle the distribution and updating and sharing of those lists - i.e. me be able to put up a JSON file of my chosen domain names and their addresses, so folk could get it and keep it updated. @danyspin97 @enkiv2 @alcinnz @lvl
@lvl @emsenn @danyspin97 @enkiv2 @ajroach42 Yeah, I'd favor an approach of mapping identifiers (even if they're still centrally managed) to cryptographic certificates, and then optionally mapping those on to IP addresses.
That seems to be simpler and covers more use cases.
Also DHTs seem like a good match to distribute the lookups, whilst hash prefixes could serve well to protect privacy.
I think there's an upper limit on how well technology can solve this political/social problem. The internet, and the web in particular are in many ways not only about accessing the things you know and care about (that which you put into your /etc/hosts), but also about referring stuff and being referred to it (DNS, URLs).
There's other compromises which can be made (and it makes sense to allow people to make those comprises for their own domains), but I do support DNS's approach. Though the lookup protocol could be greatly improved.
Semicommutative petnames (like collaborative tagging where tags slowly route through the system) makes sense to me. This is how user display names work on SSB. Human-readable names & unique names should exist but needn't be the same name.
if human-readable names are non-unique, there's the problem that it's impossible to own the thing that people will remember, and i'd say that in many cases that's a bad thing, and malicious/ignorant actors can steal names. DNS is actually quite good at solving this, because it's not really expensive to own a good name, but it's too expensive to just own large parts of the attractive namespace in order to troll everyone else.
@alcinnz so basically [/etc/hosts, dot onion, the rest]? :P
also, i think a honorable mention in this thread should go to
a) running your own (local) DNS (trusts yourself or someone in the same organization)
b) MDNS/avahi (trusts everyone who can broadcast to your local network to assign assign their own hostname under '.local')
@alcinnz @enkiv2 @zalandocalrissian @lvl @emsenn @danyspin97 @ajroach42
I guess. Despite performance problems, IPFS (for static files) and SSB (for social networks) seem to be the closest to 'the right thing' on the grounds that they put the most thought into how to do it right, so my impulse is to build on their terminology & concepts -- i.e., universal addresses based on content hashes, a second namespace for mutable collections of permanent items, & petnames as tags.
UUCP site names only needed to be unique for "well known sites". Maybe we can do something similar with pet names. Operating systems and browsers manage to maintain and distribute a list of CA certificates for bootstrapping PKI, so why not do the same for transitive pet names?
@enkiv2 @zalandocalrissian @lvl @emsenn @danyspin97 @ajroach42 @alcinnz
Incidentally, can we really think of anything cryptographic as being permanent? Keys get compromised. Cryptosystems and hashes get broken. To be permanent a URI would have to be referring to content stored in an immutable append-only log or something.
@alcinnz @ajroach42 @danyspin97 @emsenn @lvl @zalandocalrissian @enkiv2
The cryptographic authentication DNS extension you're thinking of is probably DANE. Google essentially killed it by refusing to implement it in their browser. It relies on the DNS hierarchy and DNSSEC anyway so shares all its flaws.
1. Publish your content in a well-known newspaper or journal.
2. Your URI is the issue identifier, page number, and column. Include the date of issue to avoid any ambiguity from publication name collisions.
We need an analog to this.
@ajroach42 everything that isn't permanent can be compromised; that's immutability's utility in a nutshell. How resistent to compromise does your thing need to be?
There's a reason we mark property lines with inch thick steel poles driven 8 feet down, y'know? hard to muck with that.
Une instance se voulant accueillante pour les personnes queers, féministes et anarchistes ainsi que pour leurs sympathisant·e·s. Nous sommes principalement francophones, mais vous êtes les bienvenu·e·s quelque soit votre langue.