the tricky part is finding time/focus (big work thing happening this week which is eating a bunch of my time). should I not manage to get around to it, though, I guess I may as well write up design thoughts so anyone else can try it too. this will be for a sorta v1/try-it-out design. it will eventually need iteration (because if it works, this shit will arms-race just like adblockers)

design considerations:

• threads has all of meta ip space to come from (as well as any cloud scaleout they wish to spend on)
• threads/fb/meta will behave badly at some point
• spoon availability to dig into and modify any existing fedi codebases (at least beyond seeing activitypub response formats used): 0

since they have all that IP space to use, it makes the most sense to match response for all of it. thus: hitting by ASN (or objects registered to such ASN) is probably the best wide hammer. the nginx geoip module (and the geoip2 module…) doesn’t support ASN matches, and would be unwieldy. the geo module however does have an include statement which can read from a file - this might prove to be a better approach by which to classify source traffic. this file can then be updated separately, with an update kick to nginx whenever needed

once matching the client is done, the request can then be handled and responded to as needed. whether this needs to be a sub-application responding, or could be done by nginx config statements alone, I’m not sure yet. need to look into the request response surface area in activitypub before I can detail that