oCIS has had file versioning since the beginning. Every time you save a file, the previous version is preserved. You can list them, restore them, download them. The version list sits in the file details sidebar, ready to use.
The problem: version numbers are meaningless. “v4” tells you nothing. “v4: Lukas updated the project budget section and corrected the Q3 projections” tells you everything. The gap between those two things is context — and oCIS has always had the data needed to generate it. It just couldn’t, until today.
web-app-version-changelog merged this June 18th. Lukas Hirt wrote it and shipped it in almost a single day. It’s the third AI extension to ship from web-extensions this week.
What It Does
Select a file in oCIS. Open the file details sidebar. A Changelog panel appears alongside the existing panels. The panel lists the file’s version history. Next to each version entry is a Generate button.
Click Generate on any version. The extension fetches both the current version and the previous one from oCIS, diffs them, and sends the diff to your configured LLM. The model returns a plain-English description of what changed. The summary is cached for the session so you don’t re-generate the same diff twice.
If the model call fails, a Retry button appears. If you’ve selected a folder rather than a file, the panel hides itself. If the file is binary, the panel shows an informational message rather than attempting a diff that won’t produce a meaningful text summary.
The response comes back in your preferred language; same BCP 47 detection as the document summary extension. The user’s browser locale is passed as an instruction in the prompt.
Why On-Demand Diffing Matters
The extension doesn’t pre-compute summaries for every version of every file. It fetches the two version blobs only when you click Generate on a specific version pair. An organisation with tens of thousands of files and hundreds of version entries per file does not want API calls firing for all of them. You ask for the changelog entry you actually need, when you actually need it. LLM cost matches actual usage.
Session caching means that if you generate a summary once and revisit the panel in the same session, the result is there without another API call.
Auth Token Forwarding
TThe extension forwards the authenticated user’s oCIS auth token to the LLM endpoint, which is what lets an authenticated Ollama instance, an internal inference server, or a vLLM deployment validate the calling user without a separate login step. Review during this PR flagged the obvious risk in that design: a live, replayable oCIS bearer token should never be forwarded to an endpoint outside your own origin. The fix landed in the same PR: the extension now validates the configured endpoint against window.location.origin at startup and refuses to forward the token anywhere else. In practice, that means the LLM endpoint needs to sit behind the same origin as your oCIS instance, for example through a token-terminating proxy such as the ai-llm-proxy sidecar used elsewhere in the extension framework. For endpoints that don’t require authentication, the token is simply ignored.
Four Milestones. Three Days.
| Date | PR | Extension | What it answers |
| June 15 | #443 | Relicensing to Apache-2.0 | Foundation |
| June 17 | #452 | AI doc summary | What is this document? |
| June 18 | #454 | AI chat with file | Can you change this document? |
| June 18 | #459 | AI version changelog | What changed in this document? |
Three different questions. Three different interaction patterns. Same infrastructure: your oCIS instance, your LLM endpoint, your data. The relicensing was the precondition. Without Apache-2.0 on the extension framework, none of these extensions would have shipped this cleanly.
For Administrators
Same configuration model as the document summary extension: endpoint, model name, optional API key via application config. Configure once, available to all users. The Generate button is on-demand — users decide which version entries they want explained, when they want them.
github.com/owncloud/web-extensions
What’s Next
Three AI extensions in two days. Open framework, fast review cycle, sovereign-by-design architecture, no cloud dependency baked in. The bar is: it works, it’s tested, the contributor understands it, and the DCO is signed.
What would you build?
github.com/owncloud/web-extensions/pull/459
Lukas Hirt is a Collaborator on ownCloud web-extensions. PR #459 opened and merged June 18, 2026.
ownCloud OSPO: moc.skrowetik@opso · kiteworks.com/opensource
