Kontext Encyclopedia

Collaborations

/collaborations · version 3.13 · 2026-10-06

Capabilities

Collaborations (/collaborations) is one room per shared project. Hero: Your collaboration rooms. The owner keeps the files and servers. It is not a Messenger group. Talk explains — it does not send an invite.

What is Collaborations?

Collaborations (/collaborations) is one room per shared project. Header Collaborations. Hero: Your collaboration rooms. The owner still owns the files and the servers. Deploy as a collaborator uses the owner’s hosting. Talk explains — it does not send an invite.

Rooms and inbox

Stats: Active, Inbox. Directory: Rooms. Blocks: Needs you (Invite / Request), Awaiting response (Sent invite), Active rooms. Actions: Accept, Decline, Review, Withdraw, + Invite by handle. Empty: No active rooms yet. Accept an invite or invite someone from Network.

Invite and request

Network: Invite (tooltip Invite to collaborate) or Request. Modal: Invite as Collaborator — one Select project, then Can Read, Can Edit, Can Deploy, Can Manage Agents, Can Invite Others, Can Manage Team. Send invite. No type picker. No personal message on the invite. Inbox chips say Read / Edit / Deploy, not canRead.

Inside a room

Pillars: Overview, Who, Connected, Do together. Header: Share KRN, Open in Messenger, Open in Workspace, Leave collaboration. Owner: Manage collaborators. Do together: Edit files, Deploy, Run agents, Live preview, Jump to chat. Chat: Collab chat — full thread lives in Messenger. Workspace shows a Collaborated badge.

Manage, leave, revoke

Owner Manage collaborators → Manage Collaborators. Remove revokes. Empty: No collaborators yet. Owner confirm ends the room for everyone. Collaborator Leave collaboration loses access — no copy of the app.

What it is not

Not a Messenger group. Not Communities. Not Forum. Not Marketplace. Leaving does not copy the app onto your account.

Collaborations (/collaborations) is the standalone module for shared projects — invites, rooms, deploy-as-collaborator on the owner's canister. Not the same as Messenger groups.

Collaboration lets Kontext users share project access without copying files. Everything stays on the owner's canister; collaborators get permissioned access through the platform registry.


Architecture (why it works this way)
Layer Role
Owner's user canister Stores project files, WASM, deployments — single source of truth
Collaborator's user canister Caches collaboration metadata so they can open shared projects quickly
Platform canister Invite/request registry, active collaboration references, deploy authorization

Benefits: no file duplication, fair cost distribution, instant permission updates, owner retains ownership.


Collaboration flows
Flow What you do What happens
Owner invites From a Network profile → Invite → pick your project(s), set permissions, optional message Recipient gets notification → Accept or Decline
User requests From profile → Request collaboration with message Owner picks projects + permissions → generates invites → requester accepts each
Accept Click Accept on notification or Collaborations module Project appears in collaborator's workspace with Collaborated badge
Revoke Owner removes access Instant removal; collaborator loses edit/deploy rights
Deploy as collaborator Collaborator with canDeploy runs deploy Routes through owner's canister and server pairs — not collaborator's infrastructure
Rate collaboration After working together Reputation scores and testimonials on profiles

Permission model

Platform permissions (set on invite):

Permission Intent
canRead View files and project structure
canEdit Create, edit, delete files
canDeploy Deploy to owner's hosting
canManageAgents Agent/workflow changes on shared project
canInviteOthers Sub-invite collaborators
canManageTeam Team-level admin on collaboration

Legacy UI labels map to these: Viewer, Commenter, Editor, Admin — see contract doc for exact mapping per surface.

Collaboration types: Individual (one person), Team (team id), Group (group id).


Collaborations module (/collaborations)

Standalone module — not just workspace permissions:

Feature What it does
Collaboration directory Browse active collaboration rooms and pillars
Collaboration Room shell Premium embedded chat context for a shared project
Network integration Invite from feed and profiles; deep links into rooms
Deploy hardening collaborationContext service ensures collaborator deploy targets owner canister
Cache repair Fixes stale collaboration cache after canister upgrades

What collaboration is not (scope)

User journeys

C-01. Invite a collaborator from their profile

