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

IPNS: should work with case-insensitive identifiers (Base32) #5287

Closed
lidel opened this issue Jul 26, 2018 · 18 comments
Closed

IPNS: should work with case-insensitive identifiers (Base32) #5287

lidel opened this issue Jul 26, 2018 · 18 comments

Comments

@lidel
Copy link
Member

lidel commented Jul 26, 2018

Version information:

0.4.16

Type:

bug

Description:

During the work related to ipfs/in-web-browsers#89 and https://github.com/ipfs/ipfs/issues/337 we've identified open problem with IPNS. We are unable to use current case-sensitive IPNS identifiers in case-insensitive URL contexts, namely:

https://<keyId>.ipns.foo.tld/
ipns://<keyId>/

keyId – PeerID or ID of a key generated via ipfs key gen

Not sure what would be the best way to tackle this.
Adding only a multibase prefix? Switching all keyId to CIDv1 ?

Part of ipfs/ipfs#337 (cc @kyledrake + @alanshaw for parity in js-ipfs)

Additional References:

@ghost
Copy link

ghost commented Jul 26, 2018

I think we'll have to wait for ed25519 IPNS keys, or do the same hackery as with CIDs.

@Stebalien
Copy link
Member

ed25519 IPNS keys are here. However, that doesn't help. We'll have to do the same CID hackery (or just switch to using CIDs).

lidel added a commit to ipfs/in-web-browsers that referenced this issue Jul 26, 2018
Missed the fact IPNS does not work in case-insensitive contexts right now.
More: ipfs/kubo#5287
@ghost
Copy link

ghost commented Sep 20, 2018

Let's switch to CIDs?

@kyledrake this issue should potentially be part of the base32 task force

@lidel
Copy link
Member Author

lidel commented Mar 18, 2019

Related discussion about PeerID in libp2p continues in libp2p/specs#138

@lidel
Copy link
Member Author

lidel commented Apr 15, 2019

I believe the MVP here is a scenario where:

  • people convert old Qm.. PeerID (base58btc - cidv0 - dag-pb - sha2-256)
    to bafy.. (base32 - cidv1 - dag-pb - sha2-256)
  • use the base32 result in /ipns/bafy.. addresses
  • .. and it just works (tm)

@Stebalien What would be the smallest set of changes to support this type of interop in go-ipfs?
Is it something someone not deeply familiar with go-ipfs codebase could PR?
If so, can you give me some pointers where to start?

@Stebalien
Copy link
Member

  • The current peer ID format is just base58btc(<sha2-256 multicodec><256><digest>) (just a multihash).
  • The new format would be <base32 multibase> ++ base32(<cidv1><libp2p key multicodec><the multihash>).

That is, we'd use an entirely new multicodec.


@Stebalien What would be the smallest set of changes to support this type of interop in go-ipfs?

That depends on how deeply we want to integrate this. If we only care about this for the subdomain feature, it would be pretty easy to redirect GATEWAY/ipns/Qm... to b...ipns.GATEWAY/.

@lidel
Copy link
Member Author

lidel commented Apr 17, 2019

There is an ongoing work to get IPNS fast (notes from today's meeting: ipfs/team-mgmt#948).
In the short term, fast resolve of IPNS in web browser context will most likely mean custom DNS server and resolving IPNS over DNS TXT records looking like this: dnslink=/ipns/<bafy>.ipns.dweb.link (where <bafy> is the new format in base32)

iiuc this means the immediate needs are:

  • Agree and add <libp2p key multicodec> to multicodec/table.csv and related libs, to unlock IPNS representation in subdomains (for actual hosting, and IPNS-over-DNS lookups)
    • Q: will this be just a single multicodec, or a family of entries depending on key subtype? are there any prior proposals on this?
  • Add support to HTTP Gateway for requests for <bafy>.ipns.GATEWAY/ and /ipns/<bafy>
    • Q: I imagine Gateway could just convert <bafy> to old school base58btc before doing the actual resolve, but it may get confusing if ipfs name resolve /ipns/<bafy> does not work. Would it be feasible to do the conversion there as well?

@lidel
Copy link
Member Author

lidel commented May 14, 2019

I see a small UX problem around having a dedicated multicodec:
How will go-ipfs behave if codec in /ipns/{cidv1} is different than libp2p-key?

  1. go-ipfs prints PeerID in Base58 QmNnooDu7bfjPFoTZYxMNLWUQJyrVwtbZg5gBMjTezGAJN
  2. User wants to convert it to CIDv1, so they do ipfs cid base32 {cid} or use https://cid.ipfs.io/
  3. cid base32 returns bafybeiagwnqiviaae5aet2zivwhhsorg75x2wka2pu55o7grr23ulx5kxm which has the dag-pb codec instead of libp2p-key (multicodec: add IPLD codec for libp2p public keys multiformats/multicodec#131)

This issue will mostly go away when we switch to displaying PeerID in CIDv1 everywhere, but for now we need to account for the above edge case.
I believe we should support support PeerID CIDv1 with dag-pb. If that is not feasible, then the gateway should do conversion and return HTTP 301 redirect from dag-pg PeerID to one with libp2p-key.

@Stebalien Thoughts?

@Zolmeister
Copy link

Please consider using Tor rend spec v3 address encoding for PeerIDs
Ref. libp2p/specs#139

@lidel
Copy link
Member Author

lidel commented May 27, 2019

@Zolmeister thank you for sharing. This issue is only about adding support for wrapping existing PeerIDs in CIDv1 to unlock web uses without huge refactoring (it does not change underlying way we construct PeerID). Discussion in libp2p/specs#139 is not blocked by this, feel free to continue it there 👍

@lidel
Copy link
Member Author

lidel commented May 27, 2019

Back to the issue at hand:

@lidel
Copy link
Member Author

lidel commented Jun 3, 2019

I've been looking at things we want to ship this in time for IPFS Camp.
This one looks doable. What remains here is:

@Stebalien will this be enough for HTTP Gateway support /ipns/<cidv1-with-libp2p-key>? If not, can you point me at places that need tweaking?

@Stebalien
Copy link
Member

#5287 (comment)

Sorry, completely missed this conversation. That's a valid concern and we may want to add a "hack it" redirect for now, or maybe a warning?

@Stebalien will this be enough for HTTP Gateway support /ipns/? If not, can you point me at places that need tweaking?

Bit late but the latest status is libp2p/go-libp2p-core#41

@lidel
Copy link
Member Author

lidel commented Jul 29, 2019

How will go-ipfs behave if codec in /ipns/{cidv1} is different than libp2p-key?

That's a valid concern and we may want to add a "hack it" redirect for now, or maybe a warning?

I am thinking the least amount of work/friction will be to

  • Do HTTP 301 redirect on the Gateway to fix the multicodec on-the-fly.
    This will ensure user ends up on a valid, canonical address in the browser.
  • "just work" on the CLI
    (ignore invalid multicodec on /ipns/{cid}, or display a warning with a valid path ready to copy&paste)

The issue will go away when we switch to CIDv1B32 everywhere,
so we should not stress too much about beyond making it work.

@Stebalien
Copy link
Member

Yeah, I guess. Just... grrr.

@lidel
Copy link
Member Author

lidel commented Oct 1, 2019

Tracking issue for peer IDs as cidv1b32: libp2p/specs#216

@lidel
Copy link
Member Author

lidel commented Feb 5, 2020

We are in the process of adding support for PeerID encoded as CIDv1 with libp2p-key multihash (libp2p/specs#216).

Seems that even tho we use go-libp2p-core v0.3.0 which includes libp2p/go-libp2p-core#41 there are still places which assume Multihash instead of CID:

$ ipfs name resolve -r /ipns/bafzbeiedwhhfhtte23hocn4k2bi4awpqay5sdhzqju7htk3y6sk63lvuae
Error: not a valid proquint string

$ ipfs resolve -r /ipns/bafzbeiedwhhfhtte23hocn4k2bi4awpqay5sdhzqju7htk3y6sk63lvuae
Error: not a valid proquint string

I'll try to track them down and fix, as it is blocking me from writing tests for #6096 😬

Update: found, will fix in #6096

lidel added a commit that referenced this issue Feb 6, 2020
This adds support for resolving /ipns/<cidv1-libp2p-key>

cc #5287

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
lidel added a commit that referenced this issue Feb 11, 2020
This adds support for resolving /ipns/<cidv1-libp2p-key>

cc #5287

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
lidel added a commit that referenced this issue Mar 4, 2020
This adds support for resolving /ipns/<cidv1-libp2p-key>

cc #5287

License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
@lidel
Copy link
Member Author

lidel commented Apr 16, 2020

This was fixed in #6096 and will ship with go-ipfs 0.5.0 (#7109) 🚀


When used in subdomain context, the HTTP Gateway will automatically convert case-sensitive identifier to base32 and redirect to URL with correct multicodec.

Command line and RPC API provide handy error message when an invalid multicodec is used in CIDv1:

# resolve Base58 PeerID
$ ipfs name resolve -r /ipns/QmY9DNm4UJxaTBB9FrhNkXQ75GaK43D8KhZtpJjmw8P7Sz
/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# convert PeerID to CIDv1 (with invalid multicoded, to illustrate next step)
$ ipfs cid base32 QmY9DNm4UJxaTBB9FrhNkXQ75GaK43D8KhZtpJjmw8P7Sz
bafybeieru3k6wvdzsrsjcx33jund7ebawoqlyc7jpitmn7wd4cwveunolm

# resolve CIDv1 with dag-pb multicodec
$ ipfs name resolve -r /ipns/bafybeieru3k6wvdzsrsjcx33jund7ebawoqlyc7jpitmn7wd4cwveunolm
Error: peer ID represented as CIDv1 require libp2p-key multicodec: retry with /ipns/bafzbeieru3k6wvdzsrsjcx33jund7ebawoqlyc7jpitmn7wd4cwveunolm

# resolve CIDv1 with libp2p-key multicodec suggested in previous step
$ ipfs name resolve -r /ipns/bafzbeieru3k6wvdzsrsjcx33jund7ebawoqlyc7jpitmn7wd4cwveunolm
/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@lidel @Stebalien @Zolmeister and others