Add community.lexicon.app lexicons

[pixeline]

Summary

Adds the app directory proposal from the Community App Lexicon WG thread:

• community.lexicon.app.entry for community/third-party app listings
• community.lexicon.app.profile for official self-published app profiles at rkey self
• community.lexicon.app README guidance for canonical profile preference and out-of-band verification

This also adds the minimal properties: {} declaration to community.lexicon.preference.ai#globalScope so the existing full-repo lex CLI validation passes.

Source: https://discourse.atprotocol.community/t/community-app-lexicon-wg/761

Validation

• jq empty community/lexicon/app/*.json community/lexicon/preference/ai.json
• npx -p @atproto/lex-cli@0.9.9 lex gen-api --yes tmp ./community/lexicon/*/*.json

License and Assignment

• I assign all rights of this contribution to Lexicon Community as an open source contribution under the MIT license.

[hipstersmoothie]

Would love to see the addition of 2 more fields

• hero: I've found it's nice to have a space for a large marketing image (see atstore)
• screenshots: also pretty typical of a product listing

[knowtheory]

Hi, can i request a locale field for entry records?

To the extent that entry records are non-authoritative and could be created and customized for a variety of purposes, it would be helpful to know if an entry is oriented towards a particular language/regional community both for searching and listing purposes.

I have a little more pause with the profile record when it comes to considering localization, since it's supposed to be an authoritative record from the app itself. It might be worth considering child records for the profile that are locale specific and pushing some of the fields there.

[pixeline]

Would love to see the addition of 2 more fields

• hero: I've found it's nice to have a space for a large marketing image (see atstore)
• screenshots: also pretty typical of a product listing

This is definitely a valid app‑directory use case. I’m inclined to model it via a webManifestUri rather than direct hero/screenshot blobs, since the Web App Manifest already supports icons, screenshots, labels, platform/form‑factor hints, and language, and keeps large promotional media out of repo records. For app creators, that provides one flexible source of truth they can reuse across PWA listings and app stores (including the Play Store), while still letting directories render hero images and screenshots from the manifest. If we run into gaps in what the manifest can express for app discovery, we could then consider dedicated fields in a follow‑up.

[pixeline]

Hi, can i request a locale field for entry records?

To the extent that entry records are non-authoritative and could be created and customized for a variety of purposes, it would be helpful to know if an entry is oriented towards a particular language/regional community both for searching and listing purposes.

I have a little more pause with the profile record when it comes to considering localization, since it's supposed to be an authoritative record from the app itself. It might be worth considering child records for the profile that are locale specific and pushing some of the fields there.

Good point. I’ll add a locale field to entry so a directory listing can say which language or region it is intended for, for example en, fr, or pt-BR. For official app profiles, I’ll add separate localization records so the app publisher can provide translated names, descriptions, links, and other display metadata without overloading the main profile record.

[ngerakines]

lgtm

[gxjansen]

Nice work!

I have 4 potential additions as follow-ups (not blockers)

1. Lexicon interop declarations

Answers "which apps interoperate with lexicon X?"

Something like:

  "lexicons": {
    "type": "object",
    "properties": {
      "produces": { "type": "array", "items": { "type": "string", "format": "nsid" } },
      "consumes": { "type": "array", "items": { "type": "string", "format": "nsid" } }
    }
  }

Makes the directory queryable by capability, not by name alone. Probably also the strongest argument for keeping this in community.lexicon.app rather than something that could live in any generic app-listing schema.

2. License (SPDX expression string)

The atproto ecosystem skews open source, people might filter on it. SPDX strings (AGPL-3.0-or-later, MIT, Apache-2.0, LicenseRef-... for source-available). Useful at listing level without clicking through to the repo. Unless of course the appstore pre-filters on "only open source", but that's something for the AppView to decide, still useful info for the lexicon?

3. backendDeployment (token)

Most atproto apps today are single-operator SaaS (Bluesky, Frontpage, Whitewind, Smoke Signal, Sifa). But still a signal worth capturing is whether someone other than the canonical operator can actually run their own AppView/backend, with real intent and tooling, not just "the code happens to be on GitHub."

Suggested tokens:

• #singleOperator: one canonical instance, no self-hosting path expected
• #selfHostable: operator supports running your own instance (docs, deploy templates, etc.)

