claim resources feature proposal
Open
@lyoshenka is already working on this.
Since Apr 5, 2021.
- Dominant language
- Python
- Stars
- 7.2k
- Forks
- 493
- PR merge metrics
- No merged PRs in 30d
Description
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
- To maintain consistent API response types the current
resolvecommand 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. - The existing
getcommand will be used to retrieve the resources. - When "browser" app converts markdown to HTML it would also convert all of the
lbry://urls with~in them to something like (assuminglbrynetAPI is running onlocalhost:123):http://localhost:123/get?url=one~foo:abc123. - If you call
getwith a URL that doesn't have~it will assume you want the primary content (current implementation already). - Therefore:
lbry://one~twoandlbry://oneboth return the same claim JSON when URL is passed toresolveendpoint;lbry://one~twoandlbry://onewould return different resources when passed togetcommand, resource namedtwofor first URL and the primary claim payload for second URL.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.