Nextcloud Talk: video calls, chat and federation inside a Nextcloud install

It is a Nextcloud app, not a server you run on its own

The repository is called spreed, the internal app name is talk, and the README describes it as a video and audio conferencing app for Nextcloud. That last qualifier is the whole design. There is no database to provision, no daemon to supervise and no user directory to sync, because Nextcloud already supplies all three. What Spreed adds is a set of database migrations, a Vue frontend and the signalling and media plumbing for WebRTC calls, packaged so the App Store can install it like any other app.

The frontend manifest makes the modern Nextcloud app conventions visible. `package.json` names the package `talk`, marks it private, and sets the license to agpl, matching the AGPL-3.0 licensing on the repository and the `COPYING` file at the root. The tooling is deliberately current: rspack rather than webpack for bundling, vitest for tests, eslint and stylelint for linting, and `vue-tsc --noEmit` for a type check that never writes output. Dependencies are all scoped `@nextcloud/*` packages, including `@nextcloud/vue` at 9.13.1, which is the shared component library Talk draws its interface from rather than shipping its own widgets.

The last push was on 2026-09-28, and the release tags move constantly, which is expected for an app that has to track the server's own release line.

Chat, calls, federation and a Matterbridge bridge

The README's feature list is short enough to take seriously. There is a text chat that can carry files shared from the Nextcloud Files app or uploaded from a local device, and mentions of other participants. Calls come in four shapes: private one-to-one, group, public link, and password protected. Screen sharing is supported. Federation lets a user on one Nextcloud server chat with a user on another, which the docs describe as a server-to-server conversation.

That last point is where Talk differs from most chat software, and the difference is easy to miss. Federation here means Nextcloud to Nextcloud. It is not Matrix federation, and the client ecosystem that implies is not what this app talks to. One dependency gives a hint about the crypto side: `@matrix-org/olm` at 3.2.15, the same double ratchet library Element uses, which suggests end-to-end encryption reuses proven Matrix primitives rather than a bespoke implementation. `@mediapipe/tasks-vision` is also present, which is the usual home for background effects in a browser.

For organisations that cannot move everyone at once, the README names a specific bridge: Matterbridge is integrated into Talk, so messages can be synced between Talk and other chat solutions and back again. That is a narrower claim than federation, because a bridge is a process you run and maintain, not a protocol.

TURN servers decide whether this works on your network

Installation for production is presented as a single step: enable the app from the Nextcloud App Store and it works out of the box. The README then immediately qualifies that with the part that actually generates support tickets. Some scenarios need a TURN server, specifically users behind strict firewalls or symmetric NATs, and the README calls that setup trickier than the app install. Documentation for it lives in the project's readthedocs site rather than in the README itself, and the team has published a shell script, `vm-talk.sh`, that automates it for the Nextcloud VM image on recent Ubuntu Server LTS releases.

The caveat on that script is stated in the repository rather than buried, which is to be appreciated: it is developed for the VM specifically, and issues with it belong in the Nextcloud VM repository rather than in Spreed's issue tracker. Two different projects, two different places to report a problem.

This is the honest limitation of the project. The application layer is a normal app install, but the media path reaches out of your server to whatever NAT your users sit behind, and nothing inside the app can fix that. A deployment that works on a laptop will fail for a subset of remote staff, and the fix is infrastructure you have to obtain and run. The system requirements pages, split into user-facing and server-facing, are linked separately in the README, which tells you the browser side and the PHP side have their own constraints.

Cloning into apps/ and letting the Makefile do the work

Development setup is a five step list. Clone the repository into the `apps` folder of a Nextcloud development instance, run the setup target, run the JavaScript build, activate the app through the apps management screen, and optionally build the docs. The first step is not a style suggestion, because the Makefile computes `project_dir` as the parent directory joined with the app name, so a checkout anywhere else will not resolve.

make dev-setup
make build-js

The Makefile is small and readable, which makes it a good map of the project. `dev-setup` expands to three targets in order: `clean-dev`, `npm-init` and `build-dev`. `npm-init` is `npm ci`, so the lockfile is authoritative. `build-dev` runs `composer install` then `build-js`, and `build-js` is `npm run dev`. For production, `build-production` swaps in `composer install --no-dev --classmap-authoritative`, which is the setting that matters if you ever package it yourself, and `npm run build`.

For frontend iteration the README suggests hot module replacement, which needs a separate `hmr_enabler` app installed and enabled, then `npm run serve`. The instruction to open the normal Nextcloud server URL rather than the one the command prints is a genuine gotcha, since the dev server proxies through the main instance. There is also a one-line fix for noisy `git blame` output:

git config blame.ignoreRevsFile .git-blame-ignore-revs

The repository ships a `.git-blame-ignore-revs` file at the root, and pointing git at it keeps mass code-style reformats out of every blame view.

Eight OpenAPI specifications and generated types

