Problem:
Right now, it's only possible to create an xid whitelist per conversation owner, not per conversation. This would mean that the typical model of creating random UUIDs for xid over the course of a series of conversations would open up the possibility of participants from prior conversations being able to join latter ones (possibly multiple times), counter to intention.
Suggested solution:
These whitelists (nay, allow lists, while we're at it...) should be keyed to the conversation id.
Alternative suggestions:
Could potentially add an option for both conversation and owner based
Additional context:
This design is an inheritance from our startup roots when we expected than many business applications would be run with a fixed pool of users per owner, where it would make sense to key this way. In fact, the xid system itself is entirely keyed this way: if a given xid is used on two conversations owned by the same user, the two participants will be identified as being the same "user". Most of the time this isn't an issue, especially if using random UUIDs for xids, but could potentially cause problems in niche situations. The issue is however much more significiant with the xid whitelist. It's possible that this is where the suzinvite might come in handy, but that's also possibly/likely overengineering for this problem.
Temporary workaround:
Right now this can be gotten around by creating a new owner/user record for each conversation if its really important. The same email can be used for multiple owner/users by affixing a unique (per conversation) tag (which could just be the conversation zinvite, or a handy identifier associated with convo topic) to the first part of the email like this: username+<convotag>@example.com. Not ideal, but gets things working for now.
Problem: Right now, it's only possible to create an xid whitelist per conversation owner, not per conversation. This would mean that the typical model of creating random UUIDs for xid over the course of a series of conversations would open up the possibility of participants from prior conversations being able to join latter ones (possibly multiple times), counter to intention.
Suggested solution: These whitelists (nay, allow lists, while we're at it...) should be keyed to the conversation id.
Alternative suggestions:
Additional context: This design is an inheritance from our startup roots when we expected than many business applications would be run with a fixed pool of users per owner, where it would make sense to key this way. In fact, the xid system itself is entirely keyed this way: if a given xid is used on two conversations owned by the same user, the two participants will be identified as being the same "user". Most of the time this isn't an issue, especially if using random UUIDs for xids, but could potentially cause problems in niche situations. The issue is however much more significiant with the xid whitelist. It's possible that this is where the
suzinvitemight come in handy, but that's also possibly/likely overengineering for this problem.Temporary workaround: Right now this can be gotten around by creating a new owner/user record for each conversation if its really important. The same email can be used for multiple owner/users by affixing a unique (per conversation) tag (which could just be the conversation zinvite, or a handy identifier associated with convo topic) to the first part of the email like this:
username+<convotag>@example.com. Not ideal, but gets things working for now.