ipfs name follow

[lgierth]

cc @vyzo

USAGE
  ipfs name follow <ipns-path> - Track changes to IPNS names.

SYNOPSIS
  ipfs name follow [--pin=true] [--allow-expired=true] [--] <ipns-path>

ARGUMENTS

  <ipns-path> - IPNS path of the name that should be followed.

OPTIONS

  --pin           bool   - Always pin the name's most recent content. Default: true
  --allow-expired bool   - Allow lookup even if a name's TTL is reached. Default: true

DESCRIPTION

  The 'ipfs name follow' command can be used to track changes to an IPNS name.
  A followed name will be refreshed in the background in intervals, so that
  lookups through an 'ipfs' command or the HTTP API are always instant and up-to-date.

  When called with '--pin' (default), after refreshes the name's new content
  is pinned. This is equivalent to 'ipfs pin replace /ipfs/QmOld /ipfs/QmNew'.

  When called with '--allow-expired' (default), lookups of the name through
  the 'ipfs' command or the HTTP API always return the last known content,
  even if the TTL has been reached and the name has expired. If this is the
  case, a warning is printed along with whatever is the command's respones.

  The combination of '--pin' and '--allow-expired' allows for convenient
  offline use cases. For example, on a long flight I'd like to have IPFS docs
  with me, and I'd like them to be usable at /ipns/docs.ipfs.io as always.

  Open question: pubsub

  Open question: refresh after ttl/2 or whatever
  - /ipns/QmFoo:       ttl = ipns-ttl
  - /ipns/dnslink.net: ttl = min(dns-ttl, ipns-ttl)

  Open question: storage of followings

[Stebalien]

Is this only active when the command is active? I see two different commands here: ipfs pin add --follow and ipfs resolve --follow.

Pinning

ipfs pin add --follow [--allow-expired=true] [--lazy=false] /ipns/QmId

This command will create a new (permanent) pin that will "follow" this IPNS address while the daemon is active.

Note: --lazy exists to mirror --prefetch below (basically: make a non-strict pin that doesn't download everything up-front).

Use-cases: Mirroring, backup, offline-replication.

Follow

ipfs resolve --follow [--prefetch] [--quiet] /ipns/...

Unlike the previous command, this "follow" would only remain active while the command is active. By default, unless --quiet is passed, it would print out each new target ipfs address as it finds newer IPNS records. If --prefetch is specified, this command will prefetch the linked contents. TODO: It should probably pin the contents with some form of temporary (low-priority?) pin but we don't really have those at the moment.

Use-cases: Authenticated data streams, website "feeds".

[lgierth]

@Stebalien yeah your proposal sounds good too!

[vyzo]

I am not sure we need a behaviour that is only available while the command is active - do we really care all that much about seeing background resolutions displayed in the terminal?

edit: of course it's not just human eyeballs consuming the output

[vyzo]

There is also the implicit relationship to ipns pubsub.
We can have the follow command work through pubsub or it can be something that does background resolutions.
The former is more efficient and adds value to ipns pubsub, the latter always works regardless of whether the other end have enabled pubsub.

[Stebalien]

edit: of course it's not just human eyeballs consuming the output

Exactly. That's more for e.g., webapps.

We can have the follow command work through pubsub or it can be something that does background resolutions.
The former is more efficient and adds value to ipns pubsub, the latter always works regardless of whether the other end have enabled pubsub.

I'd do both. Always use pubsub and occasionally check the DHT for updates (more frequently if we see updates through the DHT that we don't see through pubsub).

[matthewrobertbell]

An alternative could be allowing "pinning" of IPNS names, so that they are both automatically updated, the records republished by that node and the current IPFS object which is pointed to being automatically pinned as well.

This would mean that there is no requirement to keep a command running.

[rklaehn]

@Stebalien

so the ipfs resolve --follow --prefetch would only print out a new hash for a name once everything is pinned?

the ipfs pin add --follow command is permanently running in the background, but it would be great if there was a way to track what it is currently doing (what is the latest hash for the name, what is the latest hash that is fully pinned, etc.)

[vyzo]

I think I prefer the ipfs name follow approach, as it's clear that it something that works with namesys (ie it's ipns functionality).

[Stebalien]

An alternative could be allowing "pinning" of IPNS names, so that they are both automatically updated, the records republished by that node and the current IPFS object which is pointed to being automatically pinned as well.

That's the first command I proposed.

so the ipfs resolve --follow --prefetch would only print out a new hash for a name once everything is pinned?

No. Actually, it wouldn't even pin. That command would just print out the hash and then start fetching in the background. If you wanted a pin, you'd use ipfs pin add --follow ... (you could also do both).

the ipfs pin add --follow command is permanently running in the background, but it would be great if there was a way to track what it is currently doing (what is the latest hash for the name, what is the latest hash that is fully pinned, etc.)

For the latest hash, you'd just resolve the IPNS name (which should use the cache). "Fully pinned" is a bit trickier. The second we get a new hash, we'd unpin the previous version and start pinning a new one.

We could have a --keep-history (to keep past versions). However, we probably wouldn't have a way to query past versions.

I think I prefer the ipfs name follow approach, as it's clear that it something that works with namesys (ie it's ipns functionality).

Good point. I agree.

[mitar]

I think this is duplicate of #1467?

[Stebalien]

@mitar this issue exists to discuss specific designs (although it does address the needs of #1467).

[lockedshadow]

What a wonderful name! This upcoming feature looks very interesting.

And do I understand correctly that "following" nodes will republish the last seen value of given name, even if the creator of that name (with its private key) disappears once? Will the new nodes be able to resolve a value of that name, if the "following" ones will be present in network?

[vyzo]

that's an interesting idea.

[sonatagreen]

We could have a --keep-history (to keep past versions). However, we probably wouldn't have a way to query past versions.

This part feels like the sort of thing that might be best handled with IPRS involved somehow.