add optional metadata for supports #272

New issue

Closed

opened 2019-05-08 18:16:18 +02:00 by BrannonKing · 2 comments

BrannonKing commented

2019-05-08 18:16:18 +02:00

(Migrated from github.com)

This is prototyped in the metadata_for_supports branch. This sample implementation doesn't require a hard-fork in the code, but it probably needs one to ensure that enough people get the change. If we could instead get the metadata into the witness section of the block, we may be able to make this usable without a hard fork. See #273

This is to enable options for advertisements and certifications and content reviews.

👍 1 👀 1 🎉 1

tzarebczan commented

2019-06-01 06:50:43 +02:00

(Migrated from github.com)

Any performance concerns as opposed to just doing the same with non winning claims that reference each other? Seems about the same to me.

Today supports cannot be updated, and supports can't support other supports. Any reason not to allow either or those, or it's just a matter of implementation? I could see use cases for both of those - updating a comment or review that's in the form of a support, and user's being able to support a comment / review. Any performance concerns as opposed to just doing the same with non winning claims that reference each other? Seems about the same to me.

BrannonKing commented

2019-06-03 16:00:34 +02:00

(Migrated from github.com)

@tzarebczan , we've had some discussion on adding what you suggest to supports. However, the current thinking is that if you want those features you should just use a claim.

Supports can be updated; spend and reacquire one. The update command simply ensures that the spend and reacquire happen in the same block, but the consequence of it overlapping a block boundary would typically go unnoticed.

@tzarebczan , we've had some discussion on adding what you suggest to supports. However, the current thinking is that if you want those features you should just use a claim. Supports can be updated; spend and reacquire one. The update command simply ensures that the spend and reacquire happen in the same block, but the consequence of it overlapping a block boundary would typically go unnoticed.

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/lbrycrd#272

No description provided.