reposts with edits (aka third-party metadata)

[lyoshenka]

Problem

• I'd like to repost someone's claim using a newer schema that has additional fields, and I want to fill in those fields for the reposted claim
• I'd like to repost a claim while changing some of the fields
• I'd like to repost a claim while adding or removing some tags

Proposed solution

Add two new fields to ClaimReference as follows

message ClaimReference {
    bytes claim_hash = 1;
    optional Claim deletions = 2;
    optional Claim edits = 3;
}

edits and deletions are used to change parts of the referenced claim.

• if deletions includes a field that is not in the referenced claim, ignore it
• if deletions includes a repeated field that is in the reference claim, then any values in deletions should be removed from the referenced claim
• if deletions includes a non-repeated field that is in the reference claim, delete those fields from that claim (the value in the deleted field does not matter. it can be anything except the default value for that field)
• if edits includes fields that the referenced claim does not include, or if it includes repeated fields, treat them as added to the claim
• if edits includes non-repeated fields that are also in the referenced claim, treat them as overwriting the existing fields

Deletions must be applied first, and edits applied after.

The type of the deletions and edits Claims must match the type of the claim that is referenced. if it does not match, the edits will not make sense and downstream apps may ignore them or even ignore the claim as a whole.

Downstream apps should make clear to users which values come from the underlying claim and which come from edits/deletions.

If a referenced claim is updated after it is referenced, the values in deletions and edits may no longer make sense. Downstream apps should highlight to the user any fields that were updated in the referenced claim after being edited/deleted.

Outstanding Questions

• What to do if the referenced claim is updated to change the claim type? This gives the original claim's owner a way to "remove" the edits of the repost while still being reposted.

Corner Cases

• Claim A points to a 3-minute-long video, but the duration in the claim is set to 5 minutes
• I repost claim A and fix the duration to be 3 minutes using the edits field
• The owner of claim A updates it to point to a longer video which is 6 minutes long. They set the duration in the metadata to 6 minutes (which is now correct for the new video)
• My repost still has a duration of 3 minutes, which is now wrong

[jackrobison]

In addition to the claim hash, if ClaimReference also has claim_tx_hash and claim_tx_nout fields some of these corner cases can be handled better. This would allow applying the change set onto the claim that was reposted and then considering any new changes since the repost was made.

[eukreign]

In addition to the claim hash, if ClaimReference also has claim_tx_hash and claim_tx_nout fields some of these corner cases can be handled better. This would allow applying the change set onto the claim that was reposted and then considering any new changes since the repost was made.

I believe this would be redundant since you can use the time of the repost itself to determine the order the changes should be applied. In other words, you can compute the claim_tx_hash and claim_tx_nout dynamically without using precious blockchain space.

[defdistadmin]

Howdy guys - how are things going with this issue? Is it being actively worked on?

[kauffj]

@moodyjon to investigate this approach with eye to become owner of this issue

[moodyjon]

https://github.com/lbryio/types/search?q=ClaimReference

ClaimReference also appears as a member of ClaimList, so the effect of adding deletions, edits to ClaimReference may be overly broad. Would it be preferred instead to say that only reposts can have edits? And to get edits into a ClaimList, you have to repost first, then include the repost in your collection?

[moodyjon]

I've been working on _inflate_outputs() in lbry-sdk. That's where one could apply deletions/edits before outputting a search/resolve result.

https://github.com/lbryio/lbry-sdk/blob/a7d7efecc7aa8aa5ef666b16358ad1b2066e8eb1/lbry/wallet/ledger.py#L786

In lbry-sdk, jsonrpc_stream_update() calls Claim.update(**kwargs) to do its work. Generating a ClaimReference with deletions/edits would be a method override specific to Repost.

Finally, if the reposted edited fields are to be searchable, prepare_claim_metadata_batch()' should apply the edits similar to how _inflate_outputs()` does so.

https://github.com/lbryio/hub/blob/34c5ab2e56c8f3234ac068ec0f40ac339a3f8708/hub/elastic_sync/db.py#L30