probably 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 6Samuel
@samuel.fm
Yeah 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 4
bryan newbolddoesn'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 9SamuelHoly shit DLC font packs. Genius. The best part is you get to subject all the other clients to your comic sans posts too
1 3bryan newbold
David BuchananIf I wanted to store information within an image, I'd use a much more efficient mechanism than text :P
2 8
wordslist your top five more efficient than text information storage mechanisms please
2 1Samueloh you sweet summer child
David Buchananraw bytes
2 3David Buchanan(this occupies positions 1 through 5)
1 1shreyan (wise)these? legible? really?
5David Buchananjust add an "app.graysky.metadata.version": "blah" field to your post records
1 6SamuelGood idea, thanks
1 5P(aul) Frazeefwiw I’d suggest designing the field as if it’s official; the ideal is it gets upstreamed, right?
3 6David Buchananpaul this is how we get useragent strings
3 10SamuelMozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 Bluesky 1.50.0 Graysky 0.1.3
8P(aul) Frazeethis is like teenagers and hormones. I can’t stop it from happening but I can make sure they’re safe about it
3 19
Robin BerjonYou'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.
1
Mykael Wyvern — 🔮🧙🏻♂️🐉I mean I'd just expect reverse domain labeled keys with something like "com.atproto.*" being the most canonical followed by "app.bsky.*"
3 5David Buchananneither is more or less canonical, they're just Different
1 3Mykael Wyvern — 🔮🧙🏻♂️🐉Well sure, but I'm thinking of a consensus set where you'd have something like "com.atproto.app" eventually..
I'm thinking of the OCI annotations standard really specs.opencontainers.org/image-spec/a...
The OpenContainers Annotations Spec
Opencontainers Specs Documentation
specs.opencontainers.org
P(aul) FrazeeWe try to avoid syntaxes like that in the key names
1 1Mykael Wyvern — 🔮🧙🏻♂️🐉IMHO it encourages experimentation by setting clear rules and the possibility of things being incorporated upstream.. otherwise it's a free for all.. what about PDS' adding their own labels or middle tiers? Don't want them stepping on each other's labels..
1 3P(aul) Frazee100% agree. The trick is finding ways for us to avoid clobbering each other and to potentially support each other’s features and avoid blockers to doing so.
2 4
Jay.No, Mykael, David doesn’t like cannons.
1 1David Buchananthere's only room for one channon
1