3 ms·

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

by techntoke 7y ago

k__ 7y ago
Would you mind to elaborate for someone who knows next to nothing about IPFS/IPNS?
- AgentME 7y ago
  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__ 7y ago
    I see, thanks for the info! Are ENS and ZNS faster?
    - AgentME 7y ago
      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__ 7y ago
        I see! Good to know.

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

k__ 7y ago

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

AgentME 7y ago
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__ 7y ago
  I see, thanks for the info! Are ENS and ZNS faster?
  - AgentME 7y ago
    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__ 7y ago
      I see! Good to know.