1f349/dendrite
1
0
Fork 0
mirror of https://github.com/1f349/dendrite.git synced 2024-09-19 18:36:53 +01:00
Code Issues Packages Projects Releases Wiki Activity
a763cbb0e1
dendrite/keyserver
History
kegsay 2c581377a5
Remodel how device list change IDs are created (#2098) 
* Remodel how device list change IDs are created

Previously we made them using the offset Kafka supplied.
We don't run Kafka anymore, so now we make the SQL table assign
the change ID via an AUTOINCREMENTing ID. Redesign the
`keyserver_key_changes` table to have `UNIQUE(user_id)` so we
don't accumulate key changes forevermore, we now have at most 1
row per user which contains the highest change ID.

This needs a SQL migration.

* Ensure we bump the change ID on sqlite

* Actually read the DeviceChangeID not the Offset in synapi

* Add SQL migrations

* Prepare after migration; fixup dendrite-upgrade-test logging

* Use higher version numbers; fix sqlite query to increment better

* Default 0 on postgres

* fixup postgres migration on fresh dendrite instances
2022-01-21 09:56:06 +00:00
..
api Remodel how device list change IDs are created (#2098) 2022-01-21 09:56:06 +00:00
consumers Add NATS JetStream support (#1866) 2022-01-05 17:44:49 +00:00
internal Remodel how device list change IDs are created (#2098) 2022-01-21 09:56:06 +00:00
inthttp Delete device keys/signatures from key server when deleting devices (#1979) 2021-08-18 12:07:09 +01:00
producers Remodel how device list change IDs are created (#2098) 2022-01-21 09:56:06 +00:00
storage Remodel how device list change IDs are created (#2098) 2022-01-21 09:56:06 +00:00
types Cross-signing storage code (#1959) 2021-08-04 17:31:18 +01:00
keyserver.go Remodel how device list change IDs are created (#2098) 2022-01-21 09:56:06 +00:00
README.md Add boilerplate for key server APIs (#1196) 2020-07-13 16:02:35 +01:00

README.md

Key Server

This is an internal component which manages E2E keys from clients. It handles all the Key Management APIs with the exception of /keys/changes which is handled by Sync API. This component is designed to shard by user ID.

Keys are uploaded and stored in this component, and key changes are emitted to a Kafka topic for downstream components such as Sync API.

Internal APIs

  • PerformUploadKeys stores identity keys and one-time public keys for given user(s).
  • PerformClaimKeys acquires one-time public keys for given user(s). This may involve outbound federation calls.
  • QueryKeys returns identity keys for given user(s). This may involve outbound federation calls. This component may then cache federated identity keys to avoid repeatedly hitting remote servers.
  • A topic which emits identity keys every time there is a change (addition or deletion).

### Endpoint mappings

  • Client API maps /keys/upload to PerformUploadKeys.
  • Client API maps /keys/query to QueryKeys.
  • Client API maps /keys/claim to PerformClaimKeys.
  • Federation API maps /user/keys/query to QueryKeys.
  • Federation API maps /user/keys/claim to PerformClaimKeys.
  • Sync API maps /keys/changes to consuming from the Kafka topic.