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.