Alternative federation transport #529

Closed
opened 2019-01-17 10:14:34 +00:00 by lambadalambda · 6 comments

Right now, federation mostly works by POSTing to other servers inboxes with a signed version of the AP json. This is rather costly, because it involves:

  1. Signing the JSON
  2. Establishing and HTTP connection
  3. Sending the data
  4. Closing the HTTP connection

Depending on your setup, the connection can sometimes be used again from the pool, so only the signing part remains.

When I post something on soykaf, it will federate to nearly a thousand servers and will take a long time because of that.

It would be good to have an alternative transport that keeps a connection between servers and authenticates the connection itself, not the specific request, so that we can send the same json to all servers connected this way.

One obvious way for us would be to use phoenix channels, which already have this kind of authentication system built in. Another way would be to just do another custom websocket protocol for this, which should not be too hard either. Pure TCP or UDP could make sense, but would probably be hard to implement for other servers and would involve opening more ports.

Right now, federation mostly works by POSTing to other servers inboxes with a signed version of the AP json. This is rather costly, because it involves: 1. Signing the JSON 2. Establishing and HTTP connection 3. Sending the data 4. Closing the HTTP connection Depending on your setup, the connection can sometimes be used again from the pool, so only the signing part remains. When I post something on soykaf, it will federate to nearly a thousand servers and will take a long time because of that. It would be good to have an alternative transport that keeps a connection between servers and authenticates the connection itself, not the specific request, so that we can send the same json to all servers connected this way. One obvious way for us would be to use phoenix channels, which already have this kind of authentication system built in. Another way would be to just do another custom websocket protocol for this, which should not be too hard either. Pure TCP or UDP could make sense, but would probably be hard to implement for other servers and would involve opening more ports.
Member

I like the idea, but I think that we should use a websocket protocol instead of a phoenix channel.

Have per-server actors, and add a new streamingInbox endpoint.

Could probably standardize in litepub, what do you think @lanodan?

I like the idea, but I think that we should use a websocket protocol instead of a phoenix channel. Have per-server actors, and add a new `streamingInbox` endpoint. Could probably standardize in litepub, what do you think @lanodan?
Author
Owner

Litepub seems like a good place for that. I'll prototype something next week and we can go from there.

Litepub seems like a good place for that. I'll prototype something next week and we can go from there.
Owner

👍 on having it into LitePub.

But I think maybe we should try to have the streamingInbox into nodeinfo instead of a fake actor. (even if yeah gargron vs. nodeinfo but hey he didn’t want collapsable posts either)

:+1: on having it into LitePub. But I think maybe we should try to have the streamingInbox into nodeinfo instead of a fake actor. (even if yeah gargron vs. nodeinfo but hey he didn’t want collapsable posts either)
Member

Not on fake actor, but on actors themselves:

{
  "endpoints": {
    "sharedInbox": "https://example.social/inbox",
    "streamingInbox": "https://example.social/inbox"
  }
}

The server actors are to allow for the pre-authentication (without using some random actor's keypair).

Not on fake actor, but on actors themselves: ``` { "endpoints": { "sharedInbox": "https://example.social/inbox", "streamingInbox": "https://example.social/inbox" } } ``` The server actors are to allow for the pre-authentication (without using some random actor's keypair).
Author
Owner

related to #5786

related to #5786
Author
Owner

#5786 got merged, closing this for more concrete issues.

#5786 got merged, closing this for more concrete issues.
Sign in to join this conversation.
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pleroma/pleroma#529
No description provided.