Alternative room transports to full mesh (SPEC-45)

[matrixbot]

We shouldn't assume that every room will use full mesh. Ideally rooms should be have configuration along with the policy server explaining how to distribute events amongst the participating servers.

We could have a list of distribution protocols in the room config with two transports that servers MUST support:

1. The current full mesh transport.
2. A simple list of endpoints to pass events to.

Rooms SHOULD support at least one of these two transports. A server can then always join the room by falling back to the simple list of endpoints if it doesn't understand the other federation protocols in the room.

(Imported from https://matrix.org/jira/browse/SPEC-45)

(Reported by @NegativeMjark)

[matrixbot]

Jira watchers: @erikjohnston @NegativeMjark @ara4n

[matrixbot]

what is the use case for this? who is actually going to be implementing extensible room sync protocols? is it to let us rewrite the algo in future without breaking the world, or to allow folks implementing their own s2s APIs have an easier learning curve? or something else?

-- @ara4n

[matrixbot]

To allow alternative sync protocols in the future. I think it would be useful to allow servers to create rooms using newer protocols without having to worry about locking out older servers from those chat rooms.

-- @NegativeMjark

[matrixbot]

Ftr, there have been some vague suggestions around circular hashing, petri nets, clos switches or DHT-based routing thrown around, but nothing concrete afaik.

-- @ara4n

[ara4n]

Stuff happened around this for https://matrix.org/blog/2019/03/12/breaking-the-100bps-barrier-with-matrix-meshsim-coap-proxy/. We need to find someone to fund more work around it.