[WIP] proto3 proposal #17
Labels
No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
consider soon
Epic
good first issue
hacktoberfest
help wanted
icebox
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
priority: blocker
priority: high
priority: low
priority: medium
resilience
Tom's Wishlist
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/types#17
Loading…
Reference in a new issue
No description provided.
Delete branch "proto3"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
My proposed schema changes. this is very much WIP. I just wanted to see what it might look like and get your opinions on it.
Goals:
Keep in mind that in proto3, every field is optional. Also keep in mind that I'm trying to match this stuff to https://spec.lbry.io/#specification (e.g. Stream.hash vs Stream.sd_hash)
When you look at the field numbers, anything numbered 1-15 means we think that field will be set in most claims. Numbers 16+ means we think that field will not be set in most claims. There's no functional difference other than a small space savings if we predict it correctly.
I think the biggest questions are about the structure of the
stream.protofile.Closes #3, closes #16, closes #8, closes #13, closes #6, closes lbryio/internal-issues#205.
Some comments, but I'm pretty much a protobuf idiot.
Do we need this?
It does seem like this could be inferred, though I could also see the metadata switching on type, which might be a reason to keep it?
This seems very safe to include in the top 15, I think.
If this is metadata 2.0 this should be fixed/expanded, or simply moved into a tag.
What is this?
@ -17,0 +20,4 @@string thumbnail_url = 18;uint32 duration = 19;repeated string tags = 20;int64 release_time = 21; // seconds since UNIX epochthis field should die entirely
Is there anything else I should do to test or run this? We also have a semi-long list of fields to add. Would it make sense to add those before merging in case some should go in the top 15?
putting this here so i don't forget: https://github.com/lbryio/types/issues/8
related: https://github.com/lbryio/types/issues/15
@kauffj yes, link any fields that need to be added here. i found a few PRs but not sure i got em all
@ -17,0 +20,4 @@string thumbnail_url = 18;uint32 duration = 19;repeated string tags = 20;int64 release_time = 21; // seconds since UNIX epochshould it be changed to creator? if im publishing public-domain work that i did not create, how do i note that?
@ -17,0 +20,4 @@string thumbnail_url = 18;uint32 duration = 19;repeated string tags = 20;int64 release_time = 21; // seconds since UNIX epochFair, something like this probably needs to exist. But if we're supporting that kind of thing we'd still want that to be a first-class entity (at some point, we're obviously not too close to that).
I'd recommend keeping this out of the 15 because I do not think a single plain text field will be the ultimate solution for how distinguishing authorship.
great, maybe make a backup of the current one like
/proto_legacy/? The current proto2 one is still needed for decoding claims.i actually don't know. we have it today
Questions re: channel metadata
usernameanddisplay name?coverandthumbnailbe web URLs or LBRY URLs or claim IDs?@ -0,0 +8,4 @@string description = 3;string thumbnail_url = 4; // url or claim ID?string cover_url = 5; // url or claim ID?}we may want a short description, limited to a reasonable number of characters and no markup, as well as an unbounded (well, bounded by claim size) field that would be shown on the full profile view
whatever is determined by https://github.com/lbryio/lbry/issues/1842
it may be better to have them directly as blob or stream hashes?
Question for reviewers:
content height/length and orientation would be helpful for spee.ch and other apps too - see https://github.com/lbryio/spee.ch/issues/435 / https://github.com/lbryio/spee.ch/issues/527. We wouldn't have to run ffmpeg on new files anymore...
@ -0,0 +8,4 @@string description = 3;string thumbnail_url = 4; // url or claim ID?string cover_url = 5; // url or claim ID?}regarding: https://github.com/lbryio/types/pull/17#issuecomment-463418314 - I think Name could be the channels real name, or whatever they want to nickname their channel...i.e. my channel is @iloveLBRY, but the name would be "I Love LBRY!"
How does everyone feel about adding some of my other suggestions from https://github.com/lbryio/types/issues/8 -at least Language (and/or Location? - that's what YT has) and Featured Video (lbry URL/claimid).
Can tags have a "type" property the way it's defined currently? i.e. Category/topic/genre/other/etc.
@ -0,0 +8,4 @@string description = 3;string thumbnail_url = 4; // url or claim ID?string cover_url = 5; // url or claim ID?}coverandthumbnailbe web URLs or LBRY URLs or claim IDs? - I think this should be similar to our current thumbnail system, and if we decide to support LBRY urls/hashes there, then we should here too. For now, http urls / spee.ch links should work fine.i'm not sure what you mean. can you give me some examples?
What about a
website/contactfield? Most sites have something for you to add your email address or link to a website. I'm not sure if both would be valuable, or if you could just merge it into one field.Per the discussion this afternoon, this would pose UX challenges when users tagged content.
The idea was that a top level tag might be bound to some type, i.e. category, with predefined values. Then users could easily reference the category tag when searching/selecting based on tags, as opposed to more generic tags.
👍 on adding both a website and an email field to channels @lyoshenka
Question Responses:
nameis the display name. Slightly less ambigious (not sure by how much) might be to usetitleinsead ofname, but I thinknameis fine too.coverandthumbnailshould be claim IDsFeedback:
floatfor the Fee is a bad idea. It should be an integer and then the precision is 2 decimals for fiat currencies (USD) and 8 decimals for crypto currencies (LBC/BTC). ($1USD would be 100 and 1LBC would be 100000000).New Questions:
Channelmake sense for certificates if we're planning to also use them for a users identity? I think the oldCertificateis more generic when applying to both channels and identities.Claimcontainer type withChannelandStreaminside of it, can we just haveChannelandStreamas root containers (and get rid ofClaim)? (And perhaps add other root objects likeCommentin the future?)I don't think I should have to download thumbnails/covers over DHT, unless the long term plan is to allow that for claim thumnails as well (https://github.com/lbryio/lbry/issues/1842)
I agree. I do not think thumbnail/cover should be a claim id.
I can see a case where it is a url or a claim id (or something else), but since thumbnail is already a url for a claim, this should follow the same behavior.
per @lyoshenka, we should add these under a dimensions subfield
@seanyesmunt note that as long as we encourage usage of spee.ch for images, we are encouraging thumbnail/cover to be a claim id just with extra steps ;)
Another feature that just struck me as missing is creator identity verification (where verification equals proving I own a certain Twitter account, YouTube account, domain name, or ??). You would prove you own relevant property by issuing a tweet, publishing a video, adding a DNS entry / uploading a file, etc.
This is more complicated than basically everything else we're proposing to add, so I don't want to block on this, but if we can come up with a generic format or nail down a few of them specifically, it'd be good to include.
@ -0,0 +4,4 @@message Channel {bytes public_key = 1;string name = 2;this is different from the name used to make the claim? is this like a title?
@ -0,0 +4,4 @@message Channel {bytes public_key = 1;string name = 2;yes
@lyoshenka is anything blocking this?
what are the possible values for
orientation?i'm dropping the ability to list payments in BTC. we're just keeping usd and lbc.
@lyoshenka I would say horizontal/vertical, but we can expand that to 0/90/180/270 (https://stackoverflow.com/a/47676129/8308000). I asked Sean and he suggested a boolean for a Portrait setting.
Pull request closed