The goal of this project is to allow clients to upload key packages before publishing identity updates. While we are rolling out these changes, we can do a bit of cleanup of some of the legacy APIs that predate the identity work.
Because of some frontend->backend dependencies, we'll need to roll this out in at least two phases.
Phase 1
- [x] Change logic in `RegisterInstallation` and `UploadKeyPackage` to not validate that the key package is part of a given inbox. Instead it should just validate the signatures and extract the installation ID.
- [x] Update database schema to not store the `inbox_id` on installations, since we don't have that trusted information after the first change. Also remove the expiration field
- [x] Update client to call `UploadKeyPackage` _before_ publishing an identity update adding the installation
- [x] Remove `RegisterInstallation` and `GetIdentityUpdates` APIs from the libxmtp traits
- [x] Make the `ValidateInboxIdKeyPackages` endpoint in the validation service stop checking the lifetime of key packages, since that check will panic if the lifetime is not set
- [x] Stop setting a lifetime on new key packages. This will prevent them from expiring
Phase 2
- [ ] Roll out changes from phase 1 to all clients
- [ ] In the `PublishIdentityUpdate` flow, check to make sure the installation is already registered. Reject any identity updates that reference an installation that does not have a key package stored in the DB.
- [ ] Remove `RegisterInstallation`, `RevokeInstallation` and `GetIdentityUpdates` from the protos and server
- [ ] Remove `ValidateInboxIds` and `ValidateKeyPackages` endpoints from the MLS validation service and protos
The goal of this project is to allow clients to upload key packages before publishing identity updates. While we are rolling out these changes, we can do a bit of cleanup of some of the legacy APIs that predate the identity work.
Because of some frontend->backend dependencies, we'll need to roll this out in at least two phases.
Phase 1
Phase 2