gemini://gemini.dimakrasner.com/threads-ap.gmi

I don't see an immediate problem if the ActivityPub implementation you use ignores posts from a user without followers: if user A on server B sends a post to user C on server D but D ignores posts from A (instead of saving and displaying them) because C doesn't follow A (and nobody else on D does), B can't flood D with content (like ads or opinions most users on D disagree with). I don't know how Mastodon, Lemmy, etc' behave but I believe most big servers have basic protection like rate limiting, in case Threads floods them with content. However, the fediverse is very malleable, and Threads can introduce ActivityPub extensions that can be used for things like tracking, and create a situation where servers that don't support these extensions can't federate with Threads, forcing servers to choose between losing users (who have many friends on Threads and prefer compatibility) or implementing extensions that make money for Meta.

It's a mistake to think that ActivityPub is one "thing" or a protocol like HTTP or Gemini. In general, I find the ActivityPub W3C spec to be very vague, with many loose ends. The fediverse is a big ecosystem of applications that talk to each other, don't understand each other 100%, but agree on some shared core protocol and shared data structures, both with a huge number of extensions. This core is the W3C spec plus many undocumented or "unofficial" extensions. For example, as far as I know, polls are a Mastodon extension but other ActivityPub implementations mimic Mastodon's behavior to make polls work. ActivityPub implementations are free to introduce extensions, and a "big whale" like Mastodon can force the "fish" to implement these extensions (for example, Mastodon's requirement of HTTP signatures). Mastodon's implementation of the spec and Mastodon's extensions are the de-facto standard the ecosystem follows, the W3C spec is mostly useful as an introduction to concepts like "actors" and "activities". Therefore, history can repeat itself and Threads can join the "big whale" gang (or become the only "big whale") but proceed from the "embrace" and "extend" parts to the "extinguish" part if the ecosystem refuses to comply with its money-making-via-extensions roadmap.

I don't know if interoperability with Threads is good or bad: time will tell, but now is a good time to update the ActivityPub spec from 2018 to match the current state of the fediverse, or at least create an unofficial "update" of the spec if the W3C process takes too much time. I see the FEP process as an attempt to standardize the current state by translating some of the requirements from a Mastodon-compatible ActivityPub implementation into independent specs and expand on that (for example, through data portability and integrity extensions). The list of FEPs is (still?) not a place where one can find a list of necessary and sufficient conditions an implementation must meet to be 100% interoperable with most of the fediverse, but this sounds doable to me. If Threads introduces controversial extensions, the FEP process looks like a promising way to draw a line in the sand, between the "free" part of the fediverse and the Threads-controlled part, the one with extensions implementers might want to ignore or sabotage (for example, by dropping metadata used for tracking purposes when forwarding posts to other servers).

Thoughts about Threads