While I think a URL shortener is an interesting project and an interesting application of IPFS (e.g., by using dnslink + an IPFS directory of all registered paths), I don’t think we really want a “blessed” centralized URL shortening service.
Really, we’d rather not even have to run the gateways (we’ve been toying with ways to make them more decentralized). We only do that as a stop-gap. However, a URL shortener like this seems a bit more permanent.
If we ever did introduce something like this as a blessed service, we’d definitely want to use some form of decentralized consensus algorithm.
We also need to consider the concrete problem we’re trying to solve as there are other solutions. So, why do we want something like this? What’s wrong with the current system?
IPFS urls look long and unwieldy
- Solution: Don’t show them. Put them in
<a> tags, etc. This is my preferred solution. In my perfect world, users would treat IPFS resources as tangible objects. Unfortunately, this would require better browsers and operating systems.
- Solution: Use an alternative, shorter encoding. E.g., a zero-width encoding that can be copied. If users don’t need to read the URLs, there’s no reason show them.
IPFS urls can’t be copied from paper
Solution: Use a QR code.
IPFS urls can’t be spoken/typed
Story: Professor writes a URL on the board.
Ideally, we’d live in a world with augmented reality and, again, we could just treat the URL as a tactile object. Unfortunately, we don’t.
This is really the only case where I think we actually need some form of shortener. Well, there are some other fancy solutions with IPNS and QR codes but they have some sever usability drawbacks.