Lady, EVOLVED @Lady@cat.family

Some folks have speculated that we may have added some logic to #GoToSocial to refuse federation with threads, since GtS and Threads cannot federate together. We have not! We may in the future set federation with threads.net to "off" by default, and have this setting be adjustable by admins (with a link to Threads ToS for third-party services), but we haven't done anything like this yet.

It seems that as of the moment of writing, Threads responds to requests for ActivityPub representations -- requests which work just fine for all the fedi softwares we know about -- with a huge chunk of html+CSS. Of course GoToSocial doesn't parse this response as JSON, and therefore lookup of Threads users from GoToSocial fails. Likely Threads is requiring something very fussy with its Accept headers, or there's some other small issue preventing Threads from understanding GtS's outgoing HTTP requests. We haven't investigated it yet, because frankly getting federation working with Threads is not at all a priority for us.

Apparently some other fedi server devs have already implemented workarounds on their side for this issue, which brings up a rather tricky point: Is it the responsibility of open source fedi server developers to implement workarounds for Threads? In other words, is it for fedi devs to debug Threads' black-box implementation of ActivityPub for them, when Threads is closed source, for-profit, and not free?

Personally I would say no, it's not our responsibility, since Meta is an enormously large company with paid engineers working on this. In my view, if their implementation does not work with existing ActivityPub implementations (which mostly work fine with one another in this ecosystem we've created), it is their responsibility to fix their implementation, not ours.

At GoToSocial we work really hard to debug and fix compatibility issues with other open source fedi projects, within a reasonable scope and to the best of our abilities. Where the protocol is unclear (and AP is a protocol which is notoriously open to different interpretations), we try to err on the side of being generous in what we accept, and strict in what we send out, and to provide reasonable fallback behavior. We spend a lot of time poring through the code of other implementations, checking logs, trying to narrow down issues, etc. We would expect Threads to do the same.

This brings up another point: When this sort of thing happens (some federation bug or other issue), who do people assume is at fault? In other words, who wrote the bug: the big corporation, or the open source developers?

The power dynamics here are interesting. Based on my purely anecdotal (!) experience of seeing comments on such matters over the years, people tend to assume that developers at big corporations write code with fewer bugs than independent open source devs, and that corporate code is more reliable and more "technically correct". For better or worse, they seem to tend to view open source developers as being more amateurish and slapdash, and corporate developers as being more disciplined and by-the-book.

In a case like this, where open source implementations of a protocol are federating with a corporate implementation of a protocol, it seems likely to me that folks will generally assume that the "amateurish" open source developers are at fault if something does not work properly. If Threads, owned by Meta/Facebook puts something out there, it must be correct, right?

So already the burden of fixing things may fall disproportionately on the open source devs; and already even at this very early stage, we can get a feeling for the sort of weight that big corporations have to throw around, when it comes to interoperability matters. They have the money, the PR, the personnel, the reputation, all that stuff, and folks will tend to assume that they're in the right, without really interrogating that assumption for truth.

This is sort of worrying, and I don't really have a neat way to tie up this long post. I suppose I would caution folks against assuming that code produced by corporations is automatically more correct than code written by small independent groups. And I'd also caution folks to be aware of the power imbalances that are entering play here. It's not going to be an easy time for fedi devs.