@tost@mk.toast.cafe @puniko @ada @cleo mastodon sends out deletes¹ to all³ known² instances, and people hate that shit, they call it a "DDoS"
¹ maybe only actor deletes, idk
² this gets done in statusreachfinder and accountreachfinder i think?
³ "all" is the current strat but there is some work being done to use a bloom filter to send only to "probable" instances that may have fetched the actor before, and also another idea to have AUTHORIZED_FETCH but for actors only?
@trwnh@mastodon.social @tost@mk.toast.cafe @puniko@mk.absturztau.be @ada@blahaj.zone i think we should add this to calckey, but A) no spoons again to make a issue for that, and B) prolly huge discussion on how to do it here again, but doing the foundkey way for now works fine, its not a DDOS lmao, me having a delayed queue of now 1.4k is a ddos.
@cleo @ada @puniko @tost@mk.toast.cafe there have been multiple issues complaining about how fedi does both link previews and also Deletes. sometimes to servers that arent even fedi anymore. the "health check" is a good idea to mark certain domains undeliverable bc i think either masto or oma sill keep trying basically forever. i ran a nextcloud social briefly and it still gets requests. i forget which magic HTTP response code will get mastodon to stop, and idk what others do
@trwnh@mastodon.social @ada@blahaj.zone @puniko@mk.absturztau.be @tost@mk.toast.cafe try the I am a teapot status code lmao
@trwnh@mastodon.social @cleo@bz.pawdev.me @tost@mk.toast.cafe
i'm not sure "health check" is the correct term for what we do. we don't go probe the instance actively.
misskey already has been keeping track of the last HTTP status returned by any of an instances inbox URLs as well as the last time of successful communication (inbox or outbox). we just make use of that data to determine if we should send stuff to a particular instance.
we will stop sending stuff to an instance if we
- receive HTTP 410 from any inbox
- dont successful communicate for >7d
@tost@mk.toast.cafe @puniko @ada @cleo but in any case the "reality" inside and outside of any software rn is that you have no idea who fetched any given public status without authentication. even sending a delete to everyone you know will not be enough. sending to followers is the bare minimum.
if you require signed fetches then you can track who fetched any given object (status or account) but no one actually does this yet afaik. also you will still fail to account for inbox forwarding insofar as it exists
@trwnh@mastodon.social @tost@mk.toast.cafe @puniko@mk.absturztau.be @ada@blahaj.zone actually, we do require signed fetches, well at least thats a thing you can enable, the issue with that is, when you do that there is a chance that relays break
@tedu i suppose that's another way to do it, but user agent can be faked and already has been iirc? although you could argue that proxy signing is also possible so even that is not 100%
@trwnh@mastodon.social @tedu@honk.tedunangst.com useragent is being faked in the wild by prominent instances
@natalie yeah there's activitypub-proxy and also a lot of those "fedi search engines" pretend to be firefox or chrome
@tedu i was thinking more like "i am pretending to be some other domain so please send alllllll your deletes there :)" as a way to amplify traffic toward a certain domain