LBRYCommunity/types

Fork 0

reposts with edits (aka third-party metadata) #49

New issue

Open

opened 2022-08-11 16:37:29 +02:00 by lyoshenka · 6 comments

lyoshenka commented

2022-08-11 16:37:29 +02:00

(Migrated from github.com)

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

## 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 ```proto 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

👍 1

jackrobison commented

2022-08-12 16:19:32 +02:00

(Migrated from github.com)

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.

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 commented

2022-08-12 16:33:29 +02:00

(Migrated from github.com)

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.

> 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.

👍 1

defdistadmin commented

2022-09-19 23:09:36 +02:00

(Migrated from github.com)

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

kauffj commented

2022-10-03 17:41:03 +02:00

(Migrated from github.com)

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

moodyjon commented

2022-10-04 16:51:45 +02:00

(Migrated from github.com)

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?

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 commented

2022-10-10 22:22:24 +02:00

(Migrated from github.com)

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.

34c5ab2e56/hub/elastic_sync/db.py (L30)

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

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/types#49

No description provided.