new proto3 definitions

lyoshenka commented

2019-02-27 18:05:04 +01:00

(Migrated from github.com)

Final proto3 PR.

Closes #3, closes #16, closes #8, closes #13, closes #6, closes #17, closes lbryio/internal-issues#205.

Final proto3 PR. Closes #3, closes #16, closes #8, closes #13, closes #6, closes #17, closes lbryio/internal-issues#205.

lyoshenka commented

2019-02-27 18:08:53 +01:00

(Migrated from github.com)

One issue that was discussed a lot in #17 is urls vs claim ids. I stuck with urls for now because there are outstanding questions about claim ids. For example, if a thumbnail is at a claim with a fee, what do you do? Pay the fee? Not show the thumbnail? Ask the user? What if the fee is high? etc.

We can add thumbnail_claim_id later.

One issue that was discussed a lot in #17 is urls vs claim ids. I stuck with urls for now because there are outstanding questions about claim ids. For example, if a thumbnail is at a claim with a fee, what do you do? Pay the fee? Not show the thumbnail? Ask the user? What if the fee is high? etc. We can add `thumbnail_claim_id` later.

eukreign commented

2019-02-27 18:14:33 +01:00

(Migrated from github.com)

"For example, if a thumbnail is at a claim with a fee, what do you do? Pay the fee? Not show the thumbnail? Ask the user? What if the fee is high? etc."
Show broken/missing icon placeholder.

_"For example, if a thumbnail is at a claim with a fee, what do you do? Pay the fee? Not show the thumbnail? Ask the user? What if the fee is high? etc."_ Show broken/missing icon placeholder.

lyoshenka commented

2019-02-27 18:18:14 +01:00

(Migrated from github.com)

what if its 0.0000001 LBC for the thumbnail?

eukreign commented

2019-02-27 18:23:34 +01:00

(Migrated from github.com)

What's the use case? Why would it make sense to charge people to show a thumbnail?

I think if it requires payment it's a broken/invalid thumbnail.

What's the use case? Why would it make sense to charge people to show a thumbnail? I think if it requires payment it's a broken/invalid thumbnail.

eukreign commented

2019-02-27 18:32:38 +01:00

(Migrated from github.com)

@lyoshenka I would like to reiterate the two things I still think would be really good to add/change:

Drop the Claim container type, if you have to do a check on what type of claim it is anyways then the same check can be done when extracting the protobuf data from the claim transaction. Having a claim (protobuf type) within a claim (tx) seems like an extraneous layer of indirection.
Once we start requiring identities for users in order to participate in commenting and possibly other activities on the LBRY network it's likely that these identity certificates will significantly outpace the number of channels. If Certificate is not desirable name, can we at least change channel to identity if 90% of these types of claims will be user identity certificates? Referring to user identities as channels just seems weird.

@lyoshenka I would like to reiterate the two things I still think would be really good to add/change: 1. Drop the `Claim` container type, if you have to do a check on what type of claim it is anyways then the same check can be done when extracting the protobuf data from the claim transaction. Having a claim (protobuf type) within a claim (tx) seems like an extraneous layer of indirection. 2. Once we start requiring `identities` for users in order to participate in commenting and possibly other activities on the LBRY network it's likely that these `identity` certificates will significantly outpace the number of `channels`. If `Certificate` is not desirable name, can we at least change `channel` to `identity` if 90% of these types of claims will be user identity certificates? Referring to user identities as `channels` just seems weird.

kauffj commented

2019-02-27 18:37:45 +01:00

(Migrated from github.com)

@lyoshenka I proposed that for images we use either stream hashes or blob hashes, not claim ids. How often are images larger than 2MB, and do we want to support > 2MB images anyway? If not, blob hash works fine and doesn't require blockchain bloat for additional claims.

eukreign commented

2019-02-27 18:42:20 +01:00

(Migrated from github.com)

@kauffj A downside of not having a claim for the thumbnail is that when blob hosts want to purge invalid / abandoned blobs the method to figure out which blobs are still valid and which aren't would be more complicated: You can't just say "only keep blobs which are represented by valid calims on the blockchain" now you have to separately search for blob hashes in the metadata. The other downside is blob size but you could probably point to an sd_blob and therefore not have blob size limitation.

On the positive side:

it's measurably faster
eliminates the situation where someone tries to charge for thumbnail

@kauffj A downside of not having a `claim` for the thumbnail is that when blob hosts want to purge invalid / abandoned blobs the method to figure out which blobs are still valid and which aren't would be more complicated: You can't just say "only keep blobs which are represented by valid calims on the blockchain" now you have to separately search for blob hashes in the metadata. The other downside is blob size but you could probably point to an sd_blob and therefore not have blob size limitation. On the positive side: 1. it's measurably faster 2. eliminates the situation where someone tries to charge for thumbnail

kauffj commented

2019-02-27 20:54:37 +01:00

(Migrated from github.com)

@eukreign fair point. Two further comments:

It's not trivial to identify which blobs appear in valid claims. To do this, one must fetching all stream descriptor blobs. This seems as or more complicated than checking which blobs appear in the blockchain.
I suspect blob retention will probably eventually be done by comparing access rates with hosting density, rather than simply trying to host everything.

@eukreign fair point. Two further comments: 1) It's not trivial to identify which blobs appear in valid claims. To do this, one must fetching all stream descriptor blobs. This seems as or more complicated than checking which blobs appear in the blockchain. 2) I suspect blob retention will probably eventually be done by comparing access rates with hosting density, rather than simply trying to host everything.

new proto3 definitions #21