Is websocket federation the right way to do signed connections or are there better alternatives?

I've been thinking if websocket federation is an overkill solution for the problem it tries to solve. We need to re-implement all the failure states and functionality since we can't reuse much of the endpoint logic. All of that is necessary for one reason: eliminate the signing overhead by confirming the identity of the server instead of signing each payload with actor's key. However, it seems overkill for that. We could just use TLS client certificates to prove the identity of the server with no additional overhead and continue to use our HTTP infrastructure. The only problems with this solutions also apply to websocket federation:

1. This will need nginx config changes to pass the client cert to the application.
2. This will need some kind of capability negotiation (could probably add a property to the inbox of the actor, or even have a separate tlsInbox/lightInbox)

The only benefit of websocket federation I see is if we want to implement some kind of realtime communication in the future. But things like typing notifications can be implemented with HTTP without much trouble and anything more realtime (like calls) will probably require it's own non-AP protocol anyway.

Upon discussing this on irc with @lambadalambda he suggested to "exchange a bearer token between servers and use that to securely identify the server" because it's "easy to implement for others and easier to understand". I don't really see how an additional token you need to have a way to exchange and store somewhere is easier than using a proof you already have anyway, but this is up for discussion.

So in this issue I want to gather thoughts on whether we should:

• Abandon websocket federation and use TLS client cert auth/bearer tokens
• Continue with websocket federation because...
• Something else?