Mauve 👁💜 @mauve@mastodon.mauve.moe

@tychi Gonna be me when I skill switch into programming cellular automata for photonic computers. 🥰🥰

https://www.nature.com/articles/s41377-023-01180-9

@hank Yup! I think as @thisismissem alluded to the only challenge is getting folks to actually adopt such a strategy. :P

@thisismissem Yeah! Exactly. At the very least the inbox level block will help reduce how much your posts get pushed to those instances and their global timelines.

To be clear though, this will just be on the SocialInbox server to preemtively filter out replies and follow requests from such instances.

Sadly we need a whole new approach to figure out how to prevent instances like this from reading your posts since all your data is available via ActivityPub and HTML on the #dweb. 😅

Huge thanks for folks/ input on this. We're going to start with the mastodon blocklist format version of gardenfence and go from there.

We'll have a flag for folks to toggle during setup for pulling from a URL and have it set to this one by default:

https://github.com/gardenfence/blocklist/blob/main/gardenfence-mastodon.csv

@thisismissem Dang yeah having all these domains in a list seems like a great way for folks seeking out communities like that to find each other 🥶 Ah well, we'll adopt whatever new thing comes along once we get to it!

@thisismissem Yeah good point. Any benefits to mastodon's format instead of the fediblocksync format? I assume the mastodon one is more widely deployed at this point?

I came across one a while ago but it seems to be run by some folks that I don't think I could trust or even mention in any professional contexts. :/

I was kinda hoping #FediDB would be tracking something like this but I didn't see anything in their api

@j3j5 Yeah defs a fan of this project and into integrating at some point. For the moment I'd like to reduce the overall size of the blocklist and focus on something with a bit less nuance like "the top most blocked instances" since it's easier to grock without nuance IMO.

Ideally instance operators would then add / remove more allowed/blocked instances from there.

@j3j5 Yeah defs a fan of the bad space. I think my only concern is that there isn't much insight into where it comes from and how much "shared reality" there is. IMO "the top most blocked instances" is an easier sell for folks just getting started + reduces the overall size of your blocklist.

Very much into integrating with it as stuff progresses and stabilizes though.

@trevorflowers Phantom decoration syndrome?

Anyone got an API endpoint of the "most blocked instances" handy? I wanna add it to the initialization flow for the #DistributedPress #SocialInbox

Ideally it'd be nice to say "Here's the top 100 most hated instances so you can preemptively block them if you'd like". It's not perfect but I think this would make it easier for small publishers to get started.

#ActivityPub #moderation #mastodon #fediblock

@happyborg One hard part is how to intoduce yourself to a person for the first time. If you query folloed of followed outboxes for incoming follow requests a la ssb it's not too bad, but when it's a total stranger you need a central randevous point. There's a bunch of approaches but I wrote one up here: https://medium.com/@RangerMauve/p2p-inboxes-be0f02083223

@happyborg Yeah great points. I'm working on a gradual transition timeline where we start at where the current fediverse is and gradually go full p2p.

I think before we replace the current inbox flow we can have more put into indexed outboxes for fast sync so instead of waiting for pushes from the accounts you follow you can get a quick pull for just the data you want and leverage the social graph for loading all that info.

Inboxes do live updates, outboxes are for sync when you come online.

@happyborg That's the hope yeah. We're reducing the surface of the bits of AP that need to use a central server as much as possible. Right now the inbox is hosted in the cloud but it could just as easily run on your device and servers could acc3ess it over p2p if they support that or via http gateways.

Similar approach for the published AP data. Initially instances will load over https but we'll be adding specs to include p2p urls for all your data which some clients can load directly.

We've got a new #ActivityPub implementation that'll be released in early September in #DistributedPress!

Instead of fancy frontends and databases, we're focusing on enabling statically published sites to add AP support via a lightweight Social Inbox server that they can register using standard HTTP Signed Messages.