ipfs object stat should print out the hash #1082
Comments
dylanPowers
added
backwards incompatible: protocol
sprint
and removed
backwards incompatible: protocol
labels
|
On Tue, Apr 14, 2015 at 02:11:47PM -0700, Jeromy Johnson wrote:
I'm leaning toward ‘ipfs resolve’, since ‘ipfs object --help’ says: 'ipfs object' is a plumbing command used to manipulate DAG objects and “what's the hash for ?” sounds more important than plumbing Anyway, is changing the default namespace for ‘ipfs name resolve’ too
This is basically the the same approach taken by Git when they 1: #1093 (comment) |
|
On Mon, May 04, 2015 at 09:23:07PM -0700, W. Trevor King wrote:
Talking about this with @jbenet and @whyrusleeping on IRC 1, it's $ ipfs name resolve <*-or-ipfs-path> If the goal is to keep the IPFS and IPNS portions as separate as $ ipfs name resolve [--recursive] [] for (recursive) IPNS lookups and then use: $ ipfs resolve for just the IPFS portion. That means: $ ipfs resolve /ipns/ would error out and you'd have to use: $ ipfs resolve $(ipfs name resolve --recursive ) that draws a good line between IPFS and IPNS, but it does mean you'd /ipns/some.ca/example.net/static/ae.io/css/beautiful.css Resolving that with disjoint dns/IPFS/IPNS tooling would look like: $ ipfs dns resolve some.ca You could write a shell script to handle that automatically, I'm also not clear on whether the tightly focused resolution here is In this version of the future, we don't need to migrate the ‘ipfs name |
|
I think we should have: # ipfs only resolution
# `ipfs object` planned to be renamed `ipfs dag`
ipfs dag resolve <ipfs-path>
# ipns only resolution
ipfs name resolve <ipns-path>
# porcelain combining the others
ipfs resolve <ipfs-or-ipns-path>which i think covers your concerns.
👍 to this. having dns inside ipns is a convenience hack, but we should also have this. We should publish it as a standalone tool too. (need to make the cmds lib less of a mess for this to be easy)
don't have to, with not meaning to force things to be in multiple processes (i'd prefer not, given the state of kernel process costs), but to make the toolchain very granular so users can take + hack only the parts they need.
Agreed, this is needed.
More concrete example? |
|
On Wed, May 06, 2015 at 03:56:18AM -0700, Juan Batiz-Benet wrote:
So my concern here is that if you compile a porcelain ‘ipfs resolve
You could have multi-step IPNS references: $ ipfs name resolve QmKey1 which you could resolve with --recursive: $ ipfs name resolve --recursive QmKey1 And once you sprinkle in DNS links, you could have: $ ipfs name resolve QmKey1 Without the prefix, if you do a non-recursive: $ ipfs name resolve QmKey1 (vs. /ipns/QmKey2), there's no way to decide the protocol. Is that a $ ipfs name resolve QmKey1 So you can say, “Ah, it starts with ‘/ipns/’. I bet the next segment The current interface mostly works because (1) we always do |
|
@wking small note: github doesn't like the inlined emails. it hides them under [...]. i think most people will miss your comments. maybe copy over the quoted section to the top? see
Yeah i agree. which is why ipns should take pat as a value (including the prefix). |
|
On Wed, May 06, 2015 at 03:47:09PM -0700, Juan Batiz-Benet wrote:
They don't like PGP/MIME email either, and they occasionally drop my
Top-posting makes it hard to figure out what I'm responding to though.
Ok, the output from those I agree with. But if ‘ipfs name resolve $ ipfs name resolve /ipns/QmSomeIPNSKey1 |
|
|
it would provide an easy way to find the hash of a path:
Should tell us what the hash of 'd' is.
Alternatively (or additionally) we could have an
ipfs resolvecommand that outputs the hash that a path resolves to.The text was updated successfully, but these errors were encountered: