You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 29, 2023. It is now read-only.
Reading from the "katzenpost client control socket" yields an infinite stream of event structs.
In particular, we simply encode them with CBOR and a 2 byte length prefix.
Meanwhile writing to the control socket allows the client to send messages on the mixnet. The encoding must be 2 byte length prefixed CBOR. The CBOR message type for sending would be something like this:
type SentMessage struct {
ID [64]byte
DestinationProvider string
DestinationService string
Payload []byte
WithSURB bool
}
Should the plugin system must handle multiple concurrent connections? For each connection, it is intended that this plugin protocol let's the plugin send and receive concurrently. Should each plugin that's running receive all the events? How can we handle the receive/event side correctly? If a client runs multiple plugins then there needs to be a way to distinguish their receive payloads so that they can be routed to the correct recipient plugin on the client device. I suppose we could use our SURBs to help us identify replies. This client library currently does that and internally tracks this by mean of a Message ID.
However this only helps us identify replies to our queries sent. Whereas Katzenpost clients may receive messages from additional SURBs previously sent or because another network entity knows our Provider and recipient message queue identity. The latter being what is essentially the Loopix recipient addressing. We don't want those design elements from Loopix. We do however want to enable clients to send bundles of SURBs. For the first MVP we can ignore this multi-SURB use case. But even in that case, it's just a matter of matching the SURB ID on incoming messages.
In the above example, SentMessage has an ID field. ID is intended to be matched with the MessageID field of the "message reply event". Our client library's plugin system runtime needs to handle the routing of these reply events and route them based on Message ID. This routing is necessary to support multiple concurrent plugins. However it would be an acceptable minimum viable product to initially have the plugin system assume only one plugin will be used.
The text was updated successfully, but these errors were encountered:
Reading from the "katzenpost client control socket" yields an infinite stream of event structs.
In particular, we simply encode them with CBOR and a 2 byte length prefix.
[int][CBOR OBJECT][int][CBOR OBJECT]...
These client events are already defined in:
https://github.com/katzenpost/client/blob/master/events.go
They are used in the "event channel".
Meanwhile writing to the control socket allows the client to send messages on the mixnet. The encoding must be 2 byte length prefixed CBOR. The CBOR message type for sending would be something like this:
Should the plugin system must handle multiple concurrent connections? For each connection, it is intended that this plugin protocol let's the plugin send and receive concurrently. Should each plugin that's running receive all the events? How can we handle the receive/event side correctly? If a client runs multiple plugins then there needs to be a way to distinguish their receive payloads so that they can be routed to the correct recipient plugin on the client device. I suppose we could use our SURBs to help us identify replies. This client library currently does that and internally tracks this by mean of a Message ID.
However this only helps us identify replies to our queries sent. Whereas Katzenpost clients may receive messages from additional SURBs previously sent or because another network entity knows our Provider and recipient message queue identity. The latter being what is essentially the Loopix recipient addressing. We don't want those design elements from Loopix. We do however want to enable clients to send bundles of SURBs. For the first MVP we can ignore this multi-SURB use case. But even in that case, it's just a matter of matching the SURB ID on incoming messages.
In the above example, SentMessage has an ID field. ID is intended to be matched with the MessageID field of the "message reply event". Our client library's plugin system runtime needs to handle the routing of these reply events and route them based on Message ID. This routing is necessary to support multiple concurrent plugins. However it would be an acceptable minimum viable product to initially have the plugin system assume only one plugin will be used.
The text was updated successfully, but these errors were encountered: