claim resources feature proposal

This is a proposal for adding secondary content (resources) to claims such as images in a markdown claim, subtitles for a video claim and any other kind of supporting data to the claims primary content.

Addressing of the content and storage of the content are the two main issues that need to be tackled.

Protobuf

below this line: https://github.com/lbryio/types/blob/master/v2/proto/claim.proto#L14 add: repeated Source resources = 14; done.

Addressing

syntax: lbry://[current-lbry-url-scheme]~[resource-name]:[resource-blob-hash]

URLs that have ~ return the raw bytes of the content.

Examples:

URL	Description
lbry://one	resolve claim one and return the JSON / HTML representing the claim (this is how it works now)
lbry://one~	resolve claim, then return the primary claim payload bytes (eg, like opening a plain image file in browser)
lbry://one~thumbnail	resolve claim, then if an explicit thumbnail is defined in protobuf then that payload is returned, otherwise it will lookup thumbnail in claim resources and return that
lbry://one~foo	resolve claim, then lookup foo in resources and return payload
lbry://~foo	a “relative” version of previous URL can be used from within the claim primary content (eg. markdown), a LBRY “browser” app rendering the primary content would have to rewrite the URL to add the missing claim or pass some kind of context value along with the request providing info to the SDK of what this URL is relative to
lbry://one:beef~foo:abc123	resolve claim, then lookup a resource in resources which has both the matching name and the matching blob hash
lbry://one:beef~:abc123	same as above but only match on blob hash

Implementation Details

1. To maintain consistent API response types the current resolve command should not change it’s return type. If you pass a resource URL to resolve it will ignore the resource part and just return the claim.
2. The existing get command will be used to retrieve the resources.
3. When “browser” app converts markdown to HTML it would also convert all of the lbry:// urls with ~ in them to something like (assuming lbrynet API is running on localhost:123): http://localhost:123/get?url=one~foo:abc123.
4. If you call get with a URL that doesn’t have ~ it will assume you want the primary content (current implementation already).
5. Therefore: lbry://one~two and lbry://one both return the same claim JSON when URL is passed to resolve endpoint; lbry://one~two and lbry://one would return different resources when passed to get command, resource named two for first URL and the primary claim payload for second URL.

[lyoshenka]

from allhands discussion

[lyoshenka]

ideally yes.

another use case is preview thumbnails https://github.com/lbryio/lbry-desktop/issues/6169