I've just released 2.0.15beta4 with a small experiment: _URL Shortener_.
It is located under right-click context-menu.
When executed against a page or an image, it creates a small static HTML page that when opened, redirects user to original, long URL. The redirect page is published to IPFS and a shareable public URL is copied to user's clipboard.
Would appreciate some feedback.
Default CIDs are bit long, so this experiment uses a non-cryptographic hash function suitable for general hash-based lookup: murmur3 (32bit version is supported by go-ipfs thanks to @tabrath).
Examples:
Question:
murmur3 for URL Shortener? I don't know man, I feel like this really shouldn't live in the /ipfs namespace, since it removes the most important property of things within /ipfs: being able to cryptographically verify the contents.
Default CIDs are bit long, so this experiment uses a non-cryptographic hash function suitable for general hash-based lookup: murmur3 (32bit version is supported by go-ipfs thanks to @tabrath).
Wow, I hadn't noticed -- this is not good, for the reason above. We shouldn't allow non-cryptographic hashes in /ipfs or /ipns.
Yeah.. a lot of things here smell weird.
Been using "URL Shortener" a bit today and I am worried about the confusion between option to "get short url" and "upload to IPFS". In both cases user ends up with IPFS path, one is "native", one might redirect to "non-distributed internet".
I'll sleep on it, but I think this should be removed from browser extension.
Instead, a distributed web-app could serve the same purpose under own namespace.
@lidel please don't publish this feature, insecure hashes will be blocked in future breaking this completely.
The experiment is already removed 👌 Glad it at least helped to surface problems with murmur3.
I am closing this issue. Blocking murmur3 in /ipfs/ namespace is tracked in https://github.com/ipfs/go-ipfs/issues/4371