Some users have concerns about how their content or personal info is used. For example, some users do not want the content they created to be used for training generative AI systems, and some users do not want to have their personal information shared or sold.

In centralized systems, a user can indicate preferences and/or opt outs with an HTTP header on their own client, or apply settings to their own account on a server to have the HTTP header set by that server. However, in ActivityPub a user's content is federated across servers, so an HTTP header set by the user or on their home instance would be visible only in the original session.

Another problem with trying to standardize a set of preferences and opt outs for ActivityPub would be keeping a list up to date with all the available possible choices for all users. It's hard to know in advance what options a user will choose to exercise.

One possible way to make it work would be to extend section 3.1 of the spec, to allow information equivalent to HTTP headers to travel along with an object.

An object MAY have an http-equiv property, which is a list of header name-value pairs. A server MUST process that object as if it had been received over an HTTP connection with that header name set to that value.

For example, a user who chose to express a preference that their content not be used for AI training, and that their information not be shared or sold, could send something like this:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Note",
  "content": "Don't surveil me bro",
  "http-equiv": [{"X-Robots-Tag": "noai"}, {"Sec-GPC": 1}]
}