Allow bases to see "properties" generated by plugins

[Afeldspar]

Currently the help page https://help.obsidian.md/bases/syntax says “In the future, plugins will be able to add functions for use in formulas.”

This is an extension of the same idea, if i’m understanding that sentence correctly. My idea is for plugins to be able to supply (virtual) properties determined by examination of the files - which bases can then treat as they do file properties, note properties, or formulas.

Use case or problem

There seem to be many use cases for this facility.

I’ve linked one of the major ones below: property support for file types other than Markdown could be provided by plugins. A plugin could scan the structure of PDFs, audio files, or the like, and export useful information that bases could then sort and report.

Another - closer to my own use case - would be letting bases have information about the contents of Markdown notes that can be obtained programatically. For instance, a plugin with the right regular expressions could tell you which of your notes have Mermaid charts, or use other specific features.

Proposed solution

Create an API that plugin developers can write to, allowing them to define “properties” that the plugin can calculate, which when the plugin is installed become selectable by the user in bases just like built-in file and note properties.

Current workaround (optional)

Some use cases can be implemented with formulas, but not all.

Related feature requests (optional)

Property support for non-markdown files

Use case or problem The use case is binary file management. Obsidian already supports inline rendering of PDFs, audio and video files. This fact invites such files to become integral part of the vault. However, Obsidian does not support assigning metadata to binary files, like it does for markdown. You cannot tag a PDF, for example. The same goes for canvases, AFAIC. It is possible to use a “twin” markdown file, and there are plugins that try to automate this, but that is cumbersome. Now that …

[CawlinTeffid]

Also related:

Virtual notes for Bases

Use case or problem BASES only work with notes. It is logical for a database, but actualy usecase and functional of BASES is not exactly like that. They lack support for Nested properties for complex data strucutres. Its main purpuce is organisation and catalogue of notes. But use of bases liberaly would produce endless notes. As one note, can hold only very small amount of data. Proposed solution Using Virtual notes, would solve all of it, in an incredibly easy way: The idea is very simp…

[Afeldspar]

Another related feature request:

Bases: Display, Access (and/or Filter using) the Note's Content

Problem Currently, when working with data in a base view, the only way to find specific records is by creating persistent filters. This works well for permanent organization, but creates friction for quick, one-time searches. Base views currently only allow filtering based on property values, but sometimes you need to search within the actual content of notes. For example, imagine you have recipe notes where the ingredients aren’t stored in properties but within the note body. If you want to fi…

[annbaek]

I’d like to add another concrete use case for this API.

I’m building a plugin idea that exposes structured information from the Markdown body as virtual Bases properties. This is not limited to frontmatter.

For example, many notes use repeated headings like “Progress”, “Risks”, and “Next”. A plugin could expose:

heading.Progress.content
heading.Progress.isEmpty
heading.Progress.length

But the same API could also support other body-derived properties, such as:

tasks.open.count
tasks.open.items
tasks.withTag(“#waiting”)
blocks.withTag(“#idea”)
paragraphs.withTag(“#project”)
callouts.withType(“warning”)

These values could then be selected as custom columns in Bases, used for filters, grouping, sorting, formulas, and summaries.

Syncing this kind of data into frontmatter is not ideal. The source content may be long Markdown with links, tasks, code blocks, callouts, tags, embeds, or source positions. Duplicating it into properties can create sync conflicts and pollute the note.

Custom Bases views help, but they don’t fully solve this because plugin-generated values still can’t participate in the native Bases table/card/list views, property toolbar, filters, groups, sorts, or formulas.

A stable plugin property provider API would let plugins expose computed properties from the Markdown body as first-class Bases properties. This would unlock use cases like heading sections, task aggregation, tagged paragraph aggregation, reading progress, Dataview-like computed fields, and external metadata.