Feature: Advanced ipns tooling

[kpcyrd]

Type:

Feature

Description:

While discussion ipns on irc, the following tools might be interesting for advanced ipns operations, eg. during DDoS:

• support signing ipns records offline: Allow creating ipns records offline. Assuming a node is down/offline, the ipns pointer would expire after a while, causing a resolve failure. If a backup of the private key exists, I could theoretically create a new ipns record that is accepted by all nodes that are able to see it.
• support seeding ipns records on multiple nodes: An offline signed record could be seeded on ipfs from multiple untrusted nodes, so taking them down with a simple DDoS is harder. Those nodes would announce my record while its valid and discard it when it expires. With some scripting I could build a system that signs records offline and announces them from multiple nodes to avoid a single point of failure.

[whyrusleeping]

I really want both of these.

Not sure where exactly to put it in the api though, could be something like:

ipfs name record create <params>
ipfs name record push <rawdata>

[kpcyrd]

For additional input:

ipfs name record sign <params>
ipfs name record seed <rawdata>

but I don't have any strong opinion on this, I like create/push as well.

Maybe an additional inspect command might make sense as well that prints the encoded data in a human readable way to ease debugging.

In the end, this should work:

RECORD=`ipfs name record create $params`
ipfs name inspect "$RECORD"
ipfs name push "$RECORD"

Also, for even more bonus points, something like this:

while sleep 5m; do
    # TODO: resolve-raw feels somewhat clunky
    ipfs name resolve-raw $params | ipfs name push
done

These might be related to ipfs name follow from #4435

[mildred]

ipns name republish NAME ?

[mildred]

Why not something like this...

Generate raw data

ipfs name generate [--lifetime=<lifetime>] [--key=<key>] [--] <ipfs-path>

Will do just like ipfs name publish but instead of publishing the record, will print it on the standard output (probably base58 encoded, or perhaps not?)

Use case: generate a record for others to publish

Publish a record

ipfs name publish --raw [--] [<raw-record>]

Additional form of ipfs name publish but with a --raw option. It will decode the raw record and publish it as it is. The private key is not needed to publish the record.

edit: if the raw record is not on the command line, it is read from stdin (with or without encoding?)

Use case: seed offline generated record

Resolve a raw record for republish

ipfs name resolve --raw [--] [<name>]

An additional option to ipfs name resolve to print a (base58 encoded probably, or not) raw record. It can be used to republish the record as it is with ipfs name publish --raw

Use case: republish a record taken from the network

Republish a record

ipfs name republish [--follow] [--extend] [--key=<key>] [--] <name>

Will republish a record already existing on the network.

• --follow: if specified, the republish will keep running to republish the record forever. Else the record is only republished once.
• --extend: if specified, the record is extended to exceed its lifetime. The secret key will need to be available to resign the record (using --key=<key>)

Use case: have multiple nodes to republish the same record in case the primary node is failing

added: Inspect a record

ipfs name inspect [<raw-record>]

Use case: inspect a raw record so it is readable and we know what it contains

---

What do you think?

[kpcyrd]

@mildred sounds great. For the commands accepting a raw (untrusted) record it might make sense to accept the data on stdin instead, but this might be neglectable. The only thing I would want to add to the list would be the inspect command to parse the raw record into something human readable and/or json. This would also be useful for debugging when combined with ipfs name resolve --raw because you would get additional information that isn't accessible with a regular resolve.

[whyrusleeping]

@mildred Thats a great proposal, I don't disagree with any of it.

@kpcyrd its pretty easy to accept from either stdin or an explicit argument. We can definitely do that. also 👍 to the 'inspect' command.

[mildred]

Added the inspect command so we don't forget about it.

Also, if the raw record is read from stdin and not the command line, it is possible to skip the encoding part and have the raw binary bytes. Perhaps we should add an option to choose the encoding of the record itself (default being binary). Something like --enc=binary|hex|base64|base58.

disclaimer: I'm interested in the republish command so I can publish a record on my laptop and have my server follow it and republish it forever

[whyrusleeping]

Something like --enc=binary|hex|base64|base58.

We generally use --input-enc, but yeah. Agreed.