Appearance
KimtFS
Save folders, files and uploads privately on your device
Overview
KimtFS is a private, on-device file system for your browser. It gives you a familiar folder tree: create folders, write text files, and upload files of any type — and everything is stored locally. It is part of the kimtos new-tab app suite.
Everything is fully on-device. There is no backend, no account, and no network: every folder, file, and uploaded blob lives in your browser's storage and never leaves the machine.
Highlights
- Folders & files, fully on-device — a collapsible sidebar tree of folders, each expanding to its contents. Create, rename, and delete from a + menu or right-click.
- Text files — create a text file and edit it inline in the main pane; edits autosave a moment after you stop typing.
- Uploads of any type — upload one or many files; each keeps its original bytes, size, and MIME type. Images preview inline; anything else shows its type and size and can be downloaded back out.
- Nothing leaves your browser — no servers, no analytics, no third-party calls.
- Delete with undo — deleting a file or a whole folder (and everything in it) is reversible for 6 seconds through an undo toast.
- AnubisDB integration — because all data is stored under the app's id prefix, KimtFS content is automatically listed and attributed in the suite's AnubisDB storage console.
- Agent tools — the built-in assistant can list, create, read, update, rename, and delete your folders and files on your behalf.
Privacy model
KimtFS writes only to local browser storage:
- Folders and files are records in the shared IndexedDB, linked into a tree by a
parentId(an emptyparentIdmeans the item lives at the root). - Text files keep their content inline with the file record.
- Uploaded files keep their bytes as a separate blob in the same local database, referenced by the file's id.
Nothing is uploaded, and there are no analytics or third-party calls. Your files travel with the browser profile and are included in the suite's local backup.
Getting Started
Open KimtFS from the dock. The window is split into a sidebar file tree on the left and a file editor / preview on the right. When you have nothing yet, the tree shows a hint to create your first item with the + button or an upload.
The file tree
The left sidebar lists your folders and files. Folders sort before files, and items are ordered alphabetically within each level.
- New file or folder — the + button in the sidebar header opens a small menu (New file / New folder). New items are created in the folder you last clicked, or at the root.
- Upload — the upload button in the header lets you pick one or more files from disk; each is stored as-is.
- Expand / collapse a folder — click a folder to toggle it open or closed. The chevron on the left shows its state.
- Open a file — click it to load it into the main pane.
- Resize the sidebar — drag the divider between the panes; the ☰ button in the toolbar toggles the sidebar entirely.
Right-click anywhere for a context menu:
- Right-click a folder — New file, New folder, or Upload here, plus Rename and Delete.
- Right-click a file — Open, Download (for uploaded files), Rename, Delete.
- Right-click empty space — root-level New file, New folder, or Upload.
Text files
Create a text file (it defaults to a name like Untitled.txt) and it opens in the main pane with a title field and a text area. Type in the area and your changes autosave shortly after you stop — a small Saving… / Saved status appears next to the editor. Rename the file by editing the title field or via the right-click Rename menu.
Text files are capped at 200,000 characters; going over that limit is rejected so a single file can't grow without bound.
Uploads
Use the Upload action (header button or a folder's Upload here… menu) to add files from disk. You can select several at once. Each upload is stored with its original name, size, and type.
When you open an uploaded file:
- Images are shown inline as a preview.
- Any other type shows a file icon with its MIME type and size.
Uploaded files can be downloaded back to disk from the toolbar or the file's right-click menu.
Deleting, with undo
Delete a file or folder from its right-click menu or the toolbar trash button. Deleting a folder removes everything inside it. The item disappears immediately, and an undo toast appears for about 6 seconds — click Undo to bring it back. If you don't undo, the delete is committed and any uploaded blobs are freed from storage.
Breadcrumbs
When a file is open, the toolbar shows a breadcrumb trail starting at Home and listing the folders that contain it, so you always know where the current file lives in the tree.
Architecture
KimtFS follows the suite convention: all data logic lives behind the local API layer, and the app itself is UI plus client-side file preview. The code lives in extension/src/apps/homefs/.
Modules
| File | Role |
|---|---|
meta.ts | The app manifest — id (homefs), display name (KimtFS), accent, order, plan, and App Store marketing copy. |
index.ts | The app descriptor and UI — the folder-tree sidebar, the text editor / file preview, the + and Upload actions, right-click context menus, breadcrumbs, delete-with-undo, and the agent tools array. |
homefs.local.ts | The data layer — folder/file/upload CRUD and blob storage over the shared IndexedDB, registered on the local API router. |
homefs.css | The app's styles for the sidebar tree, editor, and preview. |
Data flow
The UI never touches storage directly: it calls getApi / jsonApi / callApi (the suite's local router), which dispatches to homefs.local.ts. Uploaded-file previews and downloads resolve a local object URL through fileUrl on the homefs/blob/:id route. The agent tools go through the same routes as the UI, so the assistant and the interface stay in sync.
Data model
Everything is a node in the homefs-nodes records collection, and the tree is formed entirely by the parentId link:
- Folder —
{ id, parentId, type: 'folder', name, createdAt, updatedAt }. - Text file —
{ id, parentId, type: 'file', kind: 'text', name, text, size, createdAt, updatedAt }, wheretextis the inline content (capped at 200,000 characters) andsizeis its character length. - Uploaded file —
{ id, parentId, type: 'file', kind: 'blob', name, size, mime, blobKey, createdAt, updatedAt }. The file's bytes live separately in the blobs store under the keyhomefs:<id>.
A parentId of '' (empty) places a node at the root. Listings return a "lean" view of each node (no inline text) for the tree; a file's full content is fetched only when it is opened.
Storage and operations
All persistent data goes through the shared dataStore (the single kimtos IndexedDB), partitioned by the app id:
- Records in the
homefs-nodescollection hold every folder and file node. - Blobs hold uploaded file bytes, keyed
homefs:<id>for object-URL access.
Because both partitions are prefixed with the app id, AnubisDB attributes them to KimtFS automatically.
Key behaviors in the data layer:
- Recursive delete — deleting a folder walks its whole subtree and removes every descendant node, freeing each uploaded blob as it goes.
- Move guards — a folder can't be moved into itself or into one of its own subfolders; both cases are rejected.
- Text limit — creating or editing a text file over the 200,000-character limit is rejected.
- Autosave — text edits are debounced (~500 ms after the last keystroke) before being persisted via a
PATCH. - Delete-with-undo — the UI soft-hides a deleted item for ~6 seconds and only commits the recursive delete to storage if the undo window lapses.
Agent tools
KimtFS exposes its capabilities to the suite's on-device assistant as an MCP-shaped tools array on the app descriptor. Each tool runs on-device through the same local routes as the UI:
| Tool | Purpose |
|---|---|
list_files | List every folder and file with id, name, type, kind, and parentId — used to find an item's id first. |
create_folder | Create a folder under an optional parentId (root if omitted). |
create_file | Create a text file with optional content under an optional parentId. |
read_file | Read a text file's content by id; uploaded files return their metadata. |
update_file | Replace a text file's content by id. |
rename_item | Rename a folder or file by id. |
delete_item | Delete a folder (and everything inside it) or a file by id. |
Following suite conventions, these tools never throw to the user — for a missing item or a validation failure they return an ok: false result the assistant can recover from — and their compact string results list ids so follow-up tool calls can reference them.