Ipns ipfs

CIDs are like commit hashes in Git, which point to a snapshot of the files in the repository.::: calloutAn IPNS name can point to any arbitrary content path (/ipfs/ or /ipns/), including another IPNS name or DNSLink path. However, it most commonly points to a fully resolved and immutable path, i.e. /ipfs/[CID].:::How IPNS worksAnatomy of an IPNS nameA name in IPNS is the hash of a public key. It is associated with an IPNS record containing the content path (/ipfs/CID) it links to and other information such as the expiration, the version number, and a cryptographic signature signed by the corresponding private key. New records can be signed and published at any time by the holder of the private key.For example, the following is an IPNS name represented by a CIDv1 of public key: k51qzi5uqu5dlvj2baxnqndepeb86cbk3ng7n3i46uzyxzyqj2xjonzllnv0v8.Note: Kubo uses the self key (ed25519 private key used for the PeerID) as the default IPNS name. But you can generate multiple keys via ipfs key gen, and use them for managing multiple IPNS names.How IPNS names relate to content pathsIPNS record can point at an immutable or a mutable path. The meaning behind CID used in a path depends on used namespace:/ipfs/ – an immutable content on IPFS (since the CID contains a multihash)/ipns/ – a mutable, cryptographic IPNS name which corresponds to a libp2p public key.The following is a useful mental model for understanding the difference between the two: IPFS; IPFS-- immutable pointer -->content;"> graph LR; IPNS-- mutable pointer -->IPFS; IPFS-- immutable pointer

Title description IPNS (InterPlanetary Name System) Learn about mutability in IPFS, InterPlanetary Name System (IPNS), and how it can be used in conjunction with IPFS. InterPlanetary Name System (IPNS)InterPlanetary Name System (IPNS)Mutability in IPFSHow IPNS worksAnatomy of an IPNS nameHow IPNS names relate to content pathsIPNS names are self-certifyingCommon IPNS operationsIPNS is transport agnosticIPNS over the DHTIPNS over PubSubPublishing IPNS records over PubSub lifecycleTradeoffs between consistency vs. availabilityIPNS record validityIPNS record TTLPractical considerationsIPNS in practiceResolving IPNS names using IPFS gatewaysPublishing IPNS namesAlternatives to IPNSFurther ResourcesMutability in IPFSContent addressing in IPFS is by nature immutable: when you add a file to IPFS, it creates a hash from the data, with which the CID is constructed. Changing a file changes its hash, and consequently its CID which is used as an address.Yet, there are many situations where content-addressed data needs to be regularly updated, for example, when publishing a website that frequently changes. It would be impractical to share a new CID every time you update the website. With mutable pointers, you can share the address of the pointer once, and update the pointer – to the new CID – every time you publish a change.The InterPlanetary Name System (IPNS) is a system for creating such mutable pointers to CIDs known as names or IPNS names. IPNS names can be thought of as links that can be updated over time, while retaining the verifiability of content addressing.By analogy, IPNS names are like tags in git, which can be updated over time, and

-->content; Loading contentIPNS = **Pointer => content">IPFS = immutable *Pointer => contentIPNS = **Pointer => contentIPNS names are essentially pointers (IPNS names) to pointers (IPFS CIDs) whereas IPFS CIDs are immutable (because they're derived from the content) pointers to content.IPNS names are self-certifyingIPNS names are self-certifying. This means that an IPNS record contains all the information necessary to certify its authenticity. IPNS achieves this using public and private key pairs:Each IPNS name corresponds to a key pairThe IPNS name is a CID with a multihash of the public keyThe IPNS record contains the public key and signature, allowing anyone to verify that the record was signed by the private key holder.This self-certifying nature gives IPNS several benefits not present in hierarchical and consensus systems such as DNS, and blockchain identifiers. Notably, IPNS records can come from anywhere, not just a particular service/system, and it is very fast and easy to confirm a record is authentic.Common IPNS operationsAs a user or developer using IPNS for naming, there are three common operations worth understanding:Updating/Creating an IPNS record: refers to the creation of an IPNS record and signing it with a private key.Publishing an IPNS record: advertising the IPNS record so that other nodes can resolve it. Details depend on the transport.Resolving an IPNS name: Resolving an IPNS name to a content path.IPNS is transport agnostic "IPNS Record"] subgraph Routing Publisher Resolver Local[("Local store")] subgraph Transports PubSub[(PubSub)] DHT[(DHT)] end end Resolver-- resolve -->Record-- "(re)publish" -->Publisher Publisher-- PUT -->DHT-. GET .->Resolver Publisher-- PUT -->PubSub-.

Update.Practically, levers within your control determine where your IPNS name is on the spectrum between consistency and availability:IPNS record validity: longer validity will veer towards availability. Moreover, longer validity will reduce the dependence on the key holder (which for most purposes is stored on a single machine and rare shared) since the record can continue to persist without requiring the private key holder to sign a new record. Another benefit of a longer validity is that the transport can be delegated to other nodes or services (such as w3name), without compromising the private key.IPNS record TTL: longer TTL trades update propagation speed for better page load performance and resiliency.Transport mechanism: the DHT veers towards consistency while PubSub veers towards availability. However, with Kubo, IPNS names are always published to the DHT, while PubSub is opt-in. For most purposes, enabling PubSub is a net gain unless you hit the upper limit of connections as a result of too many PubSub subscriptions.IPNS in practiceResolving IPNS names using IPFS gatewaysIPNS names can be resolved by IPFS gateways in a trusted fashion using both path resolution and subdomain resolution style:Path resolution: resolution: IPNS resolution via an IPFS gateway is trusted (in the sense of trusting the gateway) which means you delegate IPNS resolution to the gateway without any means to verify the authenticity response you get, i.e the content path and signature of the IPNS record.Publishing IPNS namesSee the following guide on publishing IPNS names with Kubo and Helia.Alternatives to IPNSIPNS is not the

GET .->Resolver Publisher-- Cache -->Local-. GET .->Resolver-- Cache -->Local"> graph TB Record>"IPNS Record"] subgraph Routing Publisher Resolver Local[("Local store")] subgraph Transports PubSub[(PubSub)] DHT[(DHT)] end end Resolver-- resolve -->Record-- "(re)publish" -->Publisher Publisher-- PUT -->DHT-. GET .->Resolver Publisher-- PUT -->PubSub-. GET .->Resolver Publisher-- Cache -->Local-. GET .->Resolver-- Cache -->Local Loading The self-certifying nature of IPNS records means that they are not tied to a specific transport protocol. In practice, most IPFS implementations rely on the DHT and libp2p PubSub to publish and resolve IPNS records.There are nuanced differences and trade-offs between the DHT and PubSub to be aware of.The main qualitative difference between the two is that IPNS over the DHT publishes and resolves to a global shared state, whereas IPNS over PubSub uses messaging over topics (where each IPNS name has a unique topic) to publish to and resolve from interested peers.The main implication of this difference is that IPNS operations (publishing and resolving) over the DHT can take longer than over PubSub, while potentially ensuring higher consistency (you resolve to the latest version).Note: This trade-off is best explained by CAP theorem.IPNS over the DHTThe DHT is the default transport mechanism for IPNS records in many IPFS implementations.Due to the ephemeral nature of the DHT, records expire after 48 hours. This applies to any record in the DHT, irrespective of the validity (also referred to as lifetime) field in the IPNS record.Therefore, IPNS records need to be regularly (re-)published to the DHT. Moreover, publishing to the DHT at regular intervals ensures

Record, at the cost of potentially resolving to an outdated record.IPNS record validityWhen setting the validity (referred to as lifetime by Kubo) field of an IPNS record, you typically need to choose whether you favor consistency (short validity period, e.g. 48 hours) or availability (long validity period, e.g. 1 month), due to the inherent trade-off between the two.IPNS record TTLIf you experience slow IPNS update propagation, the Time-to-Live (TTL) setting is the first thing to check.TTL as a PublisherWhen you publish an IPNS Record, the default TTL, which controls caching, might be set to a high value, such as one hour. If you want third-party gateways and nodes to bypass the cache and check for updates more frequently, consider lowering this value.Kubo: Refer to the --ttl option in ipfs name publish --help for details on adjusting this setting.Note: If your IPNS Record is used behind a DNSLink (e.g., /ipns/example.com pointing to /ipns/k51..libp2p-key), the DNS TXT record at _dnslink.example.com has its own TTL. This DNS TTL also affects caching. Ensure that both TTL values are aligned for consistent behavior.TTL as a Gateway OperatorYou should have the ability to override the TTL provided by the publisher and set a lower cap on how long resolution results are cached.Kubo: Configure this using the Ipns.MaxCacheTTL setting.Rainbow: Adjust this with the RAINBOW_IPNS_MAX_CACHE_TTL environment variable.Practical considerationsThe most important thing to consider with IPNS names is how frequently you intend on updating the name and how long a valid record should be cached before checking for an