The community.lexicon.preference.ai lexicon

ngerakines.me · April 22, 2026, 7:40pm

Hey everyone,

Picking up from a few weeks ago, I created a PR that I’d like comment on. I’m specifically looking for who would be interested in using this lexicon to interop:

github.com/lexicon-community/lexicon

Add community.lexicon.preference.ai lexicon (#72)

main ← ngerakines/community.lexicon.preference.ai

opened 06:51PM - 04 Apr 26 UTC

ngerakines

+219 -0

## Summary - Introduces the `community.lexicon.preference.ai` lexicon for dec…laring user preferences regarding AI usage of their public data - Decomposes AI usage into four distinct categories (training, inference, synthetic content generation, embedding), each with independent allow/deny controls - Supports scoped overrides via `globalScope`, `entityScope`, and `collectionScope` so users can set account-wide defaults and carve out exceptions for specific entities or collections ## Design Each preference is tri-state: allowed, denied, or undefined (omitted). The record at key `self` with `globalScope` establishes account-wide defaults. Additional records keyed by TID are scoped overrides that only need to declare the preferences they change — everything else falls through to the default. Consumer resolution order: 1. Entity-scoped override matching the consumer's DID or domain 2. Collection-scoped override matching the content's NSID 3. Global default at key `self` ## Related work - Complementary to [Bluesky Proposal 0008: User Intents for Data Reuse](https://github.com/bluesky-social/proposals/blob/main/0008-user-intents/README.md) - [IETF AI Preferences working group](https://datatracker.ietf.org/group/aipref/about/)

rude1.blacksky.team · April 22, 2026, 7:41pm

Myself and Blacksky would like to push this through as a working group and are committed to adopting this in our app in an interoperable way.

taurean.bryant.land · April 22, 2026, 8:14pm

I’d like to be involved in that. I took a first shot at a lexicon for identifying as automated but that’s largely useless without some way for users to communicate their own needs. I’d love to see this handled at a level that is not focused on Bluesky-based lexicons.

sherifea.com · April 22, 2026, 9:04pm

Hey, would like to be involved for Eurosky too. Cheers!

chaosgreml.in · April 22, 2026, 9:17pm

I’d like to be involved as well! Would be helpful for Charcoal.

posth.me · April 23, 2026, 7:15am

I’d like to participate in the discussion. Liccium would implement the lexicon if it makes sense. I also left a comment on Github:

github.com/lexicon-community/lexicon

Comment by sposth - Add community.lexicon.preference.ai lexicon

main ← ngerakines/community.lexicon.preference.ai

As mentioned above, the work at the IETF is highly relevant – not only with rega…rd to the vocabulary itself, but also the attachment mechanisms. [https://datatracker.ietf.org/doc/draft-ietf-aipref-attach/](https://datatracker.ietf.org/doc/draft-ietf-aipref-attach/) [https://datatracker.ietf.org/doc/draft-ietf-aipref-vocab/05/](https://datatracker.ietf.org/doc/draft-ietf-aipref-vocab/05/) Following the IETF meeting in Toronto a couple of days ago, a new editor’s draft is expected soon. It will include several improvements, in particular on the discoverability of content that has been opted out in the context of search. This is an important point. Many users may wish to opt out of AI training while still remaining discoverable in what the IETF may call “non-generative search” – meaning AI-assisted search that does not provide AI-generated summaries, synthetic answers, or other substitute outputs. In practice, this can be understood as a narrower form of the IETF Internet draft on display-based preferences mentioned already by @musicjunkieg. The use cases around RAG and inference – where content is used by AI systems after model training – are expected to be discussed at a future IETF meeting, likely in late summer. That discussion should help clarify whether the emerging IETF vocabulary will provide meaningful value for creators and rightsholders, who would like to have a say how content is used by AI systems post-training. Adding new AI preference expressions may be desirable, however it should be considered whether the AI model developers, AI system providers, or search engines will take them into account. I suggest a realistic approach in this regard. A second point concerns the attachment mechanism. Should AI preferences be applied only as general account-level settings, or should they rather be attachable to individual posts and media assets? This distinction matters. Content is frequently shared, quoted, or reposted by accounts that are not in a position to decide on rights reservations or permissions. For that reason, attaching such preferences solely at account level may create both practical and legal concerns. At Liccium, we are working on an asset-level approach in which AI preferences can be bound directly to the individual post and to the underlying media asset (blob) using ISCC fingerprints. This allows preferences to travel with the content itself, rather than depending only on the account or the platform through which it was shared.

bumblefudge.com · April 23, 2026, 8:19am

See previous discussion here

I see in Sebastian’s github comment that the issue of where to express licensing and/or AI terms has come up. I believe account-level is a bit of a fig leaf because the “unit of measure” for the web is still (and realistically will be for decades) the HTTP URL, not the at:// URI, and it is a “polite software” strategy to politely ask all webviews to properly crawl-to and expand and apply account-level metadata onto each display of an at:// URI…

the more extreme web3 position would be that if AI preferences and licensing terms aren’t signed by the private key of a public key in the DID Doc, you’re just inviting bad actors to impolitely ignore or strip that metadata, and you should keep these declarations not just in each URL but in each piece of verifiable data full stop. that’s where i’m increasingly convinced ActivityPub needs to go as Client-to-Server inches its way to production, and I would suggest it here as well.

ngerakines.me · April 23, 2026, 1:25pm

Read through your comment. I don’t have any objections really. To bridge the gap between “we should” and “this is how”, can you provide some examples of what specifically you’d like changed or incorporated?