Am collecting Mastodon server software feature requests - specifically for moderation enhancement that might be helpful as #Threads federates in.
Looking for those that can be doable inside a month or two timeframe, and that don't need #ActivtyPub spec to change first. (Which takes time)
See what you think of this list: and add any others you think fit to me in the comments.
https://docs.google.com/document/d/1bz0nl2SG-_CqJ7uqJvUskwXWXvXGFnpSJdafEiWWDD0/edit?usp=sharing
Recommendations for how Mastodon and other Fedivese solftware needs to evolve to deal with Threads
@tchambers, these are from the "Recommendations" section at the end of [Threat modeling Meta, the fediverse, and privacy (DRAFT)](https://privacy.thenexus.today/fediverse-threat-modeling-privacy-and-meta/#developers) -- the main text discusses the rationale (although, it's a draft).
* "Privacy by default": Set defaults so that people start with stronger privacy protections, and can then choose to give it up. For example, make "Authorized Fetch" the default setting, and ensure documention explains it well.
* Develop processes and tooling for blocking Meta instances and all instances that federate with them. For example, extend nodeinfo to have a field with an instance's policy towards Meta (transitively block, block but federate with instances that federate with Meta domains, federate with Meta domains). Investigate solutions for blocklists Meta and federating-with-Meta domains (taking into account that there are likely to be a huge number of them hosted on different domains), and for allow-lists for instances that don't share data with Meta
* Investigate shifting to allow-list federation, and look at alternative approaches like "approval first" federation.
* Reduce the number of public pages and the amount of data in them, including supporting private profiles, increasing use of non-public visibility like local-only posts, investigating new visibility levels like "viewable only to people logged into instances that don't federate with Meta", differentiating between what's shown at different levels of visibility, and (potentially) requiring login to view unlisted statuses
* Provide a usable way for instances and individual users to protect all profiles, timelines, statuses, images, etc from anonymous access.
* Provide control for individuals and sites to determine whether RSS feeds are available, and implement an option to remove unlisted statuses from RSS feeds
* Educate people on (and potentially package) existing processes and tools for IP Blocking, integrate with suspend/limit federation-level processes and infrastructure, and potentially develop new tools and look for ways to address downsides.
* Look at potential app-based dataflows and potential counter-measures, possibly including allow- and block-lists for apps as well
* Pursue funding from anti-surveillance-capitalism companies, civil society groups, governments, and crowdfunding to allow more detailed analysis, design, and rapid implementation of privacy and safety features – and ensure that the funding is directed in a way that increases equity and diversity.
* Press the project leaders to prioritize privacy and safety in their planning. If they don't, consider voting with your feet and creating a fork that prioritizes privacy and safety (as well as equity, usability, onboarding and all the other issues that need to be prioritized).
@thenexusofprivacy @fediverse @fediversenews @tchambers
Do I understand the second point correctly that the intention is isolate all instances federating with #threads from all instances not fecerating with #threads? Meaning, the goal is a hard split of the #fediverse?
Meaning, everybody (like me) who wants to be able to follow people from #threads will loose the ability of following people from "anti-#threads" instances?
@folkerschamel Yes you understand that idea correctly. Hundreds of instances have made it perfectly clear they don't want anything to do with Meta. With today's software, that's very likely to be needed to protect people who are at risk. Eugen's response in the blog post was disingenuous (or perhaps he just doesn't understand the issue).
Of course, software can evolve, but the extent of changes that are needed -- and the analysis that's needed to make sure they really do plug all the holes -- is unlikely to be completed in the timeframe Tim's talking about.
So yeah, it's very likely that you'll have to choose between following people on Threads or following people on instances who want nothing to do with Threads. Your desire to follow people there doesn't outweigh others' perspectives that they don't want to be exposed to something they consider risky and toxic.
I think your last paragraph has some important distinctions related to instance admins versus their own users if they defederate.
When this kind of thing comes up so many people focus on instance level blocking and moderation, that makes decisions for users, instead of ways of empowering users to shape their own experiences based on their own perspectives.
So when you talk about choosing between following which group of people, it just makes me think of how that might really translate to following the groups of users who have been allowed by their instances to participate more fully in the Fediverse system, forcing those users to choose as well, and it just sounds like a big old mess to me.
If we focus on empowering users instead then that does a lot to unwind those tricky social dynamics.
@volkris @thenexusofprivacy @folkerschamel While I’m in agreement with empowering users humans are complex and humans run the instances. There are admins completely against Meta, however hypocritical some stances may be. While a bad experience for the users, users are able to migrate to another instance and or self host. There’s not going to be much room for middle ground
Oh, my whole point is that empowering users IS the middle ground.
ActivityPub is sadly lacking in the ability of users to migrate between instances, even overlooking all of the issues involved in the positives for having instances in the first place, the communal aspect of it.
So, should the admin expose their users to Meta? Should they close it off? Meh, middle ground is letting each user choose what experience they want.
@thenexusofprivacy @folkerschamel
@volkris When you take the realities of today's software into account, though, that's not a middle ground -- people who want nothing to do with Meta are still exposed in some ways. Here's one example. Nobody's analyzed it all deeply, so there are almost certainly others. https://privacy.thenexus.today/just-blocking-threads-isnt-enough/
Agreed that ActivityPub allows the original instance to capture idenitity (which as @ricmac points out in https://thenewstack.io/threads-adopting-activitypub-makes-sense-but-wont-be-easy/ is why Meta loves it) but even so moving accounts could be a lot better than it is today so let's hope Meta's arrival spurs some improvements!
Well I think I am just not so quick to embrace deficiencies in the software of the moment. I would like to see improvements in the software, hopefully improvements that wouldn't actually take all that long to implement.
Surely UIs can be updated in a matter of weeks, not years, to give users more power instead of relying on administrators making those choices for swaths of users.
I'm just not so ready to give up on users having control of their experiences, especially in this environment where so many people are complaining about other platforms that they have left because of administrators taking that power over users.
@volkris 💯 on improving the software -- the recommendations section of [Threat modeling Meta, the fediverse, and privacy](https://privacy.thenexus.today/fediverse-threat-modeling-privacy-and-meta/#recommendations) has an initial list of changes that would be valuable -- for instances that federate with #Threads _and_ for instances that don't. But a lot of them have been requested by #Mastodon users since 2017-2018, and some may require #ActivityPub spec evolution, so don't hold your breath on weeks rather than years
In terms of choice, the way I look at it, if and when Meta does in fact federate (still an open question), people will probably have four choices:
1) communicate with their friends on Meta (from their acount on an instance that federates with Meta)
2) have an account on an instance that federates with Meta, but block Meta as individuals.
3) have an account on an instance that blocks Meta but doesn't transitively block instances that federate with Meta.
4) have an account on an instance that transitively blocks Meta and instances that federate with it. This is the safer than the other options.
Different people will make different choices. People who want to use their fediverse account to communicate with or follow people on Insta will tend choose #1 unless they think there are significant downsides. People who actively don't want that can choose between 2, 3, or 4 .
People who want nothing to do with Meta are likely to choose the safer option of transitive defederation so a lot of people want to choose 4 as the safest option -- at least until there's a thorough analysis of privacy risks, and other risks too. And who knows how long that will take, and for that matter how likely is it that Meta will actually cooperate enough to allow a thorough analysis. Unless and until that happens, a lot of people will choose to be on instances that transitively defederate.
@ricmac @dame @folkerschamel