Community App Lexicon WG

A lexicon is permissionless.

It takes one bad actor to mess this up.

This could work if the aggregator has a pre-approval flow to screen and verify new apps, so something to keep in mind.

Also this should be a self record pointed on the did of the project app itself? So that others cant overwrite it? Assuming this is already in the design but havent seen it specified.

I have added the WG outline @pixeline.be drafted (shared on Tangled) to the top post. If you’re interested in joining the working group, please edit the top post and provide your comments on the proposal not the lexicon itself. We can do lexicon-specific discussion once the WG is established.

I’ll add my notes on the proposal in the next day or two.

2 Likes

Hii, I just reviewed your previous wiki edit – thanks a lot!! this clarifies my concerns with self key form zicklag which I strongly support!

I appended the proposal part with two items (1) png and jpeg app icons, and (2) svg uploads.

I heard this from Tori (in her talk from atmoconf), and read it from Miss Em (on discord) that it took some time to fetch all icons (for the eurosky portal).

I believe this addition will solve for this problem.

I seperated png & jpeg from svg, because I believe the png & jpeg is a non-issue, I don’t know if people agree with the svg, so I split them :sweat_smile:

I tried to edit the top post to add my name, but got a 500 error.

Hey @pixeline.be – we had a @lexicon-community-tsc call last week and tried to make things easier and more clear on path to WG.

TLDR – you should go ahead and make a PR into the community.lexicon.app space lexicon/community/lexicon at main · lexicon-community/lexicon · GitHub

Much like the community lexicon ai preference, there’s enough interest and momentum to start working in that space on Github.

Thanks for the work you and everyone have done on this so far!

2 Likes

Hi all, here is the PR Add community.lexicon.app lexicons by pixeline · Pull Request #76 · lexicon-community/lexicon · GitHub

The PR is in submitted for review. Let me know if you need anything changed.

2 Likes

I’ve done it for you.

1 Like

one use case for an svg is services wanting the icons that can be set to a specific color

also want to note that avif and webp should probably be included in that bitmap logomark blob field.
and might want matching a logotype bitmap+svg pair in the lexicon

1 Like

What’s intentionally left out (for now)

These were discussed but deferred to keep v1 minimal:

  • Screenshots, keyFeatures — useful for rich directories but not core metadata.

I do think we should consider how self-published lexicon can support brand assets more generally. But this should be separate from the app submission lexicon, e.g. in app profile lexicon. My thinking: submission entry will be simpler to get out sooner by e.g. not letting just anyone submit screenshots for an app. But we can work more on the brand/profile one after that’s out. Perhaps that’s even a separate one - brand kit? Should profile and brandkit be separate? Tldr: yes exclude from community.lexicon.app.entry (v1)we should discuss the app.profile lexicon more as that’s both more nuanced and newer suggestion (so more v2+) imo.

Aim 4: Build or adapt at least one working implementation

At least one app (AppView + client) should use the finalized lexicon to create records on PDS and display a directory. atproto.garden and store.stucco.software are both candidates.

  • Deliverable: A working, open-source directory app that reads/writes the shared lexicon

  • Status: In progress (nikolas.ws and dame.is are both building)

Beyond this, I would like to make sure existing implementations know when the lexicon (submission but especially profile one) is available and attempt a coordinated release or “launch day” amongst at least a few of them.

Meeting Details and How to Join

  • Where: TBD — likely a dedicated channel on the ATProto Community Discord, with async discussion on the Discourse forum
  • When: Bi-weekly video/voice calls (day/time to be decided by members), with ongoing async work between meetings

Happy with dedicated discord channel or signal group, whatever others prefer.

Biweekly calls seem reasonable to me.

1 Like

Where: I’m not a huge Discord fan but if that’s what everyone is comfortable with, no problem.

When: Because I’m in Brussels, Belgium and 9 hours away from most of the nice folks I’ve had the pleasure of interacting with so far around atproto, biweekly calls is simply a no-go for me. I would prefer we continue async. I’m ok to arrange 1 (one) call if it helps finalize this.

Launch day I’m really wanting to release this as soon as possible so I can integrate it into atproto.brussels /atproto-apps (.entry) , mathr.app and gravita.social ( .profile). we could soft launch for people who maintain a listing and then a full launch for everyone. We can also reach out to all app authors to inform them. Some documentation could also help onboarding them, with even a generator and a link to tools like realfavicongenerator to help them produce their app profile lexicon.

1 Like

I’m fine with just chatting here too fwiw! And makes senses on time zones.

What’s a timeline that feels reasonable for v1 and/or v2 to target for soft launch to app listing devs? Seems you envision that as separate from launch to everyone, what timeline are you think there?

When thinking about it, I guess it makes sense to tell app makers over app listers, so that app listers can use the .entry only for apps that don’t publish a .profile . wdyt?

Thinking out loud here on a launch day approach. Once the lexicons are implemented on lexicon.community this seems reasonable to me (but happy to adjust):

  1. D-day: lexicons are published on lexicon.community
  2. +5D: I(?) release a lexicon generator for app creators : a static json creator based on a form
  3. +10D: release a short documentation, with resources to help (the lexicon generator + app icon generators)
  4. +11D: announce it to the folks who maintain app creators
  5. +20D: announce it to the folks who maintain app listers with a deadline to update their listing to +30D ?
  6. +30D: launch day

If you want i can prepare a google docs to better co-design the “market” plan of the lexicons ?

I’m also fine for a more organic approach. Things are announced when they are released and the community catches up gradually.

My inclination is for soft launch = let listers switch to lexicon, full launch = app devs can publish from any of the listing sites that implement the lexicon. Idea of giving listers the first go is they can figure out rollover, then implement any features they want to add to help developer submissions go more smoothly (like youd’ like to do with generator + documentation).

Once that’s set (give it a deadline), then we let developers know we have lexicon and they can submit at X Y or Z. Most of the listers are already listing either via a DB or lexicon, so rollover setup period seems fair.

I think if we can get atproto.brussels (you, ofc lol) + atstore (community) + atmosphereaccount (joe, community-ish?) + blueskydirectory (@jluther.net) onboard for lexicon launch that’s a great start. If others want to join that’s also great and they can be included.

1 Like

So I went through the listing apps I could find ( - https://docs.google.com/spreadsheets/d/1TJbHnCJq54m6zGNRAnLsD9Lq42rx2PqJdri7-UeRQfM/edit?usp=sharing

Summary of common fields:

  • name - 9/9 (no surprise lol)
  • url - 9/9
  • category - 7/9 → there’s massive differences between them though
  • tagline - 6/9
  • logo/icon - 6/9
  • description - 5/9
  • createdAt - 4/9 → all the ones with lexicons
  • tags - 4/9
  • screenshots - 4/9
  • alternativeTo - 3/9
  • links, repositoryUrl, iosLink, androidLink - 3/9 total

Given this and acknowledging brands need control of their assets and marketing, my suggestion for v1:

  • app.entry = name, url, tags, createdAt
    • description? → seems less risky e.g. have an app displaying user-submitted descriptions of brands vs. user-submitted assets.
    • status → useful for community monitoring of e.g. dead profiles?
  • app.profile = name, url, tagline, description, links
    • avatar = icon? just pull from at account on login (atmosphereaccount.com is doing this with bsky lexicon profile)?
    • icon, logo? screenshots? other brand asset info? → separate lexicon, or just flesh this out to a minimum set for profile?
2 Likes

I would like to push back a bit on the approach of first onboarding App listers over App makers. Here is why:

  1. Given the recent atstore.fyi drama, I’m a bit worried about the message we project if we start with App listers, vs starting with App makers.

  2. in the Readme, we’ve written:

Consumers may use community.lexicon.app.entry records for discovery, curation,
and third-party directories. When an official community.lexicon.app.profile
record exists, consumers should prefer that profile as the canonical app record.

So shouldn’t we first make sure there are more .profile records in the wild, and fill the gap with .entry ones ? It will also reduce the extra work for the App Listers.

What do you think?

1 Like

I would suggest against a launch day. It’s artificial.

Apps that want to adopt will. People will build new apps if there is a bunch of lexicon app records in one format.

Yes you’ll need to promote app profiles … but it’s a bit chicken and egg with displaying them somewhere.

The ones listed on EuroSky Portal you could probably reach out to, to support. I talked to @sebastian.eurosky.social & @thisismissem.social in Berlin about this, they’ll adopt a standard that gets adopted.

@byarielm.fyi you could put an issue in the ATstore around switching to this lexicon. Maybe start displaying .profile sooner rather than later?

Also @pixeline.be re: calls - you can make them when you like — eg 4pm/5pm/6pm CEST. But no pressure - do calls if they are useful. I do recommend at least a kick off call and a weekly or biweekly “check in” time for updates

2 Likes

Perhaps we could prepare together an offprint article sharing tips for atproto builders on “how to market your app” introducing the lexicons, the webmanifest, etc ?

Oh yeah my thought wasn’t listers doing listing, just them setting up what they need to transition to new lexicon (if they use one, and setting up to use one if they do t) and if they want to setup a submit UI for apps.

But maybe an offprint with just a simple “publish record to this lexicon” is better? I pinged Dame to see if they had thoughts on the launch day idea since they wanted atproto.garden to be community too iirc

Will make an issue on atstore

I know Boris said a launch day is “artificial”, but I don’t think there’s much of a downside to giving people some clear dates and organizing around a specific time as a launch pad like @byarielm.fyi suggested.

My original intention with atproto garden was to get like 10-15 app creators onboard with submitting theirs prior to an announcement, and then announcing with their help + a call to action for creators to submit theirs. Obviously this scenario is slightly different cause it’s a lexicon and multiple directories, but it could still work.

1 Like

this is awesome compiling and summarizing, ty for taking the time to do this!

1 Like