Proposed Simple Standard For Asset Metadata Viewing In RVN QT

[MangoFarmAssets]

Any number of standards can be used for IPFS files as metadata attached to a Ravencoin asset. Examples include Tron Black's metadata specification, RIP-0014, and RealBokito's Extended Metadata Specification.

Attempting to standardize the metadata structure can end up with specs that are over- or under-inclusive. This creates issues when viewing asset metadata on platforms that are not the platform of original issuance, including the Ravencoin QT and mobile wallets.

For example, the asset "Dave Coin" was created with the RIP14 standard. When viewed with a click on the DAVE COIN asset in the RVN QT, it appears like this in the Cloudflare Gateway.

On the Ravencoin asset explorer by Scotty, it appears like this.

And on the Mango Farm site, it is parsed as it was intended to be viewed at the time of issuance:

During developer meetings, it was suggested that one solution is to allow users the ability to select their viewer in the RVN QT, to allow them to switch from, e.g., Cloudflare's gateway to another viewer, either persistently or on a document-by-document basis.

One other possible solution, which this Issue proposes, is to standardize a simple JSON for asset building that contains a reference to both the IPFS hash and the viewing resource intended to be the place to view that hash.

For example, imagine a Ravencoin asset is issued with the following IPFS hash associated with it:

Qmdtue71rUF756P1Zy8LK5Ybmyf8qAFqvBRfBBsZmTR1pf

That file would contain a simple JSON with two key-value pairs: one identifying the metadata for the asset, and the other identifying the viewer that the issuer optimized for viewing that metadata, in this case:

{ "IPFS_hash": "QmZhXnFTgrF866rPutvdPEE5eQh8PJS9AphfawMdoseNhW", "IPFS_viewer": "https://gateway.rickdemontart.com/ipfs/" }

The IPFS_hash in the above-referenced JSON contains a file formatted in the issuer's own metadata specification, viewable here.

Using this structure would allow any RVN asset to be created with any metadata structure, whether standardized or not, and facilitate the viewing of that asset as the issuer intended from the QT wallet or any other wallet set up to parse this simple JSON and open a browser.

The end result using the above-example would be a file that opens from the QT looking like this:

As opposed to the current system, which opens the file like this.

This could add value system-wide, because issuers would no longer need to use bespoke wallets in order to view RVN assets created and issued with their own standard. All they would need to do is create bespoke viewers, and their assets would be viewed as intended straight from the QT or other wallets that incorporate this standard.

Because this would require changes to the QT, we have set this out in an Issue for further discussion and consideration, rather than in a RIP.

[hans-schmidt]

The changes needed in raven-qt to enable this improved functionality could be made simply and safely. Currently, raven-qt launches the IPFS attachment using an IPFS gateway URL. That URL is stored as a raven-qt parameter in the registry for Windows or in the Raven-Qt.conf file for Linux. That URL could be replaced with a call to an external helper application which parses JSON and decides how to most appropriately display any contents. The ability to change that URL setting to a "helper app" could be easily added to raven-qt (although the setting could also be changed manually). For security, when raven-qt starts up, it should check the config file for the "helper app" which may have changed relative to the default, and give the option to proceed or reset to default. That way the "helper app" could be selected and updated independent of qt, and qt would notify of the security risks.

[TronBlack]

We originally talked about having a content viewer inside QT, but the decentralized and uncontrolled nature of the content that could be included in an IPFS file meant it could be a problem for the GUI if it showed "illegal in some jurisdictions" PDFs, JPGs, etc without a click.

I like this idea. It does require the qt to request IPFS content, so this part would need to only request the IPFS after a user clicks. And then strictly check. The first byte would need to be '{'. IPFS JSON not over X bytes (1024?). Request only 1024 bytes and no more. Check for properly formatted JSON, check for the two key values. Make sure the IPFS is properly formatted and decodable. Check for a properly formatted URL. If any check fails, then default back to what it does now -- which would display the incorrectly formatted JSON.

I have concerns about a helper app (binary) in a crypto wallet, especially one that parses automatically distributed and unrequested user data (metadata). Browsers are battle-tested and sandboxed. A popular helper app would be a valuable target.

This does not require a consensus change but does have security implications because it could be a target. Since an automatic redirect can be done already to any website, adding a web-based user-defined viewer only slightly increases the attack surface. I'd recommend not automatically showing anything -- a click should be required.

[MangoFarmAssets]

+1 for the size/JSON structure checks and the click requirement.

[TronBlack]

amount=USD$300.00 paid_in=RVN status=open info=https://github.com/RavencoinFoundation/gitRVN

[mrsubtle]

I love this. I'd love to see one more property that should be added as optional and restricted in length (if possible). { "IPFS_hash": "QmZhXnFTgrF866rPutvdPEE5eQh8PJS9AphfawMdoseNhW", "IPFS_viewer": "https://gateway.rickdemontart.com/ipfs/", "IPFS_viewer_cta": "View on rickdemontart.com" } This would allow the content creator to customize the label of the button used to launch the content. Or some equivalent thereof.