Spaces, folders and files
The model is user → spaces → folders and files. A user can own multiple spaces and join other people's spaces. A space has one root folder; a file can sit there directly or inside nested folders.
Use one space for a project, a team, a public wiki or your private notebook. A space supplies the membership and storage boundary. Folders organize its contents. Files hold the actual bytes: Markdown, a spreadsheet, a photo, or another format.
The signed-in home shows your owned and joined spaces. Search that view to find a space by name or description. Open a space to browse and upload files. The space picker takes you between collections; deep file links open the right containing space.
Useful properties
Every space, folder and file can have a short Markdown description. Use it to explain what belongs there. Descriptions have the same audience as the thing they describe, so a public description is public too.
Files and folders also support structured JSON metadata for source IDs, tags, or another integration's context. Ordinary authorized API clients can read it. Anonymous public-link responses omit it. Do not treat metadata as a separate vault: people who have normal file access can read it.
A file has a stable ID. Its normal URL looks like https://stuff.ac/file/FILE_ID. Renaming it or moving it within its space does not change that ID. Copying it creates a new item with new ownership and history. Copies do not inherit the source's direct share links or named grants.
Cross-space copying is supported; moving across spaces while preserving identity is deferred. A source link still requires permission, even if you know its ID.
Moving a file or folder between spaces with the same owner keeps its file links and history. You must manage both spaces and confirm the access change. It inherits the destination’s access; direct shares and selected connection scopes on the moved items are removed. Copying creates new files instead.