One detail in the repository tree says more about this project's maturity than the feature list does. There are eight OpenAPI documents at the root: `openapi.json`, `openapi-full.json`, `openapi-administration.json`, `openapi-bots.json`, `openapi-federation.json`, and three scoped to subsystems, `openapi-backend-recording.json`, `openapi-backend-signaling.json` and `openapi-backend-sipbridge.json`. The signalling, recording and SIP bridge specs are the interesting ones, because they mean the pieces that make a call work are each described as their own service boundary.

That split is only useful if types are generated from it, and they are. The `ts:generate` script runs `npx openapi-typescript`, and a separate `ts:generate-core-types` script calls a shell file inside `src/types/`. The `overrides` block in the manifest pins the TypeScript version that `openapi-typescript` resolves to the same one the project uses, which is the kind of detail that only matters once you have hit the mismatch it prevents. Frontend API calls therefore work against generated interfaces rather than hand-written guesses, and the README's contribution guidance asks for regenerated OpenAPI artefacts to be split into their own commits for exactly this reason.

`redocly.yaml` sits alongside the specs, so the API reference is built from the same documents clients read. Bots and webhooks are documented separately on the project's readthedocs site, and `composer.json` plus `composer.patches.json` show that the PHP side accepts upstream patches rather than forking dependencies outright.

Version numbering, release cadence and licensing

The manifest and the release tags disagree in a way that is normal but worth knowing. `package.json` declares `26.0.0-dev.0` while the newest published tags are `v25.0.2` from 2026-09-25, `v25.0.1` from 2026-09-24 and `v25.0.0` from 2026-09-16. The main branch is the development line for the next major, so the dev suffix is the correct interpretation, and the tags are the correct thing to install from.

The v25.0.0 changelog is a reasonable summary of where the app is heading. It adds classified conversations, announcements and channels, an owner role that can promote and demote users, global message search in the conversation list, a preserve setting that restricts deletion and purging, and a setting to limit who can start calls to specific groups. It also brings an upload editor with image compression into the composer, combines several file shares into one message, adds a multi-speaker view to calls, and requires Nextcloud 35, also called Hub 26 Summer. Requiring a specific server major is the real upgrade cost here: Talk cannot be upgraded independently of Nextcloud, because the app ships database migrations that assume the server's schema.

The two patch releases after it are conventional maintenance. v25.0.1 updated dependencies and translations and fixed notification links when fully subscribed, poll wording for anonymous polls, conversation avatars in the Files Sharing tab, and saving compressed images as JPEG. v25.0.2 is a single migration fix that checks for an Index rather than a Constraint. Those are release notes with pull request numbers attached, so the history is auditable.

On licensing, the repository is AGPL-3.0 with a `LICENSES/` directory and a `REUSE.toml` file, and the README carries a REUSE compliance badge. That matters for anyone planning to modify and serve Talk to their own users, since the AGPL's network clause reaches modifications offered over HTTP. This is a licensing fact to plan around, not a reading of the obligations.

The contribution rules are unusually specific

The README's contribution section is worth reading even if you never file a pull request, because it describes how this project is maintained. The guidance on large changes asks contributors to split work into separate functioning pull requests rather than one large diff, to separate backend from frontend changes because they need different review expertise, to keep regenerated artefacts and dependency bumps in their own commits, to use fixup commits for review feedback, and to discuss the plan in an issue before writing thousands of lines. Smaller changes get reviewed faster. That is stated plainly enough that it is hard to miss.

The same section addresses AI-generated submissions directly, asking that plan discussions happen in an issue first and that bulk generated changes be broken up the same way. It is an unusual thing to find in a README and it tells you something real about review capacity.

Translations are handled separately. The README says there is no need to edit anything under `l10n/` by hand, that strings are extracted automatically and contributed through Transifex, and that translations sync back on a nightly basis. So a change to a user-facing string does not need a translated commit alongside it. Documentation for developers and administrators lives as markdown in `docs/`, built with mkdocs, and `mkdocs.yml` and `.readthedocs.yaml` at the root confirm that. User documentation for Talk itself lives in Nextcloud's separate documentation repository, which means this repository is not the whole documentation story.

Finally, authorship is explicit: `AUTHORS.md` at the root, and an `AGENTS.md` alongside it, which is another sign that contributors are expected to read repository-local instructions rather than infer them.

Editorial conclusion

Talk is the right choice when the data has to stay on infrastructure you already administer and the participants are already Nextcloud users, because federation works between Nextcloud servers rather than with the wider Matrix network. The cost is that it is an app inside a platform: you are committing to the Nextcloud App Store's release line, the Hub 26 requirement in v25.0.0, and the TURN server that strict firewalls will eventually force on you. Before enabling it, check the server system requirements page against your PHP and database setup, then decide who operates a TURN server, since that is the part the README flags as trickier than the app install itself. If your requirement is open federation with Element and other Matrix clients, this repository will not satisfy it.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. nextcloud/spreed on GitHub
3. Project website
4. README
5. Releases