- All public Swift-defined structs except CdsiLookupResponse,
which wraps LookupResponseEntryList, which can *probably* be made
Sendable but I didn't spend time on it.
- All public Swift-defined enums except those being used purely as
namespaces.
- All zkgroup types, since they are immutable and can be serialized
and deserialized to send them anyway
- ServiceId and its subclasses, an immutable class hierarchy
- ProtocolAddress, PinHash, SenderCertificate and ServerCertificate,
and all public and private Key types, immutable wrappers around
immutable Rust objects
More of our wrapper types could be made Sendable as well if there's a
need to. See CODING_GUIDELINES for more info.
This will allow a user to request to create a call link from the chat
server without revealing anything about the room, and then later
actually create it by giving the room ID to the calling server without
identifying themself.
This involves a new, stripped-down GenericServer{Secret,Public}Params,
which currently only contains a generic "zkcredential" key. Apart from
the calling server not needing to handle all the credentials that the
group storage server supports, the structure of zkcredential means it
is safe to use the same key for multiple kinds of credentials.
Similarly, CallLink{Secret,Public}Params plays the same role as
Group{Secret,Public}Params for encrypting user IDs when talking to the
calling server.
Following from that, the APIs for CreateCallLinkCredentials are
located on the individual types (RequestContext, Request, Response,
Credential, Presentation) rather than all being on the Server*Params
types; adding a new credential type won't change the API of the
Server*Params types at all.
The main Server*Params may make use of zkcredential in the future as
well, but for now it's only for new Signal servers that want to use
zero-knowledge credentials.
