should be able to cat public keys.

[jbenet]

Public keys should be accessible as ipfs objects:

> ipfs id -f="<id>"
QmTcSiJtSRiaGLtfV2qPdhUJFxqYGCNpZfzYhYWWXB4p8p
> ipfs cat QmTcSiJtSRiaGLtfV2qPdhUJFxqYGCNpZfzYhYWWXB4p8p
CAASpgQwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSC9U64WGryMbzLvkY5h/JkymHHbejgPXpWo+4X/sZOwJFeXcCyB4L7TVmA4mzazezhiASM7ZfeL7ZQglWxENjVu0sBccNc1lMlCcqK70sGn+sWfqgQRMzfx32cDDbcGM4frVonDn2wiYzGbkY0IC8LfbHH6qAynUs4axPYhXI9GuNdOvOwlzAyndCJ6IP/iSIdYHKRyQbHpKP2O47/gGsluqoi3TDcYH8voVCEFd9HYd2ycjZ3wQeu3YebC2H4GrW0qtGGi4Axw4JV9iaUUVo/jimFsDz/w+LquRUmDo/1r/q7O/nQErTvDuPJy6JRkclMgzF5rF8gedCM73MIfVQrVRazdrGRbLtMOo4af4TIEqKeVsUnK8lWsPSIu0HL5fhHTgOMGdIxh7xPAEB4m0Hs3So5VaM9r9qkTww+dR4eKo1gGBoYLdxZnW2PZG5sr85FYY3v7X2c8MI+p52cMnJ9gDN521IDc6OtWOv0ShhZoZuERlEUSx+fxj+fjQ91rICOQv1gBtc8pEbFYFBGXNGT03YEyae3SRTnjACkRV3DbsRrpPbqxpooY0QVcUZhyjBR++zRPFrltpUvG2nyBm+4tNmF712HmcmdT5YKblgUXNnNzHf1tbvw5wWQ6MJaM14XtAQ1NXcGDJ8bhdlyCPuSgoQunDlPXrLpIXJe/eQbwIDAQAB

this means we'd have an object wrapping a public key, which is fine and may be used to link to other useful information, but it does mean a bit of working in the pk exchange to ship the ipfs format.

[whyrusleeping]

i was thinking of just storing the public key as a block. otherwise things will get messy

[whyrusleeping]

but i guess we cant cat blocks... (or can we?)

[jbenet]

but i guess we cant cat blocks... (or can we?)

let's not, that sounds worrisome.

a middle-ground is to re-define the merkledag without the protobuf encoding to be valid leaf objects. i dont like having to do this, but i may be necessary. the need is showing in several places

[wking]

Talking this over with @whyrusleeping on IRC earlier today, my feeling
is that we should follow Python's lead with “All data… is represented
by objects…” 1. It sounds like the mutable DHT tree is currently:

DHT key: /{per-node-thing-you-want}/{node-you're-asking-about}
DHT value: {some-data-in-an-arbitrary-format}

So /pk/QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7 gives you my
public key. What I think we should do instead is use IPFS objects for
all the data, and just use IPNS for the mutable references (but not
the payload). So we get

DHT key: /{per-node-thing-you-want}/{node-you're-asking-about}
DHT value: {IPFS-key}

and then in IPFS:

IPFS key: {IPFS-key}
IPFS value: {some-data-in-a-protobuf}

For things that you need frequently (like node public keys), you can
store the IPFS value alongside the DHT entry referencing the object
(saving a separate DHT traversal), but that's just an optimiziation
(you'd still want to store the IPFS object in its usual place, so
folks could find it with ‘ipfs object get {IPFS-key}’).

Migrating from {some-data-in-an-arbitrary-format} to
{some-data-in-a-protobuf} is going to change hashes, but I think
that's an acceptable one-time cost (once we work the kinks out of the
migration tooling) in return for the ability to handle public keys,
IPNS symlinks, etc. with the usual IPFS object tooling (you just lose
the mutable reference from the initial DHT lookup).