Collaboration
Your team doesn't need Salsa
to start working today.
Send an invite link. Your collaborator clicks it, enters their email, and they're in — creating issues, approving plans, and claiming work alongside your agents. No download. No account. No friction.
The philosophy
People and agents.
Same loop. Same rules.
People collaborate
Your contractor creates an issue. Your teammate approves a plan. Your partner claims a task. Everyone works through the same interface — a browser.
Agents execute
When a plan is approved, agents pick up the work — inside an isolated sandbox, gated by QA, tracked in the same audit trail as every human action.
Same execution loop
Generate. QA Review. Approve. Execute. Notify. Whether the work is done by a person or an agent, it flows through the same five-stage loop with the same safety gates.
Zero-friction onboarding
Three clicks to collaboration
Your collaborator doesn't need to download an app, create an account, or install anything. They click a link, enter their email, and start working.
Send an invite
Create an invite from the Salsa app. Choose the team, set permissions, and enter their email. Salsa generates an HMAC-signed token and sends a branded email with a join link.
POST /api/v1/teams/{team_id}/invites
HMAC-SHA256 signed token
Click the link
Your collaborator receives the email, clicks the link, and sees a clean join page showing who invited them and which team they're joining. No sign-up form. No password creation.
https://gateway.salsas.io/join/{token}
7-day expiry (configurable)
Start working
They enter their email, click Accept, and they're in. A session token is issued and stored in their browser. Every API call is automatically scoped to their team. They see the board, create issues, approve plans — all from a browser tab.
X-Team-Session: {session_token}
Team-scoped, permission-enforced
Granular permissions
Not "viewer" or "editor."
Exactly what they need.
Every invite carries a specific permission set. You decide exactly what each collaborator can do — not a coarse "role" that's either too open or too restrictive.
can_create
Create new issues and tasks within their team. File bugs, request features, add work items.
can_update
Update existing issues — change status, edit descriptions, move across columns on the board.
can_delete
Permanently remove issues and tasks. Off by default because deletion is irreversible.
can_approve
Approve agent-generated plans before execution. This is the human gate that keeps agents accountable.
can_claim
Claim work items from the backlog. Assign themselves to tasks and start execution.
can_view_all
See all issues in the team. Turn off to limit visibility to only issues assigned to them.
Team-scoped sessions
They see their team. Nothing else.
When a collaborator makes any API call, their session token automatically filters everything to their assigned team. They can't see other teams, other issues, or other data — even if they try. This isn't access control bolted on after the fact. It's middleware that runs on every single request.
If a collaborator tries to access GET /api/v1/issues?team_id=other-team,
the parameter is ignored. Their session token overrides everything. The filter
is enforced at the API layer, not the UI layer — so even direct API calls
can't escape the scope.
Authentication tiers
Three levels of trust.
You choose.
Not every collaborator needs the same level of authentication. A trusted team member gets a simple link. A contractor handling sensitive data gets email 2FA. A partner with production access gets passkey verification.
Simple invite
Email validation + HMAC-signed token with 7-day expiry. The collaborator clicks the link, enters their email, and they're in.
Email 2FA
Everything in Level 1, plus a 6-digit verification code sent to their email. 10-minute expiry. Must be entered before the invite can be accepted.
WebAuthn passkey
Everything in Level 2, plus hardware passkey verification. ES256 or EdDSA keys. The strongest authentication available — cryptographic proof that the person accepting is who they claim to be.
The execution model
Humans direct. Agents execute.
Everyone is accountable.
The human gate
Agents can generate plans and produce work, but they cannot execute without human approval. The can_approve permission is the key — it means your collaborator is authorized to greenlight agent execution. This isn't a prompt instruction. It's enforced by the same DSP protocol that governs all agent behavior. The agent literally cannot proceed without a signed approval event in the audit trail.
Federation
Multiple Salsa instances.
One shared workspace.
Each person runs their own Salsa on their own machine. Federation connects these instances so they can share teams, sync issues, and coordinate work — without a central server owning anyone's data.
Explicit trust
Pairing requires manual approval on both sides. Each device has its own Ed25519 keypair. Only allowlisted peers can sync. No automatic discovery. No silent connections.
Honest conflict resolution
When two people edit the same issue at the same time, Salsa doesn't silently overwrite. Both versions are preserved and surfaced in the UI. You choose: keep local, keep remote, or merge.
Activity feed
See who did what, when, and from which device. "George created an issue at 10:30am." "Partner approved a plan at 11:15am." Full context, always available.
Presence awareness
Know who's online and what they're viewing. Heartbeats every 15 seconds. See "Partner is viewing the board" in real time. Essential for async coordination.
Bring your own key
Each federated instance uses its own LLM provider. George uses Groq. His partner uses OpenAI. Each pays their own costs. No shared billing. No vendor lock-in.
No central server
Federation syncs through a relay, but the relay can't read the data. Your issues, your plans, your audit trail — they live on your machine, encrypted and signed.
Multi-team access
One person. Multiple teams.
Different permissions each.
A single collaborator can be invited to multiple teams, each with their own permission set. Your designer might have full create/update access on the Design team but read-only access on Engineering. Your contractor might have claim access on one project but not another.
Each team also manages its own OAuth connections independently. Google credentials for the marketing team don't leak to engineering. Slack integrations for one team stay scoped to that team. No cross-contamination.
Why this matters
Collaboration that doesn't exist anywhere else
No install, no barrier
Your collaborator works from a browser. They don't need macOS, they don't need a license, they don't need to understand agents. They see a board with issues. That's it.
Agents are teammates, not tools
In Salsa, agents appear alongside humans in the activity feed. They create plans, claim work, and produce artifacts. The difference: they can only execute after a human says yes.
Work is audited, not trusted
Every action — human or agent — is logged in an immutable event store. When something goes wrong, you can trace the exact sequence of decisions that led there. No finger-pointing. Just facts.
Conflicts are surfaced, not hidden
When two people edit the same issue, Salsa shows both versions and asks you to choose. No silent overwrite. No "last write wins." No lost work.
Permissions are precise, not coarse
Six individual toggles per invite, per team. Not "admin" or "member." You decide if someone can create, update, delete, approve, claim, or view — independently.
Federation, not centralization
Each instance is sovereign. You own your data. Your collaborator owns theirs. Federation syncs what you explicitly share. No vendor has access to your combined workspace.
Start collaborating today.
Get Salsa for macOS and invite your first collaborator in under a minute.