I’d like to create an assest that links to an IPFS database. However the IPFS link is longer than the URL character limit. Is there a way around this? I could use an URL shortener (like bit.ly) but that adds a point of failure, so I’d like to avoid that if possible.
Alternatively, I considered using the IPFS CID as the ASA name and link to the host, but again the CID is longer than the maximum asset name length…
The CID is 45 characters long.
I agree, the URL length needs significantly expanded. The metadata hash field should be expanded as well.
Hi - there does not seem to be a perfect approach to this - at least that we’re aware of. At dahai.uk we write the IPFS uri into the note field of the asset when it is created like this: ipfs://gsdfgsdfsdfgsdfgdfgsdfwhatever/
We then take a 32 byte hash of this string and put that into the metadata hash field. Whilst it is possible to change the note field, the hash ensures that the holder knows if it has been modified.
Not a perfect approach, and would love to hear of alternatives.
Hi Meltie,
Thanks for the input. I was considering something similair (add the IPFs CID / gateway to the minting transaction note), but I was unaware this note could be changed. I will do as you suggest and add the hash as well.
It seems the best solution would be to increase the hash limit to 46 so the IPFS CID can be listed there directly (and then use the URL to reference the gateway). But I’m unsure if this is technically feasible or how we’d go about officially proposing it?
I could easily be wrong about the note being changeable… I think I made an assumption about that so its worth checking. If it is not changeable then no-need for the hash I guess.
Another way is to split the hash into two and place the first part in the URL and the second part in the metadata hash… but urgh.
As to proposing the change, maybe chatting with algorand on discord is a good place to start?
The note is not changeable. On future transactions you could put different notes in, but once a note is in the blockchain, it is forever. Also we are looking at changing the limit in the field.
That would be great — where is that discussion happening?
You could weigh in here: TEAL 4 Epic · Issue #1950 · algorand/go-algorand · GitHub
But honestly, there isn’t a lot of nuance to this particular conversation - I think everyone has come to realize that 32 bytes is too small. The current intention is to expand the limit to 96 bytes. That seems to allow a bit of breathing room beyond the hashes that are commonly used on ipfs.
Sounds like a great idea 
Hi everyone, how about converting IPFS CID to 32 bytes strings that fit both metadatahash and url fields (although on 2.7.1 URL is extended to 96 bytes)?!
ipfs2bytes32 GitHub repository
ONLINE DEMO
In more complex scenarios URL (96 bytes since 2.7.1) can hold ASA service endpoints which are actually URls and metadatahash field can hold onto IPFS CID (which can be converted to 32 bytes and fits now).
Just for information for people reading this post later, there is a proposal draft (not finalized yet when this answer is written) of how to create fungible and non-fungible tokens on Algorand: ARCs/arc-0003.md at main · algorandfoundation/ARCs · GitHub