"privacy nutrition labels" for bots/apps/integrations, and an overview for how all the bots in a guild process your data

theoretically, for legal reasons, bot operators need to communicate to their users (guild administrators) how they use or persist user data. and guild admins need to communicate that with their users (e.g. in an onboarding/rules/welcome channel). most of the time this doesn't happen. and it can lead to users not being clearly informed of data collected about them. because people don't like writing or reading legal documents.

bots on Fluxer should be able to declare how they process and store and share user data. for instance, a moderation bot might state something like this:

• message contents are retained for up to 7 days, and viewable by community moderators for the purpose of investigating recent incidents.

or a bridge might state:

• message contents and basic user metadata will be shared to a public matrix room, where other servers may process your data in unknowable ways
• message contents and basic user metadata will be shared with Discord. their privacy policy describes how they process that data
  • (maybe one or two important points about how Discord's privacy policy differs from Fluxer in important ways)

when multiple bots are in a guild, these labels would be aggregated into a single easily-digestible view where users could see what information is used how and why and by which bot. it would also be a great place to link to those bots' full privacy policies (instead of having to hunt for them in the member list). it would also be nice to display this information before joining a guild. maybe it would make sense for bots to be able to declare this per-guild? that way, instead of a potentially long list of irrelevant things declared by a utility bot, each community would only show what that bot actually is configured to do in that guild. if the reasons are sufficiently specific enumerated options (instead of just freeform fields), it would even be possible to combine this information with permissions, and you could see "when i send messages in this channel, which bots process that and how". maybe a user could also be required to acknowledge the policies? if that's the case, and a bot is not active throughout an entire guild, users may be able to join a guild while "rejecting" a specific bot (maybe then, this bot can't even see that user on an API level? but really, this feature needn't actually gate off any API access; bots can just declare lies after all). then, before they can chat in a bridged channel, they'd be required to acknowledge a bridge's data usage. (i'm intentionally not using the term "privacy policy" here because i don't expect anyone to read a legal document before chatting. but, if the input box was locked behind a notice like "Messages will be bridged to Discord [Okay]", i think users are more likely to read it and understand that). the acknowledgement would be a good way to inform users when something important changes here. for example, if a bridge is added, we could make sure users are informed of this before they continue chatting. acknowledgement could of course lead to a certain fatigue of just clicking yes (please don't reinvent cookie banners!), which is why there needs to be guidelines on what should be declared. a good way to prevent bots from overusing the feature and not get the cookie banner problem, is to not require this labeling from all bots unilaterally. this feature (although it DOES address a legal requirement), is first and foremost about consent. let's make it easy for bots and communities to inform their users of how bots process data, but let's not force them to declare garbage information. as an example of a bot which shouldn't concern itself with this: i don't think a diceroller bot needs to tell you "if you use my slash command, i will respond to it and have your profile in memory when processing the command". the privacy labels should only be used for things that are not utterly obviously required; most notably when a bot processes actual conversations.

this idea is heavily inspired (down to the catchy name) by Apple's "privacy nutrition labels": https://www.apple.com/privacy/labels/ every app on their App Store must self-report how it processes user data in an easily digestable summary. other app stores implement this too, most notably Google Play.