drop the ipfs-centric BCMR OP_RETURN form

[A60AB5450353F40E]

It introduces a dependency. We can get rid of dependency at the cost of some redundancy, but the benefit is a consistent method of validating the .json.

Propose only 1 form:

OP_RETURN <'BCMR'> <sha256(content)> <content_uri>

And if there's no uri: prefix, then infer https://. This way we can support any current and future content delivery protocol.

Examples:

OP_RETURN <'BCMR'> <sha256(content)> <'ipfs://bafybeibdkyv3mly2rxxeqiydl5ntbmvqlbghd2cwjgyjmeiuo73ctjgf2y'>

OP_RETURN <'BCMR'> <sha256(content)> <'https://my.registry/registry.json'>

OP_RETURN <'BCMR'> <sha256(content)> <'magnet:?xt=urn:btih:ABC123...321CBA'>

If wallets don't want IPFS dependencies, this way they could just use some https gateway, and they'd know it isn't lying to them because they also have the sha256. Those that do want IPFS could fetch it directly because the ipfs:// uri encodes the CID, of whatever version.

This way, clients can obtain the content from anywhere, or consistently query other clients for content by the sha256(content). The last push can be thought of as a hint of where to find one copy, while it could actually be mirrored in many places, and the sha256 would be a consistent way of checking you got the right content.

[A60AB5450353F40E]

Hell we could even solve #9 as it could fit into some custom uri scheme like:

OP_RETURN <'BCMR'> <sha256(deterministically_generated_json)> <'slpmeta:cashAddrMeta?hash=doc_hash&url=doc_url'>

where cashAddrMeta would be a binary serialization of <NAME> <TICKER_SYMBOL> <DECIMALS> encoded using our familiar cashaddr standard.

Then, wallets & bundlers could use the so broadcast data to deterministically construct a BCMR .json and verify it against the sha256

[cculianu]

Well after talking to Jason about it on the phone -- he convinced me it's a good idea to have the data that wallets show to users be a be a "negotiation" between creators of tokens and wallets and registry providers.. in that light.. just taking verbatim what someone put on-chain seems like it's not as important as it once was in my mind..

Like there are competing interests here -- creators of tokens may want to spam whatever to a wallet.

Wallet maintainers may not want whatever to necessarily be shown to users.

It's a negotiation between sometimes diverging incentinves..

In that light, perhaps, then I am not as eager to see these data fields naked on the blockchain as I once was. I realize now that anyway this data needs curation and if you do curation, then the super-convenience appeal of having it all on-chain becomes less important.

[bitjson]

Thanks for opening the issue @A60AB5450353F40E! (And thanks @mr-zwets, @zander, @jonas-lundqvist, @cculianu, @joemarct, and @mainnet-pat for the discussion on Telegram.) Yes, I agree. 💯

We don't want to force clients to understand IPFS CIDv1s to validate what they get back from HTTPs gateways. That alone would be worth the few bytes efficiency loss (and these transactions aren't ever going to be a huge percentage of on-chain traffic vs. payments and contract interactions, so over-optimizing here doesn't pay).

We're essentially taking the tradeoff of some extra bytes for interoperable, utf8 encoding of URIs. It's also great that this creates a clear, "right way" to add other protocols like magnet. 🚀

Should we also formalize how outputs could provide multiple download options? Since this format separates the hash from the transport, we could allow for multiple transport options to be provided. Clients can just use their preferred strategy, and each resolves to the same verifiably authentic file.

So:

OP_RETURN <'BCMR'> <sha256(content)> <'magnet:?xt=urn:btih:ABC123...321CBA'> <'wkhpil...x5tfyd.onion'> <'example.com'>

Clients that can use other protocols might prefer to do so, e.g. if they have trusted magnet peers or tor support and don't want to leak their download to a service.

Note we're able to omit both https:// and /.well-known/bitcoin-cash-metadata-registry.json for both of the HTTP URIs above. We should really push for publishers to use the Well-Known URI, that's the only reliable way for clients to associate trust in the domain name with the registry itself; tons of websites allow users to upload JSON files, so registries found at any other path can't inherit the user's trust in the top-level domain (an example of an ecosystem that handled this poorly was web cookies: lots of browser have ended up with complex, domain specific rules for websites with user generated content because "trust transfer" wasn't formally specified).

TLDR: lets avoid the /.../*.json in usage examples, the types of registries being pulled from OP_RETURNs by most clients should have their own domain.

And a final question – can someone figure out if supporting clients could theoretically compute an IPFS URI from the sha256 hash of a single, registry JSON file? (Maybe @SahidMiller knows?)

Seems like it may be possible, but I haven't gotten to review and verify. I think the question is whether or not IPFS can support content-addressing of a json file rather than requiring it be packed in their CAR format and/or compute a deterministic, single-file CAR given a sha256 hash. If so, it would be possible for some publication outputs to only push the hash (no URIs), and supporting clients could encode that hash into a CID and fetch via IPFS (or similar networks).

[mr-zwets]

Great discussion, I like the proposed solution a lot.

Should we also formalize how outputs could provide multiple download options?

I think that would be ideal! Otherwise I don't see people adding lesser supported transport options like magnet or tor.

[cculianu]

Yeah supporting multiple pushes (and the wallet software or whomever has to figure out what the payloads mean according to some standards) seems like good future-proofing...

[mainnet-pat]

OP_RETURN <'BCMR'> <sha256(content)> <'magnet:?xt=urn:btih:ABC123...321CBA'> <'wkhpil...x5tfyd.onion'> <'example.com'>

mainnet-js 1.1.20 adds support for multiple uris in a BCMR output

[zquestz]

Just to chime in. I support having just one syntax, and always requiring the sha256 hash plus at least one URI to the content.

[bitjson]

Hey y'all, please have a look at #11 to see if I've resolved this fully. The hash is now the same for all publication outputs, and zero or more utf8-encoded URIs are pushed after the hash. I also clarified the examples a bit and removed references to percent-encoding HTTPS URIs (wasn't necessary and wasted bytes).

[mr-zwets]

Great!!
I like the clarification of when an on-chain posted https-url is assumed to conform to the well-known uri scheme and when not.
I don't see any changes you lade to the examples?

[bitjson]

Ah sorry, that's what I meant – I clarified the in-line e.g.s, no changes to the examples folder.

Ok, I'll go ahead and merge this later today if no one has any further feedback 🚀