Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Advanced ipns tooling #4536

Open
kpcyrd opened this issue Jan 1, 2018 · 8 comments
Open

Feature: Advanced ipns tooling #4536

kpcyrd opened this issue Jan 1, 2018 · 8 comments
Labels
kind/enhancement A net-new feature or improvement to an existing feature topic/ipns Topic ipns

Comments

@kpcyrd
Copy link
Contributor

kpcyrd commented Jan 1, 2018

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
Copy link
Member

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>

@whyrusleeping whyrusleeping added kind/enhancement A net-new feature or improvement to an existing feature topic/ipns Topic ipns labels Jan 2, 2018
@kpcyrd
Copy link
Contributor Author

kpcyrd commented Jan 3, 2018

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
Copy link
Contributor

mildred commented Jan 3, 2018

ipns name republish NAME ?

@mildred
Copy link
Contributor

mildred commented Jan 3, 2018

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
Copy link
Contributor Author

kpcyrd commented Jan 3, 2018

@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
Copy link
Member

@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
Copy link
Contributor

mildred commented Jan 4, 2018

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
Copy link
Member

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A net-new feature or improvement to an existing feature topic/ipns Topic ipns
Projects
None yet
Development

No branches or pull requests

3 participants