Workspaces and sharing

Team workspaces aren’t open yet

Creating a shared workspace and inviting people is currently locked while we polish it — the app will tell you it’s coming soon if you try. Everything below about roles, invites and moving projects between workspaces describes how it works, not something you can turn on today.

What does work now is everything inside your own Personal Workspace, including the shared Library — assets and components at workspace scope, reachable from every project you own and by any agent working in one.

Every account starts with a Personal Workspace — created for you on signup, along with a welcome project. If you never collaborate, that’s the whole story, and Mixture stays out of your way: the workspace switcher is hidden entirely until there’s a second workspace to switch to.

The moment you work with other people, workspaces start earning their keep. A workspace holds projects, assets, components and recipes, and everyone in it sees the same library.

Roles

Members hold one of four roles, in increasing order of authority:

• Viewer — can see the workspace’s projects.
• Member — the working role: create and edit projects, upload assets, save components.
• Admin — the above, plus managing membership.
• Owner — full authority over the workspace.

Roles are per-workspace: you can own your personal workspace and be a viewer on a client’s, and nothing leaks between them.

Inviting people

Invite in the sidebar sends an invite by email. The recipient gets a link that lands them on an acceptance page — clicking through joins them to the workspace at the role you chose.

Two details worth knowing, both deliberate:

• Accepting is an explicit action, not a link click. Mail scanners prefetch URLs in inboxes, so if merely loading the link joined the workspace, a security scanner could burn the invite before the human ever saw it. The link opens a page with a button.
• Brand-new invitees get set up first. Someone without a Mixture account signs in via magic link, gets their own personal workspace and welcome project, and then joins your team workspace — so they land somewhere that already works rather than in a bare shared space.

Invites expire. If one lapses, reissue it rather than trying to revive the old link.

Moving projects between workspaces

Project cards offer Move to workspace when there’s somewhere to move to. It appears only for destinations you can actually create in (member and above), and the server enforces the same rule plus admin rights in the source — so a move you shouldn’t be able to make fails loudly rather than half-completing.

Moving a project moves its document and its project-scoped assets with it. Anything the project referenced from the old workspace’s shared library will no longer resolve, so move the shared pieces too — or promote them to the destination’s library first.

The shared library

Assets and components can live at two scopes:

• Project — only that project can use it.
• Workspace — every project in the workspace can use it.

Workspace scope is what turns a workspace into a studio. Your typefaces, logo lockups, sound beds, lower thirds and end cards sit there once, and every project — and every agent working in that workspace — builds from the same set. It’s also what makes agent-built video come out looking like yours: an agent that can see your components composes from them instead of inventing lookalikes.

See Components for saving and parameterising them.

The Library page

Library in the sidebar is the workspace shelf on its own page — no project required. It shows everything shared with the workspace, assets and components alike, plus whatever the community has published, and you can upload straight into it. Every asset type can live there — fonts, images and video, music, WGSL shaders and filters, GLB models, datasets — not just the obvious brand material. That’s the place to answer “what brand material do we have?” without opening an unrelated project to look.

Inside a project, the same shelf appears as the Workspace tab of the assets view, alongside Project (this project’s own media) and Community.

Putting something on the shelf

Two ways, and which one you use is just a matter of when you knew:

• Upload it there. On the Library page — or on the Workspace tab inside a project — uploads land at workspace scope. The button says where they’ll go.
• Share it afterwards. Open any project asset or saved component and choose Share with workspace. Nothing moves and nothing is copied: the id stays the same, so every video already using it keeps working, and it costs the same whether it’s a 20 KB SVG or half a gigabyte of video.

An agent can do both: ask it to save a logo or a typeface “to the workspace” and it files it on the shelf directly, or to share something it made earlier.

Sharing is one-way

There’s no un-share. Once something is on the workspace shelf, other projects can build on it — and narrowing it back to a single project would strand any video that had started using it. Share deliberately: a brand typeface belongs there, a screenshot for one scene doesn’t.

Deleting shared material

Deleting an asset or component that other projects use is allowed, but you’ll be told what you’re doing: the confirmation says it’s shared with the workspace and that any project using it will be left with missing media. It can’t be undone, and the projects that break are the ones you can’t see from where you’re standing — so read the dialog rather than clicking through it.

The one thing Mixture refuses outright is deleting material that a published community recipe depends on. That would break the recipe for everyone who has used it, so you’re asked to withdraw the recipe first. The same applies to editing the content of a granted asset — it’s frozen while published, since consumers would silently receive changes nobody reviewed.

Reaching across workspaces

The one exception to workspace isolation is a published recipe. When a recipe goes to the community, the assets and components it links become readable by everyone using it — that’s what makes a shared recipe actually work rather than arrive full of broken references. Unpublish the recipe and that access goes away again.

Nothing else crosses a workspace boundary.

Deleting things

Deleting a project hides it immediately, but the data isn’t destroyed on the spot — it enters a 30-day window before a background sweep purges it for good. That window exists so an accidental delete is recoverable rather than final.

Deleting a workspace behaves the same way, and takes its projects with it.

Caution

After the purge sweep runs, the data is gone — there’s no undo past the 30-day window. If a project matters, export it as well as keeping it.

If something refuses to save

Occasionally a write will fail with a message like “this project just moved to another workspace” or “the project or workspace was deleted”. That’s Mixture noticing that the thing you’re editing moved out from under you — usually because a teammate moved or deleted it while your tab was open.

It fails closed on purpose: refusing the write is better than saving your changes into a workspace you’re no longer editing in. Reload, find the project in its new home, and carry on.