It's like… if I left my security configuration information at "close ports 22, 23, 25… (etc) on your firewall and block access to these sixteen websites, oh and you can only find this information by talking to me on a full moon" you'd look at me like I was from Mars.

But people accept the equivalent advice all of the time when it comes to configuring fediverse apps.

We can do better.

#SafErFediverse

I've talked a bit about how I think #blocklists are a "when you only have a hammer" solution to a problem and that we can do so much better than them for a lot of use cases. They can have a place, but they are a start, not an end.

But beyond even that we can do _so so much better_ than manually updated blocklists that people seem to expect everyone to absorb via osmosis.

I firmly believe our current situation is a recipe for burnout.

#FediverseMentalHealth

#SafErFediverse

There's this idea that "the first thing new instance admins should do is block <these servers>."

When we see (or make) a statement like this the first thing we need to do is figure out _how would they know to do that_.

The second thing we need to think of is "if that list is updated, how would they know?"

The third thing would be "how do instances get on the list or, once on it, how do they get off? How is _that_ information disseminated?"

#SafErFediverse

What if instead of opting _out_ of content and #federation (fediblock), instances had to opt _in_ to content and federation?

What I mean by that:

* Instead of "things appear in the federated timeline by default" it is "only servers that have been reviewed show up in the fedderated timeline."

* Instead of "follow requests require review if coming from a silenced server" it would be "non-mutual follow requests require review unless coming from a reviewed server."

#ActivityPub #SafErFediverse

If you think about it, this is a natural fit for the #Fediverse and for building a #SafErFediverse: with a centralized system you depend on a contract with the provider. A privacy policy. A set of terms of service. Those in many ways serve the provider, but they also exist to serve _you_. If nothing else because you can select for or against platforms that do things that are too onerous.

With the fediverse we have to think more broadly. We have to have mechanisms of communicating wishes here.

One of the problems with just flinging capability URLs around rather than the whole post (e.g., for #QuoteBoost limitations) is how to prevent a thundering herd from landing on small servers.

Sending a URL to another party is fine and good for ten people, but it creates a challenge for small servers when something goes "viral."

How can we solve this while thinking about a #SafErFediverse?

One way would be to offer cache permissions.

I should probably make something clear given my recent diving into protocol around #QuoteBoost and #SafErFediverse:

There is a conventionally accepted dogma that QRTs were a causal factor in harassment. I do not accept this assertion as such.

There are _aspects_ of it that may be true, but I think it is likely much more nuanced than a binary ans.

That said: I think playing with protocols is fun and I also think that there are a lot of things we can do to make things safer. Not just for this.

My latin for my #SafErFediverse work (part of my toy project) is coming along.