Speakr v0.10.21-alpha

In this release, the API can be used with single sign-on access tokens, Ambrose finds people by any of their names, and reported bugs in sharing, jobs and uploads are fixed.

New

• SSO access tokens. When sso_api_tokens_enabled is on, a user's own SSO access token is accepted by the API from an app that signs users in through the same SSO provider as Speakr, so no API token has to be copied. Open WebUI can be connected with its System OAuth connection type. For an app that syncs in the background, such as Mailr, the access token can be exchanged once for a scoped API token at POST /api/v1/tokens/exchange. That token is listed in Account settings → API tokens as created through SSO and can be revoked there.
  • Only signed JWT access tokens of the clients in sso_api_allowed_clients are accepted, each for an account already linked through SSO, with at most the scopes in sso_api_scopes (read by default). No account is created and no account is matched by email.
  • An exchange is allowed only for the clients in sso_api_exchange_clients (none by default), and the exchange route is not listed in /api/v1/openapi.json.
  • Access tokens in the RFC 9068 format, as issued by Pocket ID, are matched by their client_id claim. The setup is described in Admin guide → Single sign-on.
• Revoking the current token. With DELETE /api/v1/tokens/current, the API token of the request is revoked, also a scoped one. GET /api/v1/capabilities lists token_self_revoke and sso_token_exchange.
• Finding people in Ambrose. Ambrose looks up a person in your speaker profiles (names, aliases and emails) and among the participants of your recordings. A first name, a surname, an email such as m.najjar or a spelling variant such as Mohammad, Mohammed or Muhammad is enough, and the search then covers every name the person appears under. In the recording chat, a name you give is matched to the participants of the open recording, and a participant with a speaker profile is listed with the aliases of that profile. Each point of an answer is stated in words before its citation.
• What's new after several updates. A user who missed several releases sees the notes of each release since their last visit, newest first, up to five.
• Long Sources lists. Under an answer with more than three sources, the list is folded into Sources (n) and opens on click.

Changed

• Empty summaries. An empty reply from the summary model, for example from a reasoning model that used all of SUMMARY_MAX_TOKENS for reasoning, is reported as a failed summary and retried. Before, "[Summary not generated]" was stored on a completed recording. A reply cut off at the output limit is also a failed summary, and its partial text is not stored. The error message contains the finish reason and the token usage, and for a reply cut off at the limit, SUMMARY_MAX_TOKENS and TEXT_MODEL_EXTRA_BODY are named in it. The finish reason of every summary call is logged.
• Retries (#594). An HTTP 5xx error from a transcription or model service is always retried, whatever words its response body contains.
• Notices after a failed summary (#595). When the automatic summary fails after a successful transcription, only recording.summary.failed is sent. The "Transcription ready" email and recording.transcription.completed are no longer sent for a recording that ends in a failed state.
• Error details from transcription services (#593). When a transcription service answers with an error page, only a short summary is kept in the log, the failure webhook, the failure email and the technical details. HTML is reduced to its text, values that look like tokens or keys are redacted, the directories of file paths are removed, and the length is limited.
• Expired pages. Signing out from a page whose security token has expired now signs you out, and other forms sent with an expired token return to their page with a message. Before, both showed a "Bad Request" page.

Fixed

• Sharing and permissions. When a group folder is moved to another group, or a personal folder becomes a group folder, its recordings are shared with the new group according to the folder's settings (#586). When a group tag is added to several recordings at once, the recordings are shared as with a single addition (#591). The retention of a recording is no longer set by a personal tag that a share recipient added, and such a tag no longer exempts the recording from auto-deletion (#589). Edit access is required to delete a calendar event (#598). In API v1, inbox and star changes by a shared editor are stored for that editor, not for the owner (#599). A share request with user_id set to true is refused; before, the recording was shared with account 1 (#600). The deletion of a group tag (#590) was already handled in v0.10.20.
• Jobs. For a failed merge or multi-file join, the merge error is shown and, after the last retry, the failure webhook and email are sent (#592). A stitch job for a recording other than its session's is marked failed (#596). The transcript, title or summary of a recording deleted during its job is no longer written to a new upload that received the same id (#597).
• Uploads. An upload that lists the same tag twice is accepted, and the tag is applied once. After a failed upload, no file is left in storage (#601). A WebM converted to MP3 during the upload is stored with the .mp3 extension and is no longer converted again at each transcription (#587).
• Log. A connector without a duration limit is logged as max_duration=unlimited (#588).

Upgrading

Pull the new image and start as usual. The following are added at startup; no manual migration is needed:

• Column: api_token.sso_client_id.
• Settings: sso_api_tokens_enabled (off), sso_api_allowed_clients, sso_api_exchange_clients and sso_api_scopes (read), with the .env variables SSO_API_TOKENS_ENABLED, SSO_API_ALLOWED_CLIENTS, SSO_API_EXCHANGE_CLIENTS and SSO_API_SCOPES.

A few changes are visible to administrators and API clients:

• Webhooks (#595). recording.transcription.completed is not sent when the automatic summary fails; recording.summary.failed is sent instead.
• Inbox and star in API v1 (#599). On a shared recording, is_inbox and is_highlighted in GET and PATCH /api/v1/recordings/{id} and in the batch update are the caller's own values.
• Share requests (#600). The single user_id of POST /api/recordings/{id}/share-internal must be a positive integer. A string such as "5" is refused, as in the user_ids list.
• Event deletion (#598). A view-only recipient receives 403 from DELETE /api/event/{id}.
• Stored file names (#587). New uploads converted during the upload are stored with the extension of the converted file. Existing files are not renamed.
• Empty summaries. A recording whose summary reply is empty ends in a failed state, and the summary job is retried.
• Going back to v0.10.20. The new column and settings are ignored, and tokens created through the exchange work as ordinary API tokens.

Full Changelog: v0.10.20-alpha...v0.10.21-alpha