multi workspace

[PirroFrIta]

It would be great to have the ability to create multiple workspaces with a table to manage various member logins

	Workspace 1	Workspace 2	Workspace 3
user 1
user 2
user 3	x	x
user 4
user 5		x

[ben-towner]

I agree, multiple workspaces would be ideal for splitting the memos into work, home, different teams, etc.

[Dewep]

Same feelings here, I am using memos for multiple projects (home, main job, side-projects, technical notes, ...), and I would love being able to better split them.

This is kind of a more advanced feature, because I would say your "user 3", in 2 different workspace, should be able to have 2 lists of memos. Having one list, with both workspace content would be kind of messy I think?

[mdg-pnw]

This is kind of a more advanced feature, because I would say your "user 3", in 2 different workspace, should be able to have 2 lists of memos. Having one list, with both workspace content would be kind of messy I think?

I'd imagine that Workspaces would looks something like this:

Home would still show you all of the memos that you have access to in one combined view. Clicking on a workspace would just show you memos that are just in that workspace.

[zachpro1935]

bump... Need this feature...

[Novapixel1010]

I really need this feature. I wish I knew more code I wonder how much it would cost to make this happen?

[Novapixel1010]

Here is my fully length proposal for this feature

Why add multi-workspaces?

Today Memos supports per-memo visibility (private / protected / public) but “protected” effectively means everyone on the instance. That makes it hard to share a subset of notes with just a project team or family group.

Benefits

• Least-privilege sharing: Users can share with some members without exposing to the whole server (“protected”).

• Cleaner organization: One account, many contexts (personal, work, family extended, Everyone in the same house).

• Enterprise-readiness: Paves the way for role-based access control (RBAC), audit, and admin tooling per workspace.

• Backwards compatible path: You can migrate current “protected” visibility into a default workspace with no behavior change.

Core concept

A Workspace represents a collaboration boundary: a set of users and the memos they can see. A memo can be:

• PRIVATE (author only)

• WORKSPACE (visible to members of its workspace)

• PUBLIC (world)

This is the same visibility model users already know, but “protected” is now workspace-scoped instead of instance-wide.

Data model (DB schema)

Add three tables (works across SQLite/MySQL/Postgres, all currently supported by

1. workspace

• id (PK)

• name, slug (unique), description

• created_ts, updated_ts

• created_by

2. workspace_member

• workspace_id

• user_id

• Composite PK (workspace_id, user_id)

3. Option A (simplest) – one workspace per memo: add workspace_id to memo

If NULL and visibility=PRIVATE, treat as personal memo.

If visibility=WORKSPACE, workspace_id must be non-null.

(Option B – many workspaces per memo via memo_workspace join table. Start with A; you can evolve to B if/when “share same memo across multiple workspaces” is requested.)

Migration plan

• Create a built-in “Default” workspace.

• For each existing memo with “visible to members,” set visibility=WORKSPACE and workspace_id=.

• Keep PRIVATE and PUBLIC memos unchanged.

Permissions / RBAC rules

• Read memo:

  • PUBLIC: anyone.

  • WORKSPACE: requester = workspace_member.

  • PRIVATE: author only.

• Write memo: author of the memo’s.

• Manage workspace:

  • OWNER full control; ADMIN can manager you can create a workspace and members in that workspace.

API surface (v1/v2)

Add endpoints (REST) alongside existing APIs

Workspaces

• POST /api/workspaces – create

• GET /api/workspaces – list mine

• GET /api/workspaces/:id – get

• PATCH /api/workspaces/:id – rename/desc

• DELETE /api/workspaces/:id – delete (soft-delete first)

Members

• GET /api/workspaces/:id/members

• PUT /api/workspaces/:id/members/:userId – upsert with role

• DELETE /api/workspaces/:id/members/:userId

Memos

• Extend existing memo create/update payloads with workspaceId and visibility.

• Enforce workspaceId required IF visibility=WORKSPACE.

• Query filters: ?workspaceId=…, plus existing tag/shortcut filters

OpenAPI / SDKs

• Version new fields; default workspaceId=null for backwards compatibility.

UI/UX changes (web app)

• Workspace switcher in the global header (with search + quick jump).

• Composer: a two-step share control:

  • Visibility dropdown: Private / Workspace / Public

  • If Workspace, show a workspace selector (defaults to “last used” for convenience).

• Sidebar: new “Workspaces” section.

• Settings have toggle to turn on workspaces basically just toggling its visibility I assume this will make the code less complex.

  • Tab called "workspaces"
    • In there you can create a workspace and add members to it. Maybe also select which members are allowed to create a workspace.
    • Also control things per workspace like toggling comments on or off.

• Explore: filter by workspace; keep public explore as is.

• Shortcuts / filters: allow workspaceId == 123.

What needs to change in the codebase ?

I am not sure I am assume the database,frontend,server.

Backward compatibility & rollout

1. Ship with feature flag ON but auto-creates “Default” workspace and auto-assigns all existing “member-visible” memos to it; behavior matches today.

2. Admin can create new workspaces and move memos (batch actions are a frequent UX request).

Edge cases & future work

• Cross-workspace mentions / links: allow linking by URL; show a lock badge if the viewer lacks access.

• Multi-workspace memos (Option B) if users want the same memo shared to multiple groups.

• Per-workspace integrations (webhooks, export).

• Audit log per workspace for enterprise use.

• Collaborative editing can be layered on top of workspace scoping

So what do you think @boojack