I am currently implementing federation and am struggling with what I think may be the same headaches over and over again. I bet they would sound familiar.
So I’d like to propose some guidelines which I’d love to hear your take on and maybe evolve into something like federation best practices.
Every server development project that wants to be federated with should IMO
welcome federation, both, many instances as well as many products,
provide accounts to send questions to and respond on topic within some days,
provide accounts that are legit to develop against, run by this very server software and the server-software-developers can inspect the logfiles,
put explicit timeouts and retry limits on everything.
provide actionable error responses,
be explicit about their ActivityPub compliance and requirements on the project page,
refrain from making non-ActivityPub nice-to-haves mandatory (nodeinfo, host-meta)
refrain from being finnicky without hard reason with tangible benefit,
be precise and concise on the wire,
Each project may make this pledge and tag it #FederateMe. This community may mail a list halfyearly.
I like the idea, but some of the items are less clear to me than others.
Maybe an alternative for #3 could be a pledge to document how to self-host the server for testing purposes. It doesn’t seem fair to require server software developers to inspect log files for federation attempts (I assume to answer questions related to pledge item #2) or to pay for server hosting for other developers.
I like #5, but I don’t know how it can be done effectively with AP (in general). Many servers offload activity processing to background threads prior to doing full validation. AP doesn’t have explicit support for asynchronous feedback to the activity poster. (I’ve wondered if Reject could be used for this purpose.) The servers that do insufficient validation prior to async offload could modify their implementation to provide somewhat better error messages but it’s not likely to happen. I’m talking about validation errors, but providing delivery error information would be even more difficult.
Is Webfinger included in #7? That’s not part of AP and not required by it, even implicitly. I’m assuming you want to include it because Mastodon requires it for federation.
What did you have in mind for #9? I agree with it, but I assume there’s something specific that prompted you to add that item.
thanks, your response is 100% spot on, your concerns are why I raised it.
Example #3 - if those choosing the tech stack are unable to reliably operate a single node, familiar with it as they are, with limited capacity and uptime guaranties, it is not fair to demand that from others maybe having chosen different approaches for reasons . Same with #5 - if there are only cumbersome ways to find about what on, that approach is doomed. Also setting up and maintaining dozens of servers and versions the respective authors themselves find unfair to operate isn’t fair either. And those developers know their dependencies and system requirements including the implicit, forgotten or outdated ones.
If the software developers don’t embrace being federated with (by others), there is a problem from the start painfully mitigated later on.
#7 includes webfinger - it should not be mandatory for federation or be called out such. Both in the standard as well as the implementations.
#9 general attitude. e.g. don’t return 200 Ok on an Accept activity without doing anything further. (including the logs inspected by an operator).