Off-chain content

[casey]

Should we support off-chain content?

Pros:

• Cheaper to make inscriptions
• Possible to link to very large content

Cons:

• Increases confusion for users. Some inscriptions would have content on chain which would be nearly guaranteed not to be lost, whereas others would be off chain and would rely on economic incentives of inscription holders.
• Lots of complexity: Which hash function? Should we support arbitrary URLs? How store?

SHA-256, BLAKE3, or BitTorrent V2 file merkle root. If BitTorrent V2, will also need content length

[lingmann]

If you decided to support off-chain content, it's probably worth looking at the CID Specification. They have spent some time thinking about hash functions, codecs, etc. and it is being used by Bluesky (AT Protocol) as well as IPFS.

[batcavekid]

I think the answer depends on what you want to maximize for the ecosystem, including but not limited to:

• quality of art
• number of artists and collectors
• total value transacted (primary and secondary sales of inscriptions)
• fees paid to miners

I think on-chain only is best (at least for now)

• Clear, simple, permanent
• Higher cost of on-chain storage creates scarcity, encourages quality, discourages spam
• a smaller, more technical user base might be an advantage in the early stages of the ecosystem
• Multi-file inscriptions, with html/js links, with on-chain libraries, are powerful
• It's a cool constraint
• disadvantage: it might tend to reduce total value transacted, and fees paid to miners (making some assumptions)

The vast majority of off-chain NFTs on other ecosystems are extremely low quality. I believe the best artists and projects would have found a way to inscribe at higher cost if they had to, and some of those started out as off-chain but later moved on-chain. Over time, many of the links will break (and many already have), leaving the owner with an empty token.

Advantages of off-chain:

• Large files is a clear advantage, some great art requires huge files
• I assume it would increase total value transacted (for inscription trades) and fees paid to miners
• Off-chain is more inclusive and less plutocratic (more artists, more inscriptions and collectors)

[mullojo]

Seems smart to keep the main chain as light as possible for long term success. IPFS is a very attractive solution for off-chain data storage.

[casey]

Not to sound harsh, but I've looked at and worked with IPFS, and is complex and poorly-designed. BitTorrent V2 is a much better, simpler, sounder protocol.

Requirements for any off-chain storage:

• Content must be referenced with a standard hash function digest that is not protocol specific. SHA-256 is attractive, because it does not introduce any new security assumptions, since Bitcoin already relies on SHA-256. BitTorrent V2's SHA-256 merkle tree is nonstandard, but is so simple that I'll give it a pass. BLAKE3 is attractive for its extremely fast hashing, but it introduces a new security assumption, that BLAKE3 is secure. IPFS multihashes are eliminated by this requirement, because they are linked to that specific protocol, in addition to additional issues with IPFS.

• It must be possible to inform the user of the health of content stored off chain. How many copies are there? Are they complete? This can only be accomplished by actually attempting to fetch random chunks of the content. The approach of torrent sites is reasonable here, we could display seeders and leachers. Fetching random chunks of the content eliminates IPFS again, because the protocol is so complex that we cannot implement ourselves, and it's such a heavy dependency that we wouldn't want to pull it in.

• It must be easy for users to download content that they care about, and serve it for other users. "Easy" in this case doesn't mean that the user can do it, but it requires multiple manual steps and additional software. Users must be able to automatically, using the software they already have installed, namely ord, fetch, store, and replicate off-chain content. Ord should do this automatically for any content in their wallet. Privacy considerations mean that this may need to be done over an anonymity network, to avoid doxing the IP of ord users.

[mullojo]

Have you seen this rust implementation? https://github.com/n0-computer/iroh

[lingmann]

@casey would agree with the goal of keeping the protocol spec super simple and not relying on an external system like IPFS. I was just mentioning the CID spec because it might be useful for comparing & contrasting different approaches taken towards hashing, metadata, content-type, etc. Of course you also want to avoid biasing your design, so probably a good idea to come up with your own ideas first and then compare. :) Great project btw, and congrats on the mainnet launch!

[casey]

@mullojo I haven't, but good to know about! There are some issues with IPFS that an implementation might not be able to fix, for example this, which is caused by IPFS chunking content and advertising each individual chunk in the DHT.

[casey]

Great project btw, and congrats on the mainnet launch!

@lingmann thank you!

[wagmiwiz]

IMO supporting a generic "url" media type would go a long way. It's up to the clients to then decide how they show or tag such content. And it is up to the inscribers to decide when it may make sense.

For example, if I wanted to inscribe a link to a YouTube video then I should be able to (as silly as it may sound). Clients can flag it as "external content" and unfurl/embed. The url can then be ipfs, arweave, torrent or whatever.

One could just embed a link already by using a text media type but having a more dedicted type may help to make it more explicit that the content is external.

[nammaki]

Please add support for off-chain content 🙏

[spzjulien]

for me the off-chain would be good for hd quality of the onchain version, so both at same time on one ordinal
some of my ordinal are 30-60kb and i have them in 1-2mb, some of my holder ask me better quality for print in and put on the wall
https://twitter.com/wtf_pd/status/1659574384103702530

i see off-chain like good option, but not sure if off-chain only will be popular

[tyjvazum]

@spzjulien, I agree, that's why it's optional with arb.

[casey]

I think off-chain content isn't something that's likely to be supported in the near term.