E.g.: Bluesky's AppView code is open but nobody self-hosts it: #singleOperator. Barazo is designed for self-hosting from day one: #selfHostable.

4. platforms (token array)

Web App Manifest covers PWA form-factors but not native installs, so a native iOS app currently has no way to say so. Flat tokens:

community.lexicon.app.defs#web
community.lexicon.app.defs#ios
community.lexicon.app.defs#android
community.lexicon.app.defs#macos
community.lexicon.app.defs#windows
community.lexicon.app.defs#linux
community.lexicon.app.defs#cli

Distribution URLs (App Store, Play Store, F-Droid) can live in the existing links array, no extra schema needed.

Smaller things:

• webManifestUri vs explicit images precedence is undefined when both are present. The README says the manifest can "prefill or augment", which is ambiguous: prefill implies the manifest provides defaults that explicit fields override, augment implies the manifest adds to what's there. Those are different behaviors, might be worth pinning that down.

[jphastings]

(Apologies; only half a brain to write this at the moment — do ask questions if this doesn’t make sense!)

It might be handy to include the canonical NSID that would indicate a user of this app in there too?
Like, “if this NSID/record is present for an account then you can assume they are/have been a user of this app”.

eg. org.passingreads.actor.profile:.self (I think that was the proposed RecordPath extended syntax for referencing a record with a given rKey, eg. like this! Here was part of that convo)

[pixeline]

Nice work!

I have 4 potential additions as follow-ups (not blockers)

1. Lexicon interop declarations

Answers "which apps interoperate with lexicon X?"

Something like:

  "lexicons": {
    "type": "object",
    "properties": {
      "produces": { "type": "array", "items": { "type": "string", "format": "nsid" } },
      "consumes": { "type": "array", "items": { "type": "string", "format": "nsid" } }
    }
  }

Makes the directory queryable by capability, not by name alone. Probably also the strongest argument for keeping this in community.lexicon.app rather than something that could live in any generic app-listing schema.

2. License (SPDX expression string)

The atproto ecosystem skews open source, people might filter on it. SPDX strings (AGPL-3.0-or-later, MIT, Apache-2.0, LicenseRef-... for source-available). Useful at listing level without clicking through to the repo. Unless of course the appstore pre-filters on "only open source", but that's something for the AppView to decide, still useful info for the lexicon?

3. backendDeployment (token)

Most atproto apps today are single-operator SaaS (Bluesky, Frontpage, Whitewind, Smoke Signal, Sifa). But still a signal worth capturing is whether someone other than the canonical operator can actually run their own AppView/backend, with real intent and tooling, not just "the code happens to be on GitHub."

Suggested tokens:

• #singleOperator: one canonical instance, no self-hosting path expected
• #selfHostable: operator supports running your own instance (docs, deploy templates, etc.)

E.g.: Bluesky's AppView code is open but nobody self-hosts it: #singleOperator. Barazo is designed for self-hosting from day one: #selfHostable.

4. platforms (token array)

Web App Manifest covers PWA form-factors but not native installs, so a native iOS app currently has no way to say so. Flat tokens:

community.lexicon.app.defs#web
community.lexicon.app.defs#ios
community.lexicon.app.defs#android
community.lexicon.app.defs#macos
community.lexicon.app.defs#windows
community.lexicon.app.defs#linux
community.lexicon.app.defs#cli

Distribution URLs (App Store, Play Store, F-Droid) can live in the existing links array, no extra schema needed.

Smaller things:

• webManifestUri vs explicit images precedence is undefined when both are present. The README says the manifest can "prefill or augment", which is ambiguous: prefill implies the manifest provides defaults that explicit fields override, augment implies the manifest adds to what's there. Those are different behaviors, might be worth pinning that down.

Thanks a lot for all this! I added lexicons with produces / consumes so directories can answer “which apps work with lexicon X?” (really curious to see how this will be used in the wild), and added platforms as token-backed values rather than relying on tags for that.

I’m going to leave license and backendDeployment out of this PR for now. Both seem useful, but I’d rather keep this v1 focused and treat those as follow-up additions once the base app/profile records land.

I also moved Web App Manifest back into links with a dedicated linkRoleWebManifest, so there’s no longer a separate precedence question between webManifestUri and explicit fields.