
Opera to support sites using the .crypto top-level domain - rguiscard
https://www.theregister.co.uk/2020/03/31/dreams_of_a_decentralized_web/
======
CydeWeys
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.

~~~
drcode
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.

~~~
CydeWeys
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.

~~~
konschubert
The ICANN .crypto might simply not get launched or fail after launch if the
name is already taken.

~~~
CydeWeys
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.

------
swiley
The article doesn’t mention how the .crypto namespace is managed. That’s
probably going to make or break this idea.

~~~
diggan
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)

\-
[https://github.com/unstoppabledomains/zns/blob/master/REGIST...](https://github.com/unstoppabledomains/zns/blob/master/REGISTRY.md)

\-
[https://github.com/unstoppabledomains/zns/blob/master/RESOLV...](https://github.com/unstoppabledomains/zns/blob/master/RESOLVERS.md)

\-
[https://github.com/unstoppabledomains/zns/blob/master/REGIST...](https://github.com/unstoppabledomains/zns/blob/master/REGISTRAR.md)

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

~~~
icebraining
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.

------
lildata
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](https://bugzilla.mozilla.org/show_bug.cgi?id=1354807)

------
actionowl
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.

~~~
rasz
There is no Opera anymore, just some Chinese scam vehicle
[https://www.androidpolice.com/2020/01/21/opera-predatory-
loa...](https://www.androidpolice.com/2020/01/21/opera-predatory-loans/)

------
k__
Is it possible to add IPFS via extensions to Chrome and Firefox?

~~~
diggan
Not only possible but already done!

\- [https://github.com/ipfs-shipyard/ipfs-companion](https://github.com/ipfs-
shipyard/ipfs-companion)

\- [https://chrome.google.com/webstore/detail/ipfs-
companion/nib...](https://chrome.google.com/webstore/detail/ipfs-
companion/nibjojkomfdiaoajekhjakgkdhaomnch)

\- [https://addons.mozilla.org/en-US/firefox/addon/ipfs-
companio...](https://addons.mozilla.org/en-US/firefox/addon/ipfs-companion/)

And I think Brave already ships with IPFS-Companion installed.

~~~
techntoke
IPNS is so slow though, that publishing with IPFS is a whole different story.

~~~
k__
Would you mind to elaborate for someone who knows next to nothing about
IPFS/IPNS?

~~~
AgentME
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.

~~~
k__
I see, thanks for the info!

Are ENS and ZNS faster?

~~~
AgentME
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](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!)

~~~
k__
I see!

Good to know.

------
Yizahi
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?

~~~
aarroyoc
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.

------
uasm
Broader question - is there some-kind of support planned for a DNS-like MX
address mechanism, for receiving emails via the .crypto domain?

------
Proven
If you care about privacy and security and use Opera, I don't think this will
help improve it...

