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 @thenexusofprivacy @fediverse @fediversenews
I too disagree with that Folker but trying to focus on other items out of the issue of blocking Threads here.
@tchambers @thenexusofprivacy @fediverse @fediversenews
I'm just not sure if I understand the problem this list is trying to solve. As pointed out by #Eugen, #mastodon is already based on "don't trust other servers".
I think you might be echoing my own observation that so many people are getting so upset about Threads without Knowing what substantial issues they are actually getting upset about. I don't think they understand the problems that they are yelling so loudly about.
But I also wanted to say that ActivityPub is built on an awful lot of trusting of other instances, so that Mastodon must be as well.
For example, respecting of post audience and deletion requests are all based on trusting the remote instances to do the right thing and honor those requests.
And I think more users need to realize that as they put their content into this system.
@volkris I very much agree that a lot of people don't understand the problems. As far as I know the draft privacy threat model I did is the only analysis out there -- and it doesn't really focus on issues like hate speech or promotional posts. Also it's a draft, so needs improvement, and as I point out also needs to be followed up on with more detailed funded analysis!
https://privacy.thenexus.today/fediverse-threat-modeling-privacy-and-meta/
To be clear, I'm not talking about anything related to Meta. I'm referring to the longstanding issues of people posting things here without realizing that what they are posting has such little privacy guards around it.
It's just the core of how ActivityPub was designed, and there's not much to do about it at this point except make sure users are more informed about how it works.
Heck, I wouldn't be surprised at all if Meta is MORE trustworthy and well-behaved than many ActivityPub instances out there since they are under public and legal scrutiny, unlike some random instance running in someone's bedroom vacuuming up even audience restricted content for who knows what purpose.
I don't know that the intense focus on Meta would bring effective solutions that would also address the general issues.
Technically, yes it is a challenging problem to address. No two ways about that.
But that's one reason I emphasize education. At the least I want users to know what they are getting into, and with the numbers of people I find surprised by it, clearly what we are doing so far to have warnings in UIs and such hasn't been enough.
The drama over Threads is bringing up that disconnect between privacy expectations and realities once again.
@volkris 💯 Here's an exceerpt from the threat modeling post:
@volkris @thenexusofprivacy @folkerschamel
Agree on education being key…. Even public local only ones that don’t federate are, well, public. Anything in open HTML will be scraped by LLM’s etc.
@volkris There's a lot that could be done about it. Developers have just chosen not to. One of the points I make in the threat model post is taht it's time to change that -- and looking at the threats from Meta reveals a lot of improvements that help more generally as well.
I agree that a lot of activitypub instances are worse than Meta in some important ways, but then again (as I also discuss) well-configured and well-moderated instances running forks like Hometown are a lot better than Meta from a privacy and safety perspective (even despite the issues in today's software). But that's not the experience of most ActivityPub users.
@volkris @thenexusofprivacy @folkerschamel An issue as I grasp it common to public posts on other decentralized systems too - BlueSky and even (I think Nostr) ….but others who know both protocols better can chime in.