Eight tips about consent for fediverse developers
Eight tips about consent for fediverse developers
An opportunity? A minefield? Both!
If you're a developer working on a fediverse app or service and want to get it right – or just don't want to be the center of the next firestorm – here are a few suggestions.
I'm not sure there's a better way to put them, but I bristled at the two suggestions at a high level which tell me what to say or not say, and call out my being cis as a thing to be careful about.
I'm glad that I read them despite the bristling, because I found that they were things I wouldn't say or do, and they were reasonable suggestions.
But especially the cis comment made me kind of worried. As the platform grows these types of desired policies are going to be drowned out by the majorities.
All of the proposed solutions are intentionally not scalable ones, and seem designed to keep the platforms smaller and protected. This makes absolute sense especially when held up beside the marginalized peoples who are asking for them's experiences of being marginalized.
I hope that we can find ways that satisfy those needs even through growth. It would be interesting to see scalable opt-in solutions for this problem. It would especially be useful to integrate solutions into the protocol.
But in truth I was shocked to learn about robots.txt recently, and more shocked to hear how well-ish that type of solution worked until AI came along and ignored it. So it's anyone's guess as to how well similar solutions might work here.
Thanks for the feedback -- and thanks for reading them despite the bristling. I couldn't come up with a better way to put them ... I know they'll cause some people to tune out, but oh well, what can you do.
I don't think these solutions are inherently unscalable, it's more that there hasn't ever been a lot of effort put into figuring out how to make things scalable so we don't have any great suggestions yet. I wrote about this some in The free fediverses should focus on consent (including consent-based federation), privacy, and safety (the article is focused on instances that don't federate with Threads, but much of it including this section is true more generally):
There aren't yet a lot of good tools to make consent-based federation convenient scalable, but that's starting to change. Instance catalogs like The Bad Space and Fediseer, and emerging projects like the FIRES recommendation system. FSEP's design for an"approve followers" tool, could also easily be adapted for approving federation requests. ActivityPub spec co-author Erin Shepherd's suggestion of "letters of introduction", or something along the lines of the IndieWeb Vouch protocol, could also work well at the federation level. Db0's Can we improve the Fediverse Allow-List Model? and the the "fedifams" and caracoles I discuss in The free fediverses should support concentric federations of instances could help with scalability and making it easier for new instances to plug into a consent-based network.
(The post itself has links for most of these.)
Thank you for the thoughtful response here.
If it helps, I feel like "Be an ally if you're cis and joining the conversation" might fit what you're saying and wouldn't have bristled me. But I recognize that it isn't your responsibility to manage the emotions of people who have unquestioned privilege.
I also hope this isn't a weird question but I noticed that I have to turn my vpn off to see your site. Is that intentional?
On the other stuff, I love that you're talking about the importance of account migration, and I like the idea of the concentric federation.
There's a bit more in there about scalability. So it's nice to see your thoughts around it. I was thinking that the opt-in process which messages you for approval was the closest to scalable from the former article, because it allows everyone the opportunity to opt in without requiring hidden knowledge. But it could also feel like some sort of fishing attempt to get a message asking for consent.
So I guess finding a way to build opt-in into the protocol in some way would be the most scalable option in the long term. However that could work.
They all seem reasonable suggestions:
- Consent matters, even for public posts
- Get broad feedback before launching – and listen to it
- Honor existing opt-in and opt-out mechanisms
- Include an additional opt-in mechanism for your service if it's not just a search engine or profile discovery (or something very close to them)
- Make sure to communicate that you're taking an opt-in approach and honoring existing mechanisms
- DON'T say the things that developers who ignore consent typically say
- Be extra careful if you're a cis guy
- Look at opt-in as an opportunity for a potential competitive advantage
I'm conflicted over the fact that using ActivitiyPub necessarily implies consent for other people to collect the data you send through it. It seems that many people using ActivitiyPub connected services want something different than ActivitiyPub or different default settings on many ActivityPub services.
Thanks, glad you think they're reasonable. I don't see it as using ActivitiyPub implying consent; it's more that ActivityPub doesn't provide any mechanisms to enforce consent. So mechanisms like domain blocking, "authorized fetch", and local-only posts are all built on top of ActivityPub. I agree that many people want something different than ActivityPub currently provides, it'll be interesting to see how much the protocol evolves, how far people can go with the approach of building on top of the protocol, or whether there's shift over time to a different protocol which has more to say about safety, security, privacy, and consent.
That's similar to the "you're being inconsistent" thing that the article says not to say, kind of.
Consent isn't really built into ActivityPub and it's inherently the opposite of how I understand it to work (copying your content all over the place regardless of your desires).
But their argument is kind of reasonable.
Who cares?
We can change ActivityPub, but we couldn't change Twitter. People were tolerating worse just for the sake of having a community before they moved to the fediverse. They had no say before and they're asking for better from it now that they can have their voices heard at all.
Consent isn’t really built into ActivityPub and it’s inherently the opposite of how I understand it to work (copying your content all over the place regardless of your desires).
ActivityPub is a means of sharing information in a way that the information can easily be collected and reshared. By using it, you should expect that people will collect and reshare information you send via the ActivityPub protocol.