Opera to support sites using the .crypto top-level domain

EDIT: so would this mean that registering a .dev for some BigCo domain could potentially cause problems? Curious what the real-world implications might be.

I could've swore .local was okay, as that's what I use. But maybe not. Apparently it can cause issues with Macs, but that's new to me seeing as how I primarily develop on one.

ICANN is a corrupt organization that has usurped the power to delegate all names, relegating all of them¹ to their² DNS system where, ever since gTLDs, they may be expected lend just about any name. In effect, you are expected not to use a hostname, even on a local network, without paying tribute.

IMO, ICANN needs to be put down, or put to its place, as they do not have a natural right to all hostnames. If they wish to remain an authority on hostnames, they should reserve names for other uses besides DNS.

And stop with the gTLDs - it they give out all interesting TLDs, then there can't be non-colliding alternatives. IMO, if they collide, both are to blame, but ICANN more so than Opera, as they apparently reserve 0 viable host name hierarchies for uses other than DNS.

Please correct me if I'm wrong, some details may be incorrect.

¹ AFAIK exceptions are reserved TLDs: test, example, invalid and localhost. Not really a place for an alternate name system.

² AFAIK there used to be alternative DNS roots.

Let me put it in different terms: ICANN currently has a monopoly on the issuance of new TLDs that has so far banked hundreds of millions of dollars for them. There's no way in hell they're going to voluntarily give up this monopoly and just let any random people start a new TLD without going through them.

Theoretically, anyone could make a work-alike resolver service that used their own Ethereum node to query for results; in which case any attempts to censor UD could be routed around by pointing opera to a different dns-over-http server (assuming that is configurable, which is really up to opera, not the protocol).

I do like that idea actually -- if I published a self-signed SSL cert for my domain on the Ethereum blockchain, that could be returned and used to validate my domain, without any sort of CA having to be involved. The only trust needed would be that the HTTP-DNS-Ethererum server itself wasn't lying about which public key owned the on-chain domain record.

But one important detail about content-addressable storage systems like IPFS (and torrents) is that the linked content can never change. The link ipfs://QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/Aardvark.html is immutable and will only ever resolve to that specific version of the page. That's fine if you're just sharing a specific version of a document, but it means that this system alone isn't enough if you want to host a site that you update. In order to solve that use-case, you need some mutable link to be involved, like what DNS provides. If you have a standard domain name, you can add a _dnslink TXT record to your domain that contains an IPFS link, and then when someone visits the domain, IPFS-compatible browsers will see the _dnslink TXT record, get the IPFS link from it, and follow that to get the content from the IPFS swarm (which includes anyone that's helping re-host the content) instead of asking some HTTP server for it. When you update your site, you can update the _dnslink TXT record, and browsers will be able to find the new content when someone visits the site.

IPNS is an optional part of IPFS that allows you to make mutable IPNS links that may be updated. This is an attempt to make using an external system like DNS unnecessary to use for making updatable content. It lets you make IPNS links that instead of being based on the hash of the content, are based on a public key that's paired with a private key that you control. The owner of the private key is allowed to broadcast a signed message containing the immutable IPFS link that the mutable IPNS link should resolve to. Sounds great on paper, but it works really slowly for a number of reasons that might be fundamental to how it works. I'm not sure anyone really makes use of it in production. However, a lot of discussions/tutorials about IPFS present IPNS in a way that makes it seem like the standard way to use IPFS, and I think a lot of people get turned off when they see how slow it is and think it's unavoidable or that IPFS is like that in general. The wording of the previous post makes me a little worried the poster believes that too. I wish documentation around IPFS would stop emphasizing IPNS and instead emphasize the DNS integration. You can use DNS+IPFS instead of IPNS+IPFS and it works well; I assume more people use DNS+IPFS than IPNS+IPFS. And eventually we could use decentralized systems like Ethereum Name Service or ZNS instead of DNS once those systems are more popular.