GitLab

For SoAR the planning_configuration was broadcast meaning all clients receive the message regardless of subscription.

In the proposed structure a broadcast message would be sent to all relay adapters and the relay adapters would broadcast to every project backbone.

The same is true for a broadcast message inbound from a project backbone. (Intended for things like aborts). If someone in a project backbone broadcasts an abort then each the relay adapter would re-broadcast it on internal and then other project relays would re-broadcast it on the other project backbones.

Ideally we don't want any logic embedded in the relay adapters.

moved from backbone-message-format#79 (moved)

We could populate the header.destination field with the project prefix and then have the relay broadcast know it's project and only re-broadcast messages for its project. This is a pretty easy fix but does mean the relay adapters have a small amount of thinking.

The above also solves the inbound broadcast since the message would be re-broadcast on internal to all the relays but the relays wouldn't forward if not for their project.

This does mean we have to solve the forwarded source problem. Do the relays replace the source with their own client_id or do they relay the message with the header unaltered identifying the original project client_id?

I think if the relays forward unaltered then a) that would break my proposed auth test to check that the header.source matched the sending credentials and b) we'd need to handle the case that the relay who broadcast the message didn't receive the message and then broadcast it back the other way in an infinite loop

The broadcasting client receives the broadcast message. We could make the adapter ignore this (sent-by-me) message provided we can tell it was sent by me. That also doesn't work with demoing via the send button in hydrogen. We want the message sent by hydrogen to be received by hydrogen.