Path: Network → Profile → Invite · or Collaborations → + Invite by handle

You do:

  1. Open /network and the member's profile (/profile/:handle), or stay in /collaborations.
  2. Confirm you own the project — files stay on your account.
  3. Click Invite (icon tooltip: Invite to collaborate) or + Invite by handle.
  4. Modal Invite as Collaborator: one Select project, then Can Read, Can Edit, Can Deploy, Can Manage Agents, Can Invite Others, Can Manage Team.
  5. Press Send invite. There is no type picker and no personal message box.
  6. Land on /collaborations?inviteSent=… — banner under Awaiting response.

Result: They get a notification. After Accept, the project shows a Collaborated badge in their Workspace — no file copy.

C-02. Accept a collaboration invite

Path: Notification bell → Accept · or /collaborations → pending invite

You do:

  1. Open the collaboration notification from the bell or go to /collaborations.
  2. Review the project name, owner handle, and chips (Read / Edit / Deploy).
  3. Confirm you understand files stay on the owner's canister — you are not getting a copy.
  4. Click Accept (or Decline if the scope is wrong — see C-08).
  5. Wait for the collaboration cache on your user canister to register the active reference.
  6. Open Workspace and locate the shared project with the Collaborated badge.

Result: Shared project opens in your workspace with the granted permissions; deploy and edit rights route through the owner's infrastructure, not yours.

C-03. Request access to collaborate

Path: Profile → Request / Request Collaboration

You do:

  1. From their profile, click Request (tooltip Request collaboration).
  2. In Request Collaboration, pick their public projects.
  3. Submit — it lands in their Needs you inbox and notification (📋 Review Projects).
  4. They Review and Grant Access.
  5. Open each invite that arrives (bell or Collaborations).
  6. Review Read / Edit / Deploy chips before Accept.

Result: You never get in until they grant. Same permission model as a direct invite.

C-04. Set granular permissions on an invite

Path: Invite as Collaborator → Permissions · room Manage collaborators

You do:

  1. Open the invite modal or Manage collaborators.
  2. Toggle Can Read for view-only.
  3. Add Can Edit so they can change files.
  4. Grant Can Deploy only if they may ship on your hosting.
  5. Toggle Can Manage Agents if they may change agents on that project.
  6. Use Can Invite Others or Can Manage Team sparingly.
  7. Send or save. Inbox chips show Read / Edit / Deploy — not Viewer / Editor.

Result: Minimum rights, no file copy. Updates apply on the owner’s project.

C-05. Deploy as a collaborator

Path: Collaborated project → Workspace → Deploy

You do:

  1. Open the shared project from Workspace (must show Collaborated badge).
  2. Confirm your invite includes canDeploy — without it, Deploy is blocked or read-only.
  3. Make changes in Chat, files, or Context as permitted.
  4. Open Deploy and review the preflight summary.
  5. Confirm routing targets the owner's canister and server pairs (collaborationContext service enforces this).
  6. Run deploy and watch the build log through completion.
  7. Copy live URLs or canister IDs from Hosting if the owner needs them — you did not consume your own hosting infrastructure.

Result: Deploy succeeds on owner infrastructure; collaborator deploy never bills your personal server pair for their app.

C-06. Open a Collaboration Room

Path: /collaborations → select room · Network deep link → room

You do:

  1. Open /collaborations from the module switcher or OS dock.
  2. Browse Rooms — Needs you, Awaiting response, Active rooms.
  3. Pick the room for that project.
  4. Use pillars Overview, Who, Connected, Do together.
  5. Collab chat is a preview — full thread is Open in Messenger.
  6. Deep link is /collaborations?project=… (no /collaborations/:id page).
  7. Open in Workspace when you need to edit or deploy.

Result: Premium room UI for ongoing shared work — chat plus project context in one place, separate from but linked to Network and Messenger.

C-07. Browse the collaboration directory

Path: /collaborations → directory · module switcher → Collaborations

