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
Currently, the server acts as an "aggregator", aggregating commitments before making them available to the Coordinator and aggregating signature shares in the same way.
However, ideally the server should handle as little protocol logic as possible. Thus we could shift this role to the aggregator, and then the server would truly simply carry messages back and forth between participants. The upsides are:
Simplified server;
Less metadata revealed to the server;
Makes it easier to add encryption/authentication;
Makes it easier to migrate to a P2P solution.
Change the server, removing most of current function and shifting the logic to the Coordinator (it's probably possible to reuse the State handling there), and add new "send" and "receive" functions that allows sending a message to one (or more) participants, and getting the messages that belong to the requesting user. (This will also require a message queue of sorts).
We can, in a separate issue, try to use websockets to have a push notification mechanism to allow participants know when they have new messages.
Diagrams for the old and the new architecture:
The text was updated successfully, but these errors were encountered:
Currently, the server acts as an "aggregator", aggregating commitments before making them available to the Coordinator and aggregating signature shares in the same way.
However, ideally the server should handle as little protocol logic as possible. Thus we could shift this role to the aggregator, and then the server would truly simply carry messages back and forth between participants. The upsides are:
Change the server, removing most of current function and shifting the logic to the Coordinator (it's probably possible to reuse the State handling there), and add new "send" and "receive" functions that allows sending a message to one (or more) participants, and getting the messages that belong to the requesting user. (This will also require a message queue of sorts).
We can, in a separate issue, try to use websockets to have a push notification mechanism to allow participants know when they have new messages.
Diagrams for the old and the new architecture:
The text was updated successfully, but these errors were encountered: