While reviewing the inconsistencies noted in #171, I identified five e2e
group key management endpoints that exist as REST routes in the Rocket.Chat
source (apps/meteor/app/api/server/v1/e2e.ts) but are not documented in
the OpenAPI spec:
POST /api/v1/e2e.acceptSuggestedGroupKey
GET /api/v1/e2e.fetchUsersWaitingForGroupKey
POST /api/v1/e2e.provideUsersSuggestedGroupKeys
POST /api/v1/e2e.rejectSuggestedGroupKey
POST /api/v1/e2e.resetRoomKey
These are all part of the E2E group key rotation flow introduced alongside
the suggested key distribution system.
I have drafted spec entries for all five, following the same pattern as the
existing e2e.* entries in settings.yaml. Happy to open a PR if this is
a good direction.
Closes part of #171
While reviewing the inconsistencies noted in #171, I identified five
e2egroup key management endpoints that exist as REST routes in the Rocket.Chat
source (
apps/meteor/app/api/server/v1/e2e.ts) but are not documented inthe OpenAPI spec:
POST /api/v1/e2e.acceptSuggestedGroupKeyGET /api/v1/e2e.fetchUsersWaitingForGroupKeyPOST /api/v1/e2e.provideUsersSuggestedGroupKeysPOST /api/v1/e2e.rejectSuggestedGroupKeyPOST /api/v1/e2e.resetRoomKeyThese are all part of the E2E group key rotation flow introduced alongside
the suggested key distribution system.
I have drafted spec entries for all five, following the same pattern as the
existing
e2e.*entries insettings.yaml. Happy to open a PR if this isa good direction.
Closes part of #171