You do:

  1. Sign in and open /collaborations.
  2. Scan Active rooms and the Inbox counts.
  3. Header search filters by project name or id — there is no sort-by-owner control.
  4. Open a room or Open in Workspace.
  5. Handle Needs you (Invite / Request) in the same shell.
  6. After you invite, the banner lists them under Awaiting response.
  7. Workspace shows Collaborated on a shared project — that is the same grant, not a copy.

Result: Single module view of every shared relationship — rooms, pending actions, and entry points into Workspace without hunting notifications.

C-08. Decline a collaboration invite

Path: Notification → Decline · /collaborations → pending invite

You do:

  1. Open the collaboration notification or pending row in /collaborations.
  2. Read project name, owner, and permission scope one more time.
  3. Click Decline instead of Accept.
  4. There is no reason box — Decline removes the invite.
  5. Confirm the invite disappears from your pending list.
  6. Verify the project does not appear in Workspace with a Collaborated badge.
  7. If you change your mind later, ask the owner to send a fresh invite or submit a new request (C-03).

Result: No access is granted; the owner sees the declined state and can re-invite with different projects or permissions.

C-09. Revoke collaborator access

Path: Project settings → Collaborators → Revoke

You do:

  1. As project owner, open the shared project's collaboration or team settings.
  2. Locate the collaborator row — handle, permission summary, last activity if shown.
  3. Select Revoke or Remove access.
  4. Read the confirmation copy: instant loss of edit, deploy, and agent rights.
  5. Confirm revocation — no grace period; platform registry updates immediately.
  6. Ask the collaborator to refresh Workspace if they still see a stale badge (cache repair may run on next open).
  7. Re-invite later with tighter permissions if the relationship resumes (C-04).

Result: Collaborator loses edit and deploy rights instantly; files remain on your canister and they cannot deploy or mutate the project anymore.

C-10. Sub-invite another collaborator

Path: Collaborated project → Invite (requires canInviteOthers)

You do:

  1. Open a shared project where your invite includes canInviteOthers.
  2. Open the collaboration invite flow from project settings or the Collaborations module.
  3. Search for the new member by @handle from Network.
  4. Select which of the owner's shared projects you are allowed to extend (UI may limit to projects already shared with you).
  5. Set permissions for the sub-invite — you cannot grant rights you do not hold.
  6. Add a message naming yourself as the introducer.
  7. Send; the owner may receive a notification depending on canManageTeam policy.

Result: New collaborator enters through a sub-invite chain; owner retains ultimate ownership and can revoke any participant (C-09).

C-11. Rate a collaboration and leave a testimonial

Path: Collaboration complete → profile Rate · post-project prompt

You do:

  1. Finish a meaningful stretch of shared work on a collaborated project.
  2. Open the rate collaboration prompt from the project, Collaborations module, or the partner's Network profile.
  3. Assign reputation scores across dimensions the UI shows (communication, delivery, permissions hygiene, etc.).
  4. Write a short testimonial others can see on the collaborator's public profile.
  5. Submit — confirm it appears on their profile reputation section.
  6. Optionally cross-post gratitude on Network if you want public visibility beyond the score.
  7. Decline to rate if the engagement was too brief — ratings are meant for completed collaborations.

Result: Reputation scores and testimonials accumulate on profiles, helping Network and Collaborations surfaces surface trusted partners.

C-12. Repair stale collaboration cache after upgrades

Path: /collaborations → stale project · Workspace Collaborated badge mismatch

You do:

  1. Notice symptoms: shared project missing, wrong permissions, or badge out of sync after a canister upgrade or long offline period.
  2. Open /collaborations first — the module runs cache repair for collaboration metadata on your user canister.
  3. Refresh the collaboration directory and pending invites list.
  4. Re-open the project from Collaborations or Workspace picker.
  5. If still broken, sign out and back in to force platform registry re-fetch.
  6. Ask the owner to confirm you are still on their collaborator list (they may need to re-send invite).
  7. Contact support with project id and handles if cache repair and re-invite do not restore access.

Result: Collaboration metadata on your canister realigns with the platform registry so shared projects open with correct permissions without duplicating files to your storage.

How it works

Route /collaborations. Collaboration rooms — invites, shared projects, collab chat hooks. Pairs with Messenger for DMs/groups.

Benefits

Who it's for

Primary: teams and multi-founder projects.