-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
There is the issue that ipfs URLs are currently case-sensitive with base58 hashes, but this has been recognized as a problem: https://github.com/ipfs/ipfs/issues/337 QUrl also converts addresses to lowercase. So we can't currently load base58 hashes into QUrl; consequently switched load(QUrl) to load(QString) for now. Maybe it can be reverted when they switch to base32 hashes.
- Loading branch information
Showing
4 changed files
with
40 additions
and
20 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1c7c116
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know the context of this, but you can convert case sensitive CIDv0 (Base58) to case-insensitive CIDv1 in Base32 as noted in https://github.com/ipfs/ipfs/issues/337#issuecomment-435356238
The multihash inside of CID remains the same – CIDv1 just adds some things in the prefix to be more future-proof:
More: https://github.com/multiformats/cid#versions
Hope this helps :)
1c7c116
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not quite as bad as I wrote there... it turned out that QUrl::fromUserInput() causes trouble (for one, assuming that the url can be lowercase; for another, assuming that if it's not a local file, it must be http), but otherwise it seems a QUrl can actually hold a case-sensitive path. So following links in documents actually works, for example.
Yes I know I haven't tried too hard to actually interpret the hashes yet, and I really should. I think I want to add UI for some sort of hash calculator that breaks down the parts.
Another thing is it turned out I need to use the ipfs:// scheme, because KIO maps URL schemes to "slaves". Is there anything weird about that? It doesn't seem like the URL scheme is used so consistently everywhere. I.e. I would expect random URLs around the net that point to IPFS resources would use ipfs://the-hash/path/file or just ipfs://the-hash for direct links.
1c7c116
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fysa I wrote microspec at https://github.com/ipfs/in-web-browsers/blob/master/ADDRESSING.md#tldr
1c7c116
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good UX would be to show
ipfs://{cid}/path
or/ipfs/{cid}/path
in UI where possible, but also provide user with an option to copy shareable URL pointing at a gateway (eg.http://gateway.ipfs.io/ipfs/{cid}/path
), so it can be shared with people that don't run IPFS client.