Opera to support sites using the .crypto top-level domain(theregister.co.uk)
theregister.co.uk
Opera to support sites using the .crypto top-level domain
https://www.theregister.co.uk/2020/03/31/dreams_of_a_decentralized_web/
55 comments
This is going to turn out to have been a huge mistake once the actual .crypto is added as a real TLD to root DNS come ICANN's round 2 expansion of new gTLDs.
Are we supposed to care that ICANN's feelings are hurt? Hopefully this is a step to replacing ICANN with something better.
If you think ICANN is some sort of magical organization that should get to decide all TLDs, just vote with your feet and don't use Opera.
If you think ICANN is some sort of magical organization that should get to decide all TLDs, just vote with your feet and don't use Opera.
ICANN's feelings are irrelevant here. The point is that they control the DNS root servers and no one else does, so anyone claiming to operate a TLD that isn't actually in the root servers is gonna have a bad time.
Think of what a disaster this is going to be if .crypto is launched for real in a few years. Opera is likely going to go with the real .crypto in the root DNS, thus dumping all these blockchain ones, but even if they don't, there's the problem that now .crypto domains will resolve differently in Opera than in all other browsers. That is a security/usability nightmare.
> If you think ICANN is some sort of magical organization that should get to decide all TLDs
There's nothing magical about ICANN whatsoever, and the normative claim you're making here is irrelevant. They are the organization that decides TLDs, period, and pretending that they aren't when the other 99.999% of users and devices on the Internet do use root DNS and root DNS only is a recipe for disaster.
Think of what a disaster this is going to be if .crypto is launched for real in a few years. Opera is likely going to go with the real .crypto in the root DNS, thus dumping all these blockchain ones, but even if they don't, there's the problem that now .crypto domains will resolve differently in Opera than in all other browsers. That is a security/usability nightmare.
> If you think ICANN is some sort of magical organization that should get to decide all TLDs
There's nothing magical about ICANN whatsoever, and the normative claim you're making here is irrelevant. They are the organization that decides TLDs, period, and pretending that they aren't when the other 99.999% of users and devices on the Internet do use root DNS and root DNS only is a recipe for disaster.
The ICANN .crypto might simply not get launched or fail after launch if the name is already taken.
If they haven't delegated it yet then it's by definition not yet taken as far as they're concerned, and they're the ones that make these decisions.
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.
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.
> the system is riding on top of the existing DNS rather than operating as an alternative
I assume that if .crypto becomes a TLD, Opera will default to DNS lookup first.
I assume that if .crypto becomes a TLD, Opera will default to DNS lookup first.
If it has enough adoption, hopefully ICANN would reserve it for Opera or Unstoppable Domains, in the same way they wouldn't sell me .coke or .google.
Why on earth didn't they try to use a TLD for it though? Why would you use a feature of the protocol you're trying to replace?
It would have made much more sense to define a new URI scheme.
It would have made much more sense to define a new URI scheme.
A new URI would have made a lot more sense. This current plan, intentionally causing collisions with actual real DNS, is a disaster in the making. .crypto is one of the most desired and anticipated strings for the next round of gTLD expansion, and ICANN is not gonna forego the revenue from that auction. This is all a guaranteed disaster in the making.
Did you mean a new scheme? AFAIK both http, https, and ftp, ssh, rtp, whatever protocols refer to names in their URIs. Names, which may be resolved by different, configurable methods, a few of which are popular, DNS among them, but also hosts files, avahi, netbios, maybe others. There are usually at least 2 of them active.
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.
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.
You've got quite an agenda here, but the nitpicks don't change the simple fact that making a fake TLD that isn't in root DNS, when the vast majority of users and devices out there will continue using root DNS and root DNS only, is a really bad idea. I'd even go so far as to call it foolish. That's why using a different URI scheme would be smarter: you can control it. You can't control root DNS because that's ICANN's job. At best you can control stuff at the TLD level, if ICANN lets you by delegating you a TLD.
Hostnames and DNS are not equivalent. Those are not nitpicks.
People use alternative name systems. They can be used with existing protocols and URIs. It's explicitly supported - neither local hosts file nor avahi are DNS. Problem is you need names to use, and you can't really pick non-conflicting ones, if any new gTLDs may be issued by ICANN.
There are alternative name systems, mostly using unique alternative TLDs and AFAIK none of them are registered or reserved at ICANN. I presume ICANN doesn't support it, or they want payments as in gTLDs. Payments for protection against future conflicts, not for a service as they do not resolve in DNS.
The article may not be clear, but AFAICT *.crypto are in fact resolving domains (among doing other things). When I install support for crypto names on my system, am I supposed to use something like:
I agree appropriating .crypto in particular may be a bit presumptuous. At the same time, one might expect .crypto to be administered by crypto, in whatever chaotic way people side with, along with the ensuing brokenness.
People use alternative name systems. They can be used with existing protocols and URIs. It's explicitly supported - neither local hosts file nor avahi are DNS. Problem is you need names to use, and you can't really pick non-conflicting ones, if any new gTLDs may be issued by ICANN.
There are alternative name systems, mostly using unique alternative TLDs and AFAIK none of them are registered or reserved at ICANN. I presume ICANN doesn't support it, or they want payments as in gTLDs. Payments for protection against future conflicts, not for a service as they do not resolve in DNS.
The article may not be clear, but AFAICT *.crypto are in fact resolving domains (among doing other things). When I install support for crypto names on my system, am I supposed to use something like:
ping crypto:<domain>
ping --crypto <domain>
I agree appropriating .crypto in particular may be a bit presumptuous. At the same time, one might expect .crypto to be administered by crypto, in whatever chaotic way people side with, along with the ensuing brokenness.
People shouldn't be using alternative name systems. It causes a huge amount of pain and has been known to do so for several decades now. See: https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html
The best advice is to use a REAL name, that you own. The second best advice is to, if for some reason you insist on using a fake name, pick something with a low probability of causing collisions. .crypto has a very high probability of causing collisions and is thus a terrible choice.
The best advice is to use a REAL name, that you own. The second best advice is to, if for some reason you insist on using a fake name, pick something with a low probability of causing collisions. .crypto has a very high probability of causing collisions and is thus a terrible choice.
ICANN wouldn't sell you .google because we already own it. They wouldn't sell you .cocacola because that's an unambiguous brand name that would only go to the rightful TM holder. They would sell you .coke depending on your use case; that's a generic word that has plenty of non-brand meanings, particularly in mining and refining: https://en.wikipedia.org/wiki/Coke
But ICANN would have no qualms whatsoever about selling a TLD just because some other people claimed authority over it they didn't actually have and started misusing it.
But ICANN would have no qualms whatsoever about selling a TLD just because some other people claimed authority over it they didn't actually have and started misusing it.
Yeah. After the .dev disaster, you'd think people would have learned their lesson...
I have a .dev domain and completely missed this. What happened?
Google owns the .dev TLD, and they bought it for entirely internal use. People got upset about this (any company owning a TLD for internal use only is pretty weird, and especially one as generic as ".dev") so they started to offer it to the public.
The bigger issue is that a lot of people use .dev for internal/development uses, and it should therefore never been made into a "real" TLD in the first place. It's like deciding to sell "example.com" to someone.
The bigger issue is that a lot of people use .dev for internal/development uses, and it should therefore never been made into a "real" TLD in the first place. It's like deciding to sell "example.com" to someone.
If anyone's curious, there's a shortlist of "official" TLDs to use for local development https://tools.ietf.org/html/rfc2606#section-2
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.
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.
I registered a .dev for my company, but because it's a company of one I imagine this won't affect me then. Good to know though. I do recall using .dev for local/internal development years ago...
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.
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 don’t think there are really any implications moving forward. It only affected developers in the first place. Developers have since been forced to stop using .dev for development, thanks to the existence actual .dev domains.
Yeah, at this point the horse is out of the barn, so don't worry about registering a .dev. Any damage that would be done has already happened. The point is it shouldn't have happened in the first place.
Developers have been using <something>.dev as their localhost hostname even though the .dev TLD wasn't a designated test/reserved TLD[0]. Everyone's non-https development environments broke when Google added the TLD to HSTS preload, forcing browsers to load it in HTTPS.
https://news.ycombinator.com/item?id=15268701
0: https://tools.ietf.org/html/rfc2606#section-2
https://news.ycombinator.com/item?id=15268701
0: https://tools.ietf.org/html/rfc2606#section-2
Many people were using the .dev tld as some sort of local tld.
And I guess it was probably cheaper for Google to just buy the TLD and not fix their internal processes?
I think ICANN will continue with more disasters, you just wait :)
The article doesn’t mention how the .crypto namespace is managed. That’s probably going to make or break this idea.
Don't have time (nor the interest really) but found the reference docs, seems to explain how it works:
- https://github.com/unstoppabledomains/zns
- https://github.com/unstoppabledomains/zns/blob/master/REGIST...
- https://github.com/unstoppabledomains/zns/blob/master/RESOLV...
- https://github.com/unstoppabledomains/zns/blob/master/REGIST...
So in the end, I think there is a central registrar for each gTLD, so basically the same as we're doing now, just a different organization behind it and blockchain!1!11oneone
- https://github.com/unstoppabledomains/zns
- https://github.com/unstoppabledomains/zns/blob/master/REGIST...
- https://github.com/unstoppabledomains/zns/blob/master/RESOLV...
- https://github.com/unstoppabledomains/zns/blob/master/REGIST...
So in the end, I think there is a central registrar for each gTLD, so basically the same as we're doing now, just a different organization behind it and blockchain!1!11oneone
The Registrar is an ethereum contract, not a company, though. I believe this means that once you have a domain tied to your wallet, nobody can take it down or transfer it without your private keys. The Admins can only sell new domains.
Opera works with Unstoppable Domains for the .crypto domains. Maybe you can look it up at UD's website https://community.unstoppabledomains.com/t/unstoppable-x-ope... to see how to manage the .crypto?
Not OP, but nothing on there seems to explain whether UD is just running a database-backed DNS server which they could change at their whim / govt order, or whether ownership and DNS records are actually stored on-chain ala Ethereum's ENS, or NameCoin.
Reading the website/github, the domains are stored on-chain, but UD provides an HTTP API (essentially a DNS-over-HTTPS resolver), and that could obviously be censored. It's not clear to me if Opera is reading directly from the chain or using UD's API, but I suspect the latter.
If that's the case, then I think that qualifies as reasonably decentralized, at least for me.
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.
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.
I'm glad, Opera is offering native support for Wallets, ENS & IPFS. It is a proof that they can still lead the way.
There is also some progress made by Brave what will really help in term of market share.
Unfortunately native support on Firefox is not there yet... https://bugzilla.mozilla.org/show_bug.cgi?id=1354807
Something crazy is going on inside Opera. My opera extension has been pending review since January 12th, Firefox, Chrome, and Edge have all accepted it.
There is no Opera anymore, just some Chinese scam vehicle https://www.androidpolice.com/2020/01/21/opera-predatory-loa...
They're the smallest, so I suspect they have limited resources for projects/departments they can't profit from.
Is it possible to add IPFS via extensions to Chrome and Firefox?
Not only possible but already done!
- https://github.com/ipfs-shipyard/ipfs-companion
- https://chrome.google.com/webstore/detail/ipfs-companion/nib...
- https://addons.mozilla.org/en-US/firefox/addon/ipfs-companio...
And I think Brave already ships with IPFS-Companion installed.
- https://github.com/ipfs-shipyard/ipfs-companion
- https://chrome.google.com/webstore/detail/ipfs-companion/nib...
- https://addons.mozilla.org/en-US/firefox/addon/ipfs-companio...
And I think Brave already ships with IPFS-Companion installed.
IPNS is so slow though, that publishing with IPFS is a whole different story.
Would you mind to elaborate for someone who knows next to nothing about IPFS/IPNS?
Plain IPFS (without the IPNS part) lets you create links to files (or directories) where the link is based on the hash of the files, and when someone visits the link, their IPFS node will automatically look through the peer-to-peer IPFS swarm to find any nodes hosting the files. Anyone that wants to help host the files can pin the files in their node, and then their node will mirror the files and help serve them to others. It's basically Torrent magnet links rebuilt to be usable for web browsing.
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.
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.
I see, thanks for the info!
Are ENS and ZNS faster?
Are ENS and ZNS faster?
Yes, they don't have IPNS's slowness problems. (Well, I can speak about ENS. I don't know anything specifically about ZNS, but I'm going to assume it works similarly.) The problem with IPNS is that the holder of the private key is the source of truth for the current value of an IPNS link. The private key holder can broadcast signed messages with the current value of the link to the rest of the network to cache and re-serve, but when a client gets a cached signed value, it can't know if that's the most up-to-date value for the link, so the client keeps on asking the rest of the network for a while about the current value for the link to see if anyone else has a more up-to-date value. (As opposed to when a client is fetching the content of a standard IPFS link, the client can know the content is right as soon as it gets an answer from anyone in the swarm because its hash is equal to the link. This means regular IPFS links don't have this problem at all.)
With ENS, the source of truth for the current value of all domains is the Ethereum blockchain. Every full Ethereum node has a copy of the blockchain and keeps it updated, so any node can immediately produce an authoritative answer about any domain. ENS still has the property of IPNS that only the holder of a private key can update their domain's current value, but they just have to submit any changes to the blockchain to apply them. This means that a client doesn't have to look any further than any node with a copy of the blockchain to find the current value.
Another benefit of systems like DNS and ENS over IPNS is that DNS and ENS can have human-friendly chosen names. IPNS links are always based on public keys and look like random strings. ENS and IPNS are both decentralized, but only blockchain-based systems like ENS can solve Zooko's Triangle (https://en.wikipedia.org/wiki/Zooko%27s_triangle) and have secure decentralized human-meaningful names. (Blockchains often get a lot of nonsense hype for things they don't make any sense for, but this use-case is specifically the kind of thing that blockchains are uniquely good at!)
With ENS, the source of truth for the current value of all domains is the Ethereum blockchain. Every full Ethereum node has a copy of the blockchain and keeps it updated, so any node can immediately produce an authoritative answer about any domain. ENS still has the property of IPNS that only the holder of a private key can update their domain's current value, but they just have to submit any changes to the blockchain to apply them. This means that a client doesn't have to look any further than any node with a copy of the blockchain to find the current value.
Another benefit of systems like DNS and ENS over IPNS is that DNS and ENS can have human-friendly chosen names. IPNS links are always based on public keys and look like random strings. ENS and IPNS are both decentralized, but only blockchain-based systems like ENS can solve Zooko's Triangle (https://en.wikipedia.org/wiki/Zooko%27s_triangle) and have secure decentralized human-meaningful names. (Blockchains often get a lot of nonsense hype for things they don't make any sense for, but this use-case is specifically the kind of thing that blockchains are uniquely good at!)
I see!
Good to know.
Good to know.
[deleted]
I tried to understand what IPFS is - it looks like that distributed file storage project from pre-bitcoin era but with added blockchain on top. So my question is - can you delete a file from this system?
IPFS doesn't have a blockchain, it's more like BitTorrent. Can you delete a file? Well, by definition all files in the universe are already defined there, as IPFS is content-addresable (the file hash is used as URL),
This means that you can actually delete the file from your local IPFS client, but if someone manages to create the exact same file and put it on the network, people will access to the file using the same link.
This means that you can actually delete the file from your local IPFS client, but if someone manages to create the exact same file and put it on the network, people will access to the file using the same link.
Someone else already explained what IPFS is. So let me offer a different way of seeing the whole "can you delete a file from this system?" thing.
IPFS is a protocol, just like HTTP. So the question could be rephrased as "How do you delete a file from HTTP?" The answer is: you don't. Just as on the web and on the internet, you can link files from your machines. If someone downloads it, they can share it with others. If no one downloads it, and you stop sharing it, it's effectively deleted. Same goes for IPFS.
IPFS is a protocol, just like HTTP. So the question could be rephrased as "How do you delete a file from HTTP?" The answer is: you don't. Just as on the web and on the internet, you can link files from your machines. If someone downloads it, they can share it with others. If no one downloads it, and you stop sharing it, it's effectively deleted. Same goes for IPFS.
Broader question - is there some-kind of support planned for a DNS-like MX address mechanism, for receiving emails via the .crypto domain?
If you care about privacy and security and use Opera, I don't think this will help improve it...
PaulHoule(1)