Samuel
@samuel.fm
wait so what’s the conclusion of abusing labels for this case specifically. Should I do something more like unspeccedPostedBy: “Graysky” on the post itself (if that’s possible). Or abuse facets instead?
2 10Paul and I actually disagree here, i think it’s totally fine to use labels in this way. Labels are statements made by some party about a post, and the self-labels are statements made by the author of the post. Plain and simple imo
4 2 20Makes perfect sense to me but I don’t want to accidentally fuck up a potentially large % of posts. Especially since this would be all posts not just a weird special case like, say, custom poll posts
1 3that’s such a broad description that it could apply to anything in this network
1 10Exactly. Labels are generic.
2 13no, they’re underdeveloped. we don’t fully understand their requirements yet and you’re asserting a view that introduces new requirements needlessly
9 18src: bnewbold
uri: this thread
val: heated
neg: false
cts: just now
1 5hmm what do you think
2That's why you need stuff like reserved namespaces and defined syntax so you can enforce stricter / more precise logic later without breaking stuff. This reminds me a lot of softforking in new opcodes in cryptocurrency because you can only add rules, never remove any (without unanimous support)
1 5we do have mechanisms for that actually, but labels are so poorly understood at this point we haven’t decided whether to use them
1 6It’s just a property bag Paul how hard can it be?
2 3Yeah, just make sure the strings are secure
1Barry bad
1 1Attacker, sorry, user controlled property bag, stored in a hash table, with the user controlling the keys.
What could go wrong?
1 2Who needs Christmas holidays anyway
Midwit meme with “just use labels” on the tails
4what effect are you hoping for?
1 3an indicator of the client it was posted from
2 6probably the best move would be to propose a lexicon change, second best would be an off spec field that’s maybe an object for that kind of metadata
1 6if the goal is for other clients to be able to render this info then you ideally want to think very generally, like a display name and a URL
2 6Yeah true I’m probably not thinking big enough here. My primary motivation is so I can ask Jaz to see the stats on graysky posts lol
2 4doesn't seem that hard, you can just take the input text, render it to a jpeg, and put a sweet Greysky™ watermark on the image.
you can even have festive holiday themed watermarks. default to efficient high-compression, upsell to GreyskyPlus for sharp PNG and better kerning
2 1 9Holy shit DLC font packs. Genius. The best part is you get to subject all the other clients to your comic sans posts too
1 3If I wanted to store information within an image, I'd use a much more efficient mechanism than text :P
2 8list your top five more efficient than text information storage mechanisms please
2 1oh you sweet summer child
raw bytes
2 3these? legible? really?
5just add an "app.graysky.metadata.version": "blah" field to your post records
1 6Good idea, thanks
1 5fwiw I’d suggest designing the field as if it’s official; the ideal is it gets upstreamed, right?
3 6paul this is how we get useragent strings
3 10Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 Bluesky 1.50.0 Graysky 0.1.3
8this is like teenagers and hormones. I can’t stop it from happening but I can make sure they’re safe about it
3 19You're actually *more* likely to get that result with free-form "app.graysky.metadata.version": "blah" fields!
Label+URL is probably safe: can't game the label field because it's shown to humans, and URL is likely to be equality matched. Or even stricter, make it a DID for the client's account.
1I mean I'd just expect reverse domain labeled keys with something like "com.atproto.*" being the most canonical followed by "app.bsky.*"
3 5neither is more or less canonical, they're just Different
1 3We try to avoid syntaxes like that in the key names
1 1No, Mykael, David doesn’t like cannons.
1 1btw there's a related github discussion regarding PDS version info here: github.com/bluesky-soci...
snarfed pointed out the nodeinfo spec: nodeinfo.diaspora.software/docson/index... , which is essentially {name, version, repository, homepage} -which could all be optional string fields (except name)
2 5@mozzius.dev just pinging you in here since this is above the 5-reply limit
1 4"repository" might be better named "codeRespository" or something, to disambiguate against the atproto definition of a repo
3