Describe the feature you'd like to request
Context Chat currently indexes documents based only on mimetype (a fixed whitelist), with no way to exclude specific files or folders from being embedded. For organizations handling sensitive or confidential documents, there's no mechanism to control which content gets sent to an LLM for embedding — everything matching the mimetype whitelist gets indexed by default. This is a real concern for compliance-sensitive environments where certain documents should never be processed by an AI model.
Describe the solution you'd like
I'm proposing an allow-list approach: a system tag (e.g. "AI knowledge") that a user or admin applies to a file or folder to mark it as eligible for indexing. Only tagged content would be embedded, instead of everything matching the mimetype whitelist by default.
I believe an allow-list approach ("only tagged content is indexed") makes more sense than a block-list ("everything except tagged content is indexed"), since it would be the safer default configuration. In other words, nothing is exposed unless someone explicitly marks it as "safe."
Thinking about cases where users already have Context Chat active with all documents already indexed, here's the solution I had in mind: add an option under Administration settings → Assistant → Context Chat, letting the admin choose between continuing to index all documents, or indexing only tagged documents. By default, this option should be set to "continue indexing all documents," so the new feature doesn't negatively affect any already-active user.
If the "index only tagged" option is selected instead, it should exclude already-indexed documents that don't have the tag.
Describe alternatives you've considered
I didn't consider a fundamentally different approach before landing on the tag-based solution — Nextcloud already has a system tag mechanism, and the codebase already follows an event-listener pattern for similar cases (FileListener.php), so extending that with TagAssignedEvent/TagUnassignedEvent felt like the natural fit rather than something requiring a separate design.
Describe the feature you'd like to request
Context Chat currently indexes documents based only on mimetype (a fixed whitelist), with no way to exclude specific files or folders from being embedded. For organizations handling sensitive or confidential documents, there's no mechanism to control which content gets sent to an LLM for embedding — everything matching the mimetype whitelist gets indexed by default. This is a real concern for compliance-sensitive environments where certain documents should never be processed by an AI model.
Describe the solution you'd like
I'm proposing an allow-list approach: a system tag (e.g. "AI knowledge") that a user or admin applies to a file or folder to mark it as eligible for indexing. Only tagged content would be embedded, instead of everything matching the mimetype whitelist by default.
I believe an allow-list approach ("only tagged content is indexed") makes more sense than a block-list ("everything except tagged content is indexed"), since it would be the safer default configuration. In other words, nothing is exposed unless someone explicitly marks it as "safe."
Thinking about cases where users already have Context Chat active with all documents already indexed, here's the solution I had in mind: add an option under Administration settings → Assistant → Context Chat, letting the admin choose between continuing to index all documents, or indexing only tagged documents. By default, this option should be set to "continue indexing all documents," so the new feature doesn't negatively affect any already-active user.
If the "index only tagged" option is selected instead, it should exclude already-indexed documents that don't have the tag.
Describe alternatives you've considered
I didn't consider a fundamentally different approach before landing on the tag-based solution — Nextcloud already has a system tag mechanism, and the codebase already follows an event-listener pattern for similar cases (FileListener.php), so extending that with TagAssignedEvent/TagUnassignedEvent felt like the natural fit rather than something requiring a separate design.