search

matrix-org / matrix-spec

The Matrix protocol specification
Apache License 2.0
182 stars 94 forks source link

Alternative room transports to full mesh (SPEC-45) #49

Open matrixbot opened 9 years ago

matrixbot commented 9 years ago

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 commented 9 years ago

Jira watchers: @erikjohnston @NegativeMjark @ara4n

matrixbot commented 9 years ago

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 commented 9 years ago

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 commented 8 years ago

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 commented 5 years ago

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.