Varun Srinivasan pfp
Varun Srinivasan
@v
FIP: Labels A data standard to annonate context about accounts like language, humanity, spamminess and other qualities. Labels will make it easy to generate public datasets that are useful for app developers to categorize casts and users. https://github.com/farcasterxyz/protocol/discussions/216
15 replies
23 recasts
92 reactions
shazow pfp
shazow
@shazow.eth
Similar to Bluesky's labellers, but shouldn't the labels be signed by the labeller so they can be replicated more safely?
1 reply
0 recast
1 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
in this version you're fetching it from a trusted source provided by the labeller so you're establishing trust via the data source (url, github account etc) bluesky needs labels because its replicated across instances and may not be at the source when it is retrieved
1 reply
0 recast
0 reaction
shazow pfp
shazow
@shazow.eth
Bluesky could have just said "you can fetch it from a trusted source", but signing unlocks a lot of architecture options. Why even specify the source fid then?
1 reply
1 recast
0 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
what would signing unlock here?
1 reply
0 recast
0 reaction
shazow pfp
shazow
@shazow.eth
Not having to rely on a trusted provider? The ability to safely replicate, the ability to merge records without conflating different trust assumptions, the ability to build a separate protocol on top of this, etc.
1 reply
0 recast
1 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
i get the abstract benefits, but what concretely is someone on farcaster going to build with this tomorrow or next month? i suspect the answer is "nothing" until we get a lot of data into this format first, so i want to focus on that with as little bloat as possible. if we get there, then we can add signatures and expand scope with a v2 format.
1 reply
0 recast
0 reaction
shazow pfp
shazow
@shazow.eth
If future proofing is an anti goal then I suggest simply removing the source fid and getting to work on v2.
2 replies
0 recast
0 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
bad idea. you need the source specified concretely because it might be implicit in the data source.
2 replies
0 recast
0 reaction
polymutex pfp
polymutex
@polymutex.eth
I concur with @shazow.eth that `provider` being a raw FID seems not future-proof. I'd suggest adopting an object with subtypes, similar to how the `target` field works. This trivially accommodates raw FIDs, can be expanded to support signing and to support non-single-FID sources (channels? onchain data sources?)
0 reply
0 recast
0 reaction