To get feedback! I often send out drafts to newsletter subscribers and post them on Mastodon and in the !thenexusofprivacy@lemmy.blahaj.zone community ... I got a lot of good feedback on this one which is incorporated in the revised version.

Mutuals-only posts would be useful, and have been requested since 2018 if not earlier. As @ShittyKopper points out there are challenges; Claire's 2020 comment https://github.com/mastodon/mastodon/issues/7135#issuecomment-636767048 discusses the issues in more detail. Then again some other fediverse software has them already ... and Claire's comparison to follower-only posts highlights that it could be done, it's just not a priority. So this is another good example of something that's not likely to get addressed with today's structure, and potentially could be a fork with different priorities -- if resources are avaialble, which is of course a big if.

Thanks for the tipoff on having to turn off the VPN, it's not at all intentional -- and it's not a good look for a site with privacy in its name! I'll try to figure out what's going on, it's pretty vanilla Ghost / nginx hosted on a Digital Ocean droplet so not immediately obvious.

And yeah, it'll be interesting to see how well the messaging you for approval works out in practice. As you could say it could look like phishing; and even if it's fine when just one app is doing it, it'll be annoying if there are hundreds. Also, there's a Mastodon setting to silently ignore DMs (and I think other platforms have similar options as well). And for Bridgy Fed, it would be great to have a mechanism that works symmetrically between the fediverse and Bluesky ... but Bluesky doesn't have DMs. Tricky!

I should probably mention something about being a good ally in that section, that's a good suggestion. That's not the main message I'm trying to convey though, I really do mean it as a warning to cis guys to be careful. These firestorms are tiresome for everybody, ould we please just not? Also btw sometimes particularly unpleasant for whoever sets them off. But maybe there's a better way to word it.

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.

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.)

Preemption is bonkers from a privacy perspective, and also flies in the face of the basic principle that the states are "the laboratories of democracy." But from a corporate perspective preemption is wonderful ... it keeps pesky pro-privacy states like California and Washington from ever raising the bar above whatever can get through Congress! So historically privacy advocates and organizations have always opposed preemptive federal legislation. But that wall cracked in 2022, where EPIC Privacy joined pro-industry privacy orgs like Future of Privacy Forum to support a preemptive bill (although EFF and ACLU continued to oppose the preemptive aspects).

The argument for supporting a preemptive bill (not that I agree with it, I'm just relaying it) is that the federal bill is stronger than state privacy bills (California unsurprisingly disagreed), and many states won't pass any privacy bill. Industry hates preemption, industry hates the idea of a private right of action where people can sue companies, most Republicans and corporate Democrats will do what industry wants, so the only way to pass a bill is to include at most one of those. So the only way to get that level of privacy protection for everybody is for people in California, Maine, Illinois, etc, to give up some of their existing protection, and for people in Washington etc to give up the chance of passing stronger consumer privacy laws in the future. California of course didn't like that (neither did other states but California has a lot of votes in Congress), and Cantwell's staffers also told us in Washington that she was opposed to any preemptive bill, so things deadlocked in 2022.

With this bill, I'm not sure why Cantwell's position has changed -- we're trying to set up a meeting with her, if we find out I'll let you know. I'm also not sure whether the changes in this bill are enough to get California on board. So, we shall see.

Sorry about that -- and thanks for letting me know, it was down briefly but got back on its feet fairly quickly!

Thanks! Here's how it looks:

Great example of how there isn't any one right answer here, it's different for different instances. Can I quote this in the "What will instances do? Opinions differ!" section of https://privacy.thenexus.today/should-the-fediverse-welcome-surveillance-capitalism ?

Agreed that there isn't one particular model that's right or wrong for everybody, and that a split is likely -- a region like today's fedi and that welcomes Threads, and a more safety-focused region (with more blocking, a more consent-based federation).

And, it gives cops another excuse to overpolice Black and brown neighborhoods.

There have been other waves, it's just that once they get shut down everybody loses interest and moves on. The PR for the one of the changes Mastodon just made was implemented in May 2023 after the Doge spam wave. And here's a June 2019 post talking about exactly the same kind of attack: "The problem we are experiencing is the spammer signing up on random open instances and sending spam remotely."

A very good idea! https://startrek.website/ took this approach, it'd be intersting to check in with them to see what they learned.

I had shared the draft version here a few weeks ago, and this incorporates some of the feedback -- including "This goes against everything the Fediverse stands for" 😎

It's true, but the time pressure is likely to be used to try to get a weak "compromise" bill through.

Yep. But, even though I didn't suggest it, I didn't explicitly say that it didn't mean global blocklists. So I clarified it, and added a footnote with more detial.

As Instance-level federation decisions reflect norms, policies, interpretations, and (sometimes) strategy discusses, opinions differ on the definition of "bad actor." So the best approach is probably going to present the admin of a new instance with a range of recommendations to choose between based on their preference. Software platforms should provide an initial vetted list (along with enough information for a new admin to do something sensible), and hosting companies and third-party recommenders should also be able provide alternatives.

Yes, at least on Lemmy. It's the icon with two boxes.

No, as the article says at the very beginning, it's that I think a big reason that fediverse isn't growing is its failure to deal with safety.

Nonsense. Instance blocklists are used across the fediverse today. They're certainly not a perfect solution but they have the advantage of actually existing. See Blocklists in the fediverse for a lot more discussion.

Fediblockhole does something along those lines for on Mastodon ... not sure if there's an equivlaent in the Lemmy world.