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 channel identifiers are unique UUID4 values, which are too long for many reasons. We need to determine the proper size of the entropy pool and what characters we can use to derive a valid channel ID designate.
For scaling, we may want to divvy things up based on endpoint pathing, (e.g. use the first character of the channel path to determine which pool/machine receives the connection). This would ensure that a given connection request returns to the same machine holding state for both sides.
The text was updated successfully, but these errors were encountered:
We discussed this a little in the meeting today and decided on the following:
Clients should not expect channel-ids to be any particular length. Rather they should expect to receive a b64url-encoded string which, when decoded, will be more than one and less than 32 bytes in length.
We'll keep the channel ids as 32-bytes for initial version, but look at making them shorter as we come to implement the "phase 2" PAKE-based flow.
Currently channel identifiers are unique UUID4 values, which are too long for many reasons. We need to determine the proper size of the entropy pool and what characters we can use to derive a valid channel ID designate.
For scaling, we may want to divvy things up based on endpoint pathing, (e.g. use the first character of the channel path to determine which pool/machine receives the connection). This would ensure that a given connection request returns to the same machine holding state for both sides.
The text was updated successfully, but these errors were encountered: