An app from Excelano
Filebase
Ask a folder of documents a question.
A Slipcase container is a file with its description attached, and the description travels with the document. Once a folder holds a few hundred of them, the question stops being what is in this file and becomes which of these files say this. A file manager cannot answer that. Filebase can. For macOS, Windows, and Linux.
Coming to the Mac App Store and the Microsoft Store, and to Linux and source, with the code on GitHub.
A folder that can answer
A Slipcase container is one file holding a document of any type together with a short description of it: who owns it, what state it is in, when it was signed, whatever your work needs recorded. Because the description is inside the file, it survives being copied, renamed, mailed and filed, which is the whole point of the format.
What it does not survive is a file manager. To a file manager a folder of containers is a folder of archives with the same icon, sorted by name and date, and the descriptions inside them might as well not be there. You can open them one at a time. That is the only thing you can do.
Filebase is the other thing. Point it at the folder, ask a question about those descriptions, and read what answered:
select @path, title, governance.owner where status = "draft" or tags contains "legal"
One row per container, one column per key. Tick recursive and it descends into subfolders; leave it and it does not.
See it in action
What you can do
Ask in a language you already half know. SlipQL borrows its clauses from SQL and its literals from TOML, which is the language the descriptions themselves are written in — so anyone who can write one can query one without learning a second way to write a date or quote a string. The folder you chose supplies the from clause, so a query can leave it out.
Find out what there is to ask about. select * gives the container’s path and then every key across everything that answered, which is the quickest way to learn what a folder you have just been handed actually records.
Read one in full. Select a row and that container is beside the table: what its payload is called, how large it is, and its whole description as a tree. Press Open payload and the document goes to whatever your system opens that kind of file with.
Get an answer while it is still looking. Rows appear as the scan finds them rather than when it finishes, so a large folder starts answering at once, and asking a second question stops the first.
It tells you what it could not do
Descriptions are written by people, and no two folders agree about what goes in them. So a key a container does not have comes back as an empty cell rather than failing the query, and the row is still there.
The two things that would otherwise turn a short answer into a wrong one are said out loud, under the rows. A file it could not read is skipped and named. And a comparison that crossed types is counted and named — asking for pages > 10 where one container’s pages is the word many is neither true nor false, and without the notice the row’s absence is the only evidence you would ever get.
A short answer that does not say it is short is a wrong answer. That is the rule the window is built to.
It does not write, and it does not remember
It never changes a container. There is no Save in it and no path through it that rewrites one; the descriptions are shown and not edited. The tree you read is drawn by the same editor Slipcase Desktop uses, handed a rule that marks every key read-only — so the thing that could edit your file is told not to, rather than merely not being asked. If you want to change a description, that application is the one that does it.
It keeps no index and no library. Every query is a fresh scan, so the answer is what is on disk now. There is nothing to import, nothing to rebuild, and nothing to go stale when somebody copies a file in from somewhere else.
It makes no network connection of any kind. No server behind it, no account to create, no analytics, no telemetry, no crash reporting. It stores nothing on your disk either: no settings file, no recent-folders list, no cache. Closing it leaves your machine as it found it. The full statement is in the privacy section, and because the source is open, every line of it is checkable.
How to get it
The first release is on its way. The Linux package lands in the Excelano apt repository with it, and the macOS and Windows builds follow on the Mac App Store and the Microsoft Store as with the other Excelano desktop applications. Until then it builds from source with a Rust toolchain alone; the README covers building and the desktop integration.
Something to ask about
If you have no containers of your own yet, any ZIP tool makes one — that is the argument the format is built on. The specification is a short read and shows the whole of it: a document, a text file describing it, zipped.
Behind the tool
Filebase is one of a family over an open format. Slipcase is specified in public under CC0 and is deliberately implementable with a ZIP tool and a text editor; Slipcase Desktop reads and edits one container, Slipcase Open hands a payload to its own application and writes edits back, and Filebase is the one that asks a folder of them a question.
The query language is its own project. SlipQL is a Rust crate and a command-line tool, slipql, for the places a window is not — a script, a build step, a server. Filebase embeds that crate rather than growing a second query engine, which is why the language was written first and why the command line and the window answer the same question the same way. Anything the window can ask, a shell script can ask, and the answer comes back as CSV or JSON for whatever runs next.
I built it because metadata that travels with a document is only worth attaching if something can read it back at the scale a real folder reaches, and for this format there was nothing that could. If getting a handle on a pile of documents is work your team is doing, it is the kind of work I am glad to take on.
For technical users
Filebase is free and licensed under the MIT licence, as the rest of the Slipcase implementation is. It is written in Rust and contains no unsafe code at all: the library half forbids it outright and the application denies it, which the compiler enforces on every build. It parses no containers of its own — every read goes through slpc, the reference implementation — and runs no query engine of its own, which is slipql. The repository is at github.com/excelano/filebase, with its security policy in SECURITY.md. The format is specified at slipcaseformat.org/spec.
Something to point it at. Filebase shows nothing until it is given a folder that holds containers, so here is one: a sample folder of five, three levels deep, with descriptions that differ from one another in the ways a query has to survive. Unpack it anywhere, open that folder, tick recursive, and ask it something — select * is the quickest way to see what a folder has to ask about. It also carries a file named like a container that is not one, so the notices under the rows have something to report.
Support
For questions, bug reports, or feedback, email support@excelano.com. Replies typically arrive within one business day.
Issues and feature requests can also be filed directly in the GitHub repository at github.com/excelano/filebase/issues.