Proposal: User Intents for Data Reuse

[bnewbold]

This is a discussion thread for the User Intents for Data Reuse proposal.

[DGaffney]

This is super cool and forward thinking @bnewbold! Thank you for this. One thought comes to mind is that there may be value in having some sort of track changes of historical settings (so that, should it become necessary, it's easy to know not just what the current policy is, and when it was established, but the full historical chain of policies and their update times) - lots of situations I can imagine out of the gate with people saying "but who knows what it said when I pulled it"

[bnewbold]

The idea would be to have the intent definitions be pretty stable over time. If a revision is needed, a new "v2" intent would be added, which folks would need to re-configure.

As proposed, the per-account declaration file would have an updatedAt flag for each intent, showing when it last changed.

[gxyflow]

Seems like it might be a good idea to bake versioning in explicitly from the start? eg something like

{
  "$type": "org.user-intents.declaration",
  "$version": "1.0.0",
  "syntheticContentGeneration": {
    "updatedAt": "2025-02-20T21:37:20.362Z",
    "allow": false
  }
}

This way, clients/consumers would know to look at the version, and can handle new versions gracefully/appropriately instead of blindly applying the same (v1) expectations to future versions.

From a backend engineer's perspective, it's very easy to fall into the trap of thinking a design is near-perfect and will not need to evolve much anytime soon... until it does, and it feels like a huge lift to iterate to the next version, which can impede good improvements from being implemented.

(That said, there's tradeoffs to every decision, and distributed social networks is not my area of expertise -- this is gut feeling based on experience and my current understanding of the proposal.)

[DGaffney]

One other smaller nit with the proposal is are there even further sub-conditions on the rules e.g. I'm cool with wayback machine but not with the library of congress? Maybe some optional domain scoping or something? May be more pain than it's worth...

[bnewbold]

Per-project / per-service configuration could still happen, just via separate mechanisms.

[HarshitSohaney]

I think having them keyed by origin (similar to cookies) might be neat!

[cjcodeproj]

What if the allow value was modified to act more like a firewall access rule? So, "allow" would contain a list of allowed sites, and it would be paired with a "deny" value containing a list of sites/agents to reject.

[dame-is]

governance of these intents and their definitions is separate from AT Protocol (com.atproto.) and from the Bluesky app (app.bsky.)

@bnewbold do you have any thoughts around the governance of intents yet? are we thinking an appointed committee, set of stewards (elected?), or even some form of voting records/mechanism (could be tricky with botting)?

[bnewbold]

Basically all options are on the table. There is some IETF work underway and we could align with that (IETF is participatory and has layers of governance; the outcome is standards documents). We are having conversations with other orgs like Creative Commons. My informal take is that this isn't really a Bluesky or atproto specific thing, and we should work with (or at least align with) others in this area, instead of inventing a novel governance structure from scratch. But we will see how that goes!

[ghost]

If there isn't already a method planned for opting out of starter packs, I think this would be the best way to implement it, as it would actually be enforceable on the official Bluesky app

[bnewbold]

Starter packs specifically are mentioned in the proposal. They are an application-specific feature (eg, they are "Bluesky Starter Packs", not really "AT Protocol Stater Packs", even if they build on atproto). So I think the opt-in / opt-out mechanism probably makes more sense as a Bluesky-specific mechanism.

[ghost]

A potential way to accomplish declaring intents related to application-specific mechanisms, as well as declaring additional granularity for intents like syntheticContentGeneration (see #3617 (comment)) could be using NSIDs as intent identifiers where available:

{
  "$type": "org.user-intents.declaration",
  "updatedAt": "2025-02-20T21:37:20.362Z",
  "app.bsky.intents.starterPackInclusion": {
    "allow": false,
    "updatedAt": "2025-02-20T21:37:20.362Z"
  },
  "org.user-intents.syntheticContentGeneration": {
    "allow": false,
    "updatedAt": "2025-02-20T21:37:20.362Z"
  },
  "example.research.syntheticContentGeneration": {
    "allow": true,
    "updatedAt": "2025-02-20T21:37:20.362Z"
  }
}

[gxyflow]

I like this. Just to iterate/refine/nitpick:

• it would be cool to allow users to specify whether to allow or deny by default
• probably better to put the intents as a dedicated list property
• versioning of both the declaration schema and specific intents

{
  "$type": "org.user-intents.declaration",
  "$version": "1.0.0",
  "updatedAt": "2025-02-20T21:37:20.362Z",
  "allowByDefault": false,
  "intents": [
    {
      "$type": "app.bsky.intents.starterPackInclusion",
      "$version": "1.0.0",
      "allow": false,
      "updatedAt": "2025-02-20T21:37:20.362Z"
    },
    {
      "$type": "org.user-intents.syntheticContentGeneration",
      "$version": "1.0.0",
      "allow": false,
      "updatedAt": "2025-02-20T21:37:20.362Z"
    },
    {
      "$type": "example.research.syntheticContentGeneration",
      "$version": "1.0.0",
      "allow": true,
      "updatedAt": "2025-02-20T21:37:20.362Z"
    }
  ]
}

[neko-moe-observer]

I understand wanting to limit the granularity of preferences, but i think many users, me included, will simply deny all AI training if the only options are allow/deny. I would love to help out AI training for open-source or freely released models and for scientific research, but i definitely do not want to help any proprietary commercial models.

I think having just a little bit more granularity on the issue de jour will be useful.

[bnewbold]

One way to address this would be to set an explicit "disallow" intention for generative AI training, then identify the specific projects you are willing to contribute to, and in some way explicitly "allow" just those projects.

Trying to differentiate categories like "open-source" or "open-model" or "non-profit" are notoriously difficult in the AI space. Many projects and teams have started in one of those categories and shifted; or their membership in those categories are debated.

If clear definitions take hold, and there is broad agreement on them, we could add granularity around that. I don't think we (Bluesky and/or atproto community) are in the best spot to lead consensus around these categories.

[RMcNeely]

First, thanks for doing some forward thinking about these topics. I just want to raise a question on why the proposal's are opt-in as opposed to opt-out?

[DavidBuchanan314]

why is the system designed to default to an "undefined" state

There are already tens of millions of atproto users, some users of BlueSky, some others of non-BlueSky apps and services, all created prior to the existence of "User Intents for Data Reuse" as a protocol concept. i.e. the status quo is very literally "undefined" and so any new system needs a way to represent that existing state.

If this proposal is adopted, "what should the default for new accounts be? should existing accounts be forced to adopt a default too?" are decisions that can and should be made at the application/client level - the underlying protocol does not need to have opinions there, it merely needs to facilitate such opinions.

[RMcNeely]

This is the reason I expected to hear but I'm not sure what retrieving the intent information looks like so I wasn't sure. I guess in the future you could conceive of a v2 where it already exists and then the protocol might have an easier time declaring a default setting.

[jritch]

If this proposal is adopted, "what should the default for new accounts be? should existing accounts be forced to adopt a default too?" are decisions that can and should be made at the application/client level - the underlying protocol does not need to have opinions there, it merely needs to facilitate such opinions.

But the proposal, as it is written, describes application-level behavior and implies that Bluesky users would have to explicitly configure their settings to opt out of sharing their data.

Suppose a Bluesky user does not want any of their public data to be used for generative AI training. They would go in to app settings, find the data reuse preferences section, and configure “Generative AI” to “disallow”.

Is there a place where users or community members can give input on what application-level behavior should be? I think many Bluesky users would be much more comfortable with automatically "disallowing" Generative AI use for existing accounts.

[bnewbold]

This proposal basically assumes that downstream users are well-behaved, either because they are actually trying to "do the right thing", or because they are required to do so with social, cultural, and/or legal pressure.

Some situations and regulatory scenarios depend on users explicitly opting out, in a machine-readable format, in a way that can be differentiated from software-decided-defaults.

[just-cameron]

I like undefined as a property, even though I generally believe in opt-in systems. The reason for this is that there are some forms of use of user data that are relatively harmless. Starter packs and list membership are examples to me of relatively harmless use of your data. ATProto is public and choosing strictly opt-out for all applications doesn't quite make sense to me.

I wonder if there is a world where the PDS asks a user on repo creation what their preferences are. This would leave existing repos with undefined values, and help new repos understand easily what their options are. Obviously still up to whatever the PDS is, though imo that's a long term feature.

[sinand]

If this intent system is implemented, it should be mandatory for all PDS and other applications using the AT Protocol to enforce these preferences. Otherwise, many apps will prioritize "user convenience" and UX choices as an excuse not to ask users for their preferences. As a result, only a small number of privacy-conscious users will be aware of these options, while the majority remain uninformed.

Additionally, there is a risk that LLM abuse could turn this into a spam mechanism. Users aiming to manipulate responses to specific questions might create content specifically designed for this purpose and post it as ordinary content while setting "allow": true. This could lead to intentional bias in AI training data.

[tom-sherman]

It's not possible for any PDS to enforce an opt out in the same way that it's not possible for a public website to enforce tools not to scrape it. It's only possible to express an intent (eg. robots.txt) and it's up to third parties to respect that intent.

[sinand]

It's not possible for any PDS to enforce an opt out in the same way that it's not possible for a public website to enforce tools not to scrape it. It's only possible to express an intent (eg. robots.txt) and it's up to third parties to respect that intent.

I think you're misunderstanding my point. I'm not talking about technical enforcement of these preferences by third parties.

I'm saying that if this intent system is implemented as part of the AT Protocol, it should be mandatory for all PDSs and applications using the protocol to present these options to their users. Otherwise, most apps will prioritize "user convenience" and UX considerations as an excuse not to ask users for their preferences. As a result, only a small number of privacy-conscious users will be aware of these options, while the majority remain uninformed.

The document specifically states that applications (e.g., the Bluesky App) would allow configuration of intents in a settings dialog. My concern is about ensuring all users have equal access to these settings across all implementations of the protocol.

[bnewbold]

These preferences are definitely the sort of thing a PDS could expose through an Account Management web interface. That would be an app-neutral way for users to find and configure the settings.

[ajdecon]

This is really interesting and I love that you all are thinking in this direction.

On my initial read of this, the analogy I came away with was “robots.txt for ATProto, but categorized by use case rather than agent”. Is this a good way to think about it, or is there a better mental model to use?

What was the design thinking behind the use case categorization rather than agent? I can see arguments either way (eg, I’m good with a group archiving data but not distributing a bulk dataset). But I think categorization by agent is what most developers are more used to on the web, and I’m curious why you all started first with this version.

[CrystalENVT]

I feel the best approach for this type of initiative is to have these as Opt-In features instead of Opt-Out, as the average user will never navigate to this settings page. Prioritize protecting uninformed individuals.

When the new feature is added have a one time prompt that will lead directly to the settings page for configuring these settings, and (optionally) as a part of the new account creation process show the settings so the user can configure the settings from the get-go

[Tamschi]

It probably needs to be an intentional reservation by the user to have any teeth: https://www.gesetze-im-internet.de/englisch_urhg/englisch_urhg.html#p0328

(This is the English translation of the German implementation of an EU-wide copyright detail.)

[jenirainerpdx]

There is a statement in the proposal that intentions can be in a state of undefined, allow or disallow. If in a state of undefined, would the behavior default to disallow or allow? It seems preferable to default to disallow if you are using an opt-in approach.

[imax9000]

Related: bluesky-social/proposals#75

[OneDeuxTriSeiGo]

I'm glad intents are coming. My one suggestion would be that instead of pushing for opt-in or opt-out, default to no choice made and prompt the user on first open of their app after it rolls out to make a choice. And for UX purposes add an "ask me later" button so they can make their decision later (pushing the prompt to the next app launch unless they go to settings to make their choice).

[imax9000]

I'm not sure updatedAt field is going to be useful. But it leads me to another idea: specifying a timestamp up to/starting from which a specific intent applies. That would allow specifying things like "only bridge my posts made after 2024/12/31", "don't archive my posts from 2025".

[imax9000]

• these intents are account-wide for simplicity, not application-specific or configurable on individual pieces of content. Applications may have their own intent mechanisms.
• the available intents are a small currated set. They are not free-form, and there is not a direct extension mechanism.

These two points prohibit implementing an important use case: unified dashboard of your data reuse preferences. It would be very annoying to have to log into a gazillion different web pages just to check or uncheck a box, which would be buried in a different spot in each one of them.

[imax9000]

Following up to the above, having a fixed set of intents also does not accommodate another category of apps: the ones that don't require you to log in and don't quite fit into any of the defined intents. Requiring user credentials for the sole purpose of specifying intent in an app-specific record would give the app a lot more permissions that strictly necessary.

[imax9000]

For the protocol bridging specifically, please at least consider including per-protocol knobs in the generic record. E.g., allow users to say that they don't want to be bridged to Nostr regardless of which specific service is used.

This might be implemented as "hierarchical" entries:

  "protocolBridging": {
    "allow": true
  },
  "protocolBridging.nostr": {
    "allow": false
  },

List of protocol names would have to be also managed, to ensure that implementations don't end up using different names for the same thing, but that shouldn't be too much of a trouble.

[DGaffney]

lol - I'll bump it too while I'm getting blasted in my inbox @bnewbold User Intents wen

[hexdotooo]

This issue is getting a wave of attention today for some reason. If you want to support it, please give it (edit: not this comment! lol) a thumbs up 👍🏻 instead of posting comments that don't add anything substantive but still get emailed to all the subscribers. Thanks.

[adorablecyborg]

It was posted on Bluesky today to get people's attention to the proposal post-Attie announcement.

I suspect a lot of people who are about to come here don't understand the dev culture on GitHub. @bnewbold you may want to edit the opening post to encourage people to react if they have don't have anything further to add. Not a perfect solution, but easier to point to.

[FaeAlicia]

This would be great, honestly, but with one change. It seems to be mentioned already, but to voice my own support for this, this needs to be changed to be opt-in and any undefined value should be treated as false by default. Consent is paramount. A user that doesn't consent to being put in an AI database shouldn't be put in there for the same reason someone that doesn't consent to being thrown in the back of an unmarked van shouldn't be kidnapped. If you leave it ambiguous by default, malicious actors profit while the innocent suffer. No means no, but maybe also means no until such time an explicit yes is given.

[FaeAlicia]

There isn't really a concept of opt-in vs opt-out here. Technically speaking your choices are to A: say nothing, B: explicitly consent, or C: explicitly revoke consent. Whether option A is interpreted as implicit consent or implicit refusal of consent is up to the consumer.

I know that. I understand "undefined" has to exist. I'm just saying it should be treated the same as not giving consent in order to ensure legal protections for both the devs and the end users. The only reason Google and the like can get away with the data collection stuff they do is because they're a massive company backed by obscene amounts of money. Y'all aren't, so for the sake of not having to deal with legal headaches because you get sued for not informing someone their rights were being violated, stick with "undefined should be treated the same as the user hasn't consented."

[OneDeuxTriSeiGo]

Y'all aren't

Fwiw I'm not associated with bluesky the org. I'm just a dev/nerd in the greater atproto space who pitched in on this thread back in 2025 and I was chiming in when this thread got revived.

But yeah I agree that this is the stance/interpretation that bluesky themself should take and they should add it to their policy docs if/when this proposal is accepted.

My only caveat is that this proposal is not really tied to bluesky (the org) beyond one of their devs proposing it so it doesn't address bluesky (the org) policy. They mention this in the discussion section (below):

Intents explicitly and intentionally do not reference or rely on legal rights, such as copyright or amoral rights.

But I'd agree they should probably expound on this section to clarify that while there is no legal rights tied to the protocol implementation, infrastructure operators can and should adopt compliance policies based on them with a suggested interpretation included somewhere in the proposal. That suggested interpretation could be the interpretation that bluesky (the org) adopts if/when the proposal is accepted.

@bnewbold thoughts on this?

[FaeAlicia]

I'd like to add that due to Facebook successfully being sued by a single person for $3 million due to dark patterns messing up her childhood, protocol devs providing guidance for app devs is a legal requirement at this point. For distributed platforms, if no guidance is provided on the protocol level, it makes sense that they would be the highest, most upstream group to sue for damages from dark patterns.

[FaeAlicia]

And sorry for the wrong assumption. I've done some bug reporting and stuff for apps before, but this is my first time in such a big one and forgot to look for the badges to indicate who was actually part of the team and who's just part of the larger discussion.

[OneDeuxTriSeiGo]

Yeah I definitely agree in the value of prescribing recommended policy and guidance here. For AI related intents it certainly makes sense to recommend that people assume no explicit consent is the same as explicit no consent. For non-AI related intents however it may be less cut and dry.

For example with an "allow my content in discover (or other algorithmic feeds)" intent it may be acceptable to assume the "unspecified intent" is implicit consent. Or more likely a transition period could be established where unspecified intent is assumed to be consent (for say a year) with apps asking users without a specified intent each time they log in. Then after that transition period is over an unspecified intent can be assumed to be no consent. The risk in not doing this is that enacting the policy cuts off engagement for artists, etc and potentially harms income they depend on to survive.

And of course then other intents could be specified as "sub-intents" so you may say no to all algorithmic feeds but then allowlist specific feeds or vice-versa by blacklisting specific problematic feeds (cough discover cough).

[sharpiepls]

+1 for this feature implementation

[GreaterJoe]

Hello, yes, I would like this implemented.

[kfinn]

I would like this implemented!

[blaine]

I support this proposal, with the addition that I support all proposals in this vein: https://leaflet.pub/p/did:plc:3vdrgzr2zybocs45yfhcr6ur/3miowxyaoak2c

[sharpiepls]

love this!

[Lowenar]

Heck yeah I want this

[jeengland]

This is a great idea and should be implemented immediately

[iwcnOS]

I want this in bsky. In fact I want this as opt-in rather than opt-out

[watters]

Please implement this, posthaste.

SHOULD be opt-in, not opt-out.

[dkletter]

I would like to see this implemented immediately because I absolutely don’t consent to any of my public data being used for A.I. training.

[OneDeuxTriSeiGo]

I'm adding these links from bluesky because they are relevant and aren't currently included in the OP or the proposal:

• Update from @bnewbold on the proposal: https://bsky.app/profile/did:plc:44ybard66vv44zksje25o7dz/post/3mioy3vrdmk2d
• Demo interface for creating and modifying intents: https://demo.user-intents.org/
• Demo Impl PR: demo: add AI-PREF Content-Usage header based on user intent record social-app#8676

[gvelez17]

hey weighing in here i think user intents are super important :-). - expressing, and honoring, is actually easier to implement now with AI i think?

[tecknojock]

Yes please, I would like user intents supported by ATProto.