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
In the current implementation, we maintain separate pubsub topics for peers to allow separating data out for specific peers through a "mailbox" of sorts. This would help prevent needless data from being propagated to other peers of the same topic due to specific requests and events being encrypted for a specific peer. Example would be if we send or receive a friend request, the payload itself is encrypted between those two peers. In raygun, conversation topics are shared among the members of the conversation so messages can easily propagate or fanout to other peers in that mesh while still being intended for those set of peers in that topic. However, due to the separate topics as of #87, we would be required to be connected to those peers to be able to publish to those topics unless we are connected to a peer who is subscribed to that topic (in which in our current implementation, that would not be possible although #336 would allow that to be possible). As a result, data may not propagate and fanout.
In 7754827, a placeholder was added as a start of allowing the identity to be announced to a targeted topic when after adding a friend, or initializing the identity profile with a set of friends who may be online to build a discovery path (which is disabled by default). Specific peers topics (under the current implementation) will continue to publish encrypted messages while targeted topics may only publish signed data if the published message does not contain any sensitive information, otherwise it would be encrypted and marked for the intended recipients of the data.
Notes:
Although discovery is disabled by default, the placeholder functionality would improve identity discovery through a "friend-of-friend" style of trust as it only broadcast the identity out after accepting a request or after the initialization of the identity profile with existing friends (unless we are connected to a peer under the same topic).
This change should not impact the current functionality as it does intend to maintain a level of security and privacy for specific data that should not be broadcasted through a topic.
This might change in the far future were we would send data directly instead to reduce the redundancy for specific messages while connected to those peers.
The text was updated successfully, but these errors were encountered:
In the current implementation, we maintain separate pubsub topics for peers to allow separating data out for specific peers through a "mailbox" of sorts. This would help prevent needless data from being propagated to other peers of the same topic due to specific requests and events being encrypted for a specific peer. Example would be if we send or receive a friend request, the payload itself is encrypted between those two peers. In raygun, conversation topics are shared among the members of the conversation so messages can easily propagate or fanout to other peers in that mesh while still being intended for those set of peers in that topic. However, due to the separate topics as of #87, we would be required to be connected to those peers to be able to publish to those topics unless we are connected to a peer who is subscribed to that topic (in which in our current implementation, that would not be possible although #336 would allow that to be possible). As a result, data may not propagate and fanout.
In 7754827, a placeholder was added as a start of allowing the identity to be announced to a targeted topic when after adding a friend, or initializing the identity profile with a set of friends who may be online to build a discovery path (which is disabled by default). Specific peers topics (under the current implementation) will continue to publish encrypted messages while targeted topics may only publish signed data if the published message does not contain any sensitive information, otherwise it would be encrypted and marked for the intended recipients of the data.
Notes:
The text was updated successfully, but these errors were encountered: