In Beaker's implementation of PeerSocket, we need each app to operate separately from each other. They need to join/leave swarm topics separately, and use the sockets separately.
In practice, I think this means
Beaker needs to reference count the lobby joins and exit swarm topics when all tabs have left a lobby.
The messaging protocol needs multiplexing support so that Beaker can parcel out the sub-sockets to apps.
The wire protocol that Beaker is currently constructing for PeerSockets is two layers.
Messaging framing with length-prefixes
Protobuf schemas for individual message types (currently PeerSocketMessage and PeerSocketSessionData)
I think we could handle multiplexing by adding channels to the protobuf schemas, in which case this doesn't need to be implemented in Hyperswarm itself.
mafintosh
commented
4 years ago
In Beaker's implementation of
PeerSocket, we need each app to operate separately from each other. They need to join/leave swarm topics separately, and use the sockets separately.In practice, I think this means
The wire protocol that Beaker is currently constructing for PeerSockets is two layers.
PeerSocketMessageandPeerSocketSessionData)I think we could handle multiplexing by adding channels to the protobuf schemas, in which case this doesn't need to be implemented in Hyperswarm itself.