ord:// protocol and gateways

[0xGh]

This is a proposal to standardize a ord:// protocol that, similarly to IPFS, would allow to reference inscriptions by stable protocol URLs that are not bound to specific web2 gateways (eg. ordinals.com).

Like with IPFS, dApps would use gateways to access the actual resources.

The ord:// protocol would simply replace the gateway host (https://${location.host}/) while the standard endpoints would be unaltered.

Example:

ord://r/inscription/143170d5a2b8e29e3d26880ba3ef664e2268c022bac63b8658adf50f90fb17c9i0

Such a protocol would allow outside systems to recognize urls as inscriptions and handle them accordingly - for example enable Ethereum smart contracts to reference inscriptions.

[raphjaph]

That seems reasonable but I have no idea how to make this an official protocol URL

[0xGh]

Initially I thought it could be just a formalized standard / agreement and resolution is handled at the web2/dapp level

I would like to see if any Ethereum marketplace is willing to add support for this, perhaps even by simply special casing when metadata are on ordinals.com

make this an official protocol URL

I will look into this.

[0xGh]

I would like to see if any Ethereum marketplace is willing to add support for this

By the way if you or @casey have any connection at a marketplace it'd be nice to ask whether any of them would be willing to "pilot" this.

[casey]

I don't think that ord:// protocol URLs should contain arbitrary endpoint strings, i.e./inscription. /inscription is not a recursive endpoint and is subject to no backwards compatibility guarantees. I would suggest that all ord:// endpoints be recursive, and, before resolving them, r/ be appended to them. I.e., ord://inscription/ID correspond to /r/inscription/ID. To facilitate this, /r/contentcan be added as a alias for/content, so ord://content/ID` can return the content of an inscription.

[0xGh]

Absolutely! The example was wrong :) Fixed it.

Do you think it is worth introducing this convention (prepend r/ upon resolution)? or would it be better to be explicit?

[casey]

I think it would be better for it to be implied. If it's implied, and the r/ is prepended before resolving, then there is no way to construct a non-recursive ord: URI.