### Author:  [@0zAND1z](https://discuss.ipfs.tech/u/0zAND1z)
#### Post date: [January 8, 2018, 8:05am UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/1 "2018-01-08T08:05:46Z")
Hi there!
I am working on an IPFS based CI tool for solidity smart contracts on Ethereum Blockchain ([Ethereum/Solidity Smart Contract CI Toolchain on IPFS! (WIP)](https://discuss.ipfs.tech/t/ethereum-solidity-smart-contract-ci-toolchain-on-ipfs-wip/1780/2))
The core component of sharing in this architecture becomes tedious if we don’t shorten the looong IPFS URL for each folder under an ipns. 😅
Is anyone working on the URL Shortener just for the IPFS links? Let me know in the comments pls…
PS: Happy to contribute(PRs) if any such projects in current…
---
### Author:  [@stebalien](https://discuss.ipfs.tech/u/stebalien)
#### Post date: [January 9, 2018, 12:47am UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/2 "2018-01-09T00:47:09Z")
That’s actually a perfect use-case for an eth app. Unfortunately, the cost of shortening urls would be prohibitively expensive (and bla bla comparability with existing browsers…). Unfortunately, I don’t know of any existing projects.
---
### Author:  [@fiatjaf](https://discuss.ipfs.tech/u/fiatjaf)
#### Post date: [January 10, 2018, 3:05am UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/3 "2018-01-10T03:05:06Z")
I don’t understand why would anyone want that. Creating an URL-shortener for IPFS content is throwing away all the protocol.
---
### Author:  [@Jared4DataRoads](https://discuss.ipfs.tech/u/Jared4DataRoads)
#### Post date: [January 10, 2018, 3:59am UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/4 "2018-01-10T03:59:24Z")
One fruitful line of investigation might be in how you use the multihash. Trying a hash with less bits will obviously tradeoff shortness for lower security against collision attacks, but this sounds like a tradeoff you may be willing to make. You might also be able to find a more compact representation than Base64. As a trivial example, URL path strings theoretically allow enough characters to support up to Base69 if your HTTP service lets you directly parse the normally reserved character set (domain names only support up to Base36 cleanly due to case insensitivity and the requirement that ‘-’ are each surrounded by other legal characters).
I wouldn’t want to fill up the finite multihash type table with any domain-specific hashes, but some hash types may (at least theoretically) have different collision characteristics with specific serialized data structures, which could in turn be exploited to _only ever use them to hash a limited subset of file types_, which in turn further helps limit the risk of global namespace collisions. For example, I imagine a lot of Ethereum smart contract linked files are rather text-heavy in order to retain some semblance of lawyer-readability, so if you could find a low bit total hashing method that is particularly collision resistant _only_ when applied to UTF-8 documents, you could use that multihash on those files independently of the default or more commonly used hash types as a matter of course, both as a shortener and a cross-hash collision avoidance method.
Definitely food for thought for any format-specific crypto hash researchers.
---
### Author:  [@0zAND1z](https://discuss.ipfs.tech/u/0zAND1z)
#### Post date: [January 10, 2018, 4:45pm UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/5 "2018-01-10T16:45:28Z")
I understand your premise…
But we need the shorting of URLs at some time from the usability perspective, right?
---
### Author:  [@fiatjaf](https://discuss.ipfs.tech/u/fiatjaf)
#### Post date: [January 10, 2018, 6:16pm UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/6 "2018-01-10T18:16:24Z")
Of course not. IPFS is a protocol, the goal is for everyone to be running their own IPFS nodes. Not to create infrastructure around the [ipfs.io](http://ipfs.io) gateway (if that’s what you thinking about).
Anyway, I fail to see why from the user’s perspective a big identifier is worse than a short identifier.
Even if it was much better (and possible) to have super small identifiers, would you really trade all the decentralization and immutability for that? If yes, why can’t you use S3 hosting with bit.ly, then?
---
### Author:  [@0zAND1z](https://discuss.ipfs.tech/u/0zAND1z)
#### Post date: [January 10, 2018, 6:33pm UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/7 "2018-01-10T18:33:10Z")
I have made attempts to actually shorten the url’s and run it by my own url shortening service… It worked!
But the problem now lies in domain hosting. I wish I could get some help directly from Protocol Labs.(cc @jbenet & @whyrusleeping)
Maybe host this on ipfs.to or some sub-domain of [ipfs.io](http://ipfs.io) (maybe [to.ipfs.io](http://to.ipfs.io) ?)
If someone is serious enough to make a decision, I can put some extra time and host a Redis Cache for a production grade server. 👍
---
### Author:  [@stebalien](https://discuss.ipfs.tech/u/stebalien)
#### Post date: [January 10, 2018, 8:17pm UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/8 "2018-01-10T20:17:13Z")
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 `` 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](https://github.com/multiformats/multibase/issues/27) 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.
---
### Author:  [@leerspace](https://discuss.ipfs.tech/u/leerspace)
#### Post date: [January 10, 2018, 8:46pm UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/9 "2018-01-10T20:46:24Z")
To add some other considerations onto URL shorteners:
1. They hurt performance by requiring at least one redirect
2. If (when?) they stop working all of their links are broken
- I’m not sure how inevitable this would be if this was done in a decentralized way. Doing it through a sub-domain on [ipfs.io](http://ipfs.io) doesn’t sound like such a way, though.
- Archive Team has spent a lot of time trying to archive shortened URLs for URL shortening services that have come and gone, leaving a trail of broken links in their path.
1. With IPFS, immutability is lost (as @fiatjaf already mentioned). A link that used to redirect to one hash could theoretically be made to redirect to another.
Unless “the core component of sharing in this architecture” involves manually typing URLs, it would be nice to not increase users’ exposure to the weaknesses of URL shorteners.
---
### Author:  [@fiatjaf](https://discuss.ipfs.tech/u/fiatjaf)
#### Post date: [January 10, 2018, 9:08pm UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/10 "2018-01-10T21:08:19Z")
None of the currently widely deployed URL-shortening services solve any of the problems you’ve mentioned. Who in his right mind (unless it’s the only solution and the last) copy shortened URLs from bit.ly or goo.gl to and from paper? Or speak them? That’s impossible. `bit.ly/z30YI8r`? no way.
The solution was always to have people link to things. I don’t believe IPFS will ever replace the entire web with its hashes, but if it is, it will only be when URLs become, as you say, tangible objects. Until them, we still have domain names and mutable websites that can serve as passage points to IPFS URIs.
If you want to speak an URL today you’ll probably have to host it some easily-spoken domain + path and tell people to visit it. You can still do that. Each person may do that in their own way, like they’re doing today.
(Actually, I thought a lot in the last days on the problem of spokenable URLs and in the end produced [https://filemap.xyz/](https://filemap.xyz/), which is a mutable site with a mutable database, but that links to immutable IPFS objects.)
---
### Author:  [@stebalien](https://discuss.ipfs.tech/u/stebalien)
#### Post date: [January 10, 2018, 10:07pm UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/11 "2018-01-10T22:07:00Z")
> [@fiatjaf](#):
>
> None of the currently widely deployed URL-shortening services solve any of the problems you’ve mentioned. Who in his right mind (unless it’s the only solution and the last) copy shortened URLs from bit.ly or goo.gl to and from paper? Or speak them? That’s impossible. bit.ly/z30YI8r? no way.
1. People _do_ write down urls like `bit.ly/z30YI8r`. They don’t speak them, but they’ll write them on a whiteboard or print them.
2. For speakable URLs, there was shoutkey (but that appears to have gone away).
The only other reason to use a URL shortener is to put URLs in tweets.
---
### Author:  [@Jared4DataRoads](https://discuss.ipfs.tech/u/Jared4DataRoads)
#### Post date: [January 10, 2018, 11:25pm UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/12 "2018-01-10T23:25:04Z")
I enjoy the discussion on the pros and cons of URL shorteners in general, and agree that a sort of “blessed forever-shortener” is impractical to the point of impossibility, but I’m also afraid we may be speaking at cross-purposes here.
Framing the problem in the context of the original question – use of shortened references in a particular set of Solidity contracts – I would note that the short-form redirects only need to survive a little longer than the contracts that are referencing them, in the same way that QR codes only need to be valid a little longer than the set of visual media that contain them. Yes I know people want to write contracts that will last forever+1 years, but we do have a thing called “statute of limitations” in legal frameworks for good reasons. Until Aubrey De Gray formulates the exact correct monkey-paw wish, I don’t see permanence as a worthwhile concern _in this specific context_.
This set-limited impermanence then points to a form of (distributed consensus based) reference counter solution, such that when any short-link’s counter falls to 0, it can safely be recycled. At that point, for safety you could even patch the contracts to utilize the full multihash or CID instead of the shortened version, just in case anyone wants to clone them in the future. At that point the cloners compile their own _new shortened links_, even preferentially recycling the old ones if they catch them in time. 😉
---
### Author:  [@fiatjaf](https://discuss.ipfs.tech/u/fiatjaf)
#### Post date: [January 11, 2018, 12:50am UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/13 "2018-01-11T00:50:13Z")
I still don’t understand. If you’re going to reference a mutable URL from the Solidity contract, why do you need IPFS?
---
### Author:  [@0zAND1z](https://discuss.ipfs.tech/u/0zAND1z)
#### Post date: [January 11, 2018, 8:07am UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/14 "2018-01-11T08:07:22Z")
This is certainly the beginning of a new thought for referring to stuffs on IPFS. Thanks!
---
### Author:  [@0zAND1z](https://discuss.ipfs.tech/u/0zAND1z)
#### Post date: [January 11, 2018, 8:10am UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/15 "2018-01-11T08:10:10Z")
Makes sense. But I think the URL Shortening utility is beyond twitter refs 🙂
---
### Author:  [@0zAND1z](https://discuss.ipfs.tech/u/0zAND1z)
#### Post date: [January 11, 2018, 8:18am UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/16 "2018-01-11T08:18:05Z")
So here’s the thing - IPFS is permanent web. It doesn’t necessarily limit the scope of the data to remain immutable as a stone.
A new line into the document creates a new IPFS hash. (At this point I request you to check the solution architecture for my problem here: [Ethereum/Solidity Smart Contract CI Toolchain on IPFS! (WIP)](https://discuss.ipfs.tech/t/ethereum-solidity-smart-contract-ci-toolchain-on-ipfs-wip/1780))
Atleast this is how I saw its working.
The reason behind choosing IPFS is because we are essentially looking for a distributed, open network.
---
### Author:  [@fiatjaf](https://discuss.ipfs.tech/u/fiatjaf)
#### Post date: [January 11, 2018, 10:43am UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/17 "2018-01-11T10:43:56Z")
I don’t understand your architecture or what exactly IPFS does there, the linked example is not available, apparently.
But here’s the point, again: IPFS is a distributed, open network. A URL shortener is not and will not be, it will be a single server with its own arbitrary rules. As such, the URL shortener can dissappear at any moment or change the shortened URLs to anything it wants. It doesn’t change anything if that URL shortener is in an [ipfs.io](http://ipfs.io) domain.
If you really want an URL shortener, you can create one, but it will not be different from bit.ly or whatever. It is not possible to include an URL shortener in the IPFS protocol.
You can host content on IPFS and then use your own URL shortener (or bit.ly or whatever) to shorten the IPFS URLs, but if you need a distributed, open network, you’re not going to have it anymore, as the URL shorteners will be not distributed nor open.
---
### Author:  [@0zAND1z](https://discuss.ipfs.tech/u/0zAND1z)
#### Post date: [January 11, 2018, 11:58am UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/18 "2018-01-11T11:58:07Z")
Noted. I’m already looking at the alternative measures… But thanks a lot for taking time and explaining! 👏
---
### Author:  [@0zAND1z](https://discuss.ipfs.tech/u/0zAND1z)
#### Post date: [January 11, 2018, 11:59am UTC](https://discuss.ipfs.tech/t/ipfs-url-shortener/1783/19 "2018-01-11T11:59:13Z")
> [@fiatjaf](#):
>
> the linked example is not available, apparently
IPNS not set to persist the hash object for more than 24 hrs (for now)