Unfortunately, we don’t plan to implement the app lexicons on Bluesky Directory. This is primarily because all of our bandwidth is allocated to paid work right now.
But it’s also a matter of strategy. We’ve talked a lot lately about what’s next for Bluesky Directory. It’s been a cool project, but our efforts to monetize the site haven’t succeeded. We bring in enough to pay its operational costs, but that’s about it. We’ll absolutely keep it going, but we don’t plan to add any new features.
We still love Bluesky, but for us, the ATmosphere is the future, so that’s where we’re going to focus. We really want to start building atmospheredirectory.com (which we own), but again, we can’t do it without a way to fund it. When we do build it, we’ll implement the lexicons, for sure!
TLDR;
This version moves the shared pieces into reusable definitions, follows AT Protocol conventions more closely, and clarifies how third-party entries can point to canonical app profiles.
I also took @knowtheory.net ’s localization point a bit further by adding a dedicated localization record, so app authors can publish official translated presentation metadata. For richer app-store-style media, I followed @byarielm.fyi’s suggestion and added support for Web App Manifest URIs instead of adding separate hero/screenshot fields directly to the lexicon.
One point I’d like feedback on: for the app description, I aligned the limits with a Bluesky post: maxLength: 3000 and maxGraphemes: 300. Does that feel right for app descriptions, or should this lexicon use different limits?
We expanded all the limits for the conference profile and effectively you won’t get to something “bsky post sized” when sharing because you’ll need to add text about this in any case.
For the conference profile we ended up having a longer “bio” - does extended description make sense?
Feels like there is enough variability here or opportunity for someone to do a “standard site” compatible field that is any many characters as people want.
I saw some comments that gave me the impression there were more changes, but tbh perfect is the enemy of good. Whomever feels this is “ready” leave a comment saying so in the PR and I’ll go ahead and approve once I do one final validation check.
I created an App Lexicon Generator and in the process, realized how much complexity the Web App Manifest idea brings to the trade, as it seems it’s not really widely known.
I’m thinking we should perhaps back pedal and while keeping the web app manifest entry in the lexicon, add our own “images” entry (as an array where owner can label the image as a “hero”, a “screenshot”, “icon”, “ads”, …
I like the idea of web manifest, but maybe it’s even just part of the process of scanning it if it exists to create the lexicon entries and just do the images array as you suggest.
Thanks @ngerakines.me and @bmann.ca ! I do fear the Wep App Manifest is adding an unnecessary hurdle and will add a “images” entry, similar to the “links” entry. That will give maximum flexibility.
I just had an idea I’d like to run through this WG. It is not at all a blocker for accepting the PR.
Wouldn’t it be cool if the app lexicon lists the scope of lexicons it uses? That would enable app listers to detect and display the interoperability of, say, bluesky with blacksky and northsky, offprint.app & leaflet, etc, etc.
it could be a “lexiconScope” of type array.
AFAIK, there is no simple way to find that out, is there ?
Finally taking a look, thanks for following up on this, been busy PhD’ing -
Really love the shape this is taking and happy with it. No concerns or objections on the lexicon. Just a question: why was web manifest URI pulled out from under the links field?
Lastly, @thisismissem.social does these proposed lexicons seem reasonable to adapt for more refined purposes like Eurosky’s directory, where profiles may not have a “made in europe” tag?
The closest would be the client-metadata.json - if the app is requesting permission, they’re using the lexicon in some way. But e.g. sprk.so might request bsky permissions so users can cross-post, but they don’t show those lexicons in most places of the app.
why was web manifest URI pulled out from under the links field?
It got “promoted” to its own space because it contains a lot of interesting (reusable) data (screenshots, icons, description, name, short name, theme colors). But then as I explained above, I realized it’s adding a lot of friction: many app developers do not seem to know about the manifest (given most apps don’t have one), so since that version of the lexicon made it a requirement to add visuals, it means we’d also need to educate them on that, on top of the lexicon.
It does not really hurt to keep it there, and I use it in my app lexicon generator to prefill the lexicon. But true, it could also move back to being just a link entry.
