architecture

Security · OAuth · Permissions

Who is allowed to see what, and why we believe the architecture makes that tractable.

The first guarantee: source code locality

Source code does not leave the LAN of the machine where the Node runs. The relay holds no source. Clients render messages, not files. Recap summaries generated at Thread end are short text descriptions, not file contents — see the Memory page for the pipeline. This is the architectural property that lets us be defensible to a security-sensitive game studio without making any specific compliance promises.

OAuth, but project-scoped

Authentication is OAuth 2.1 (GitHub OAuth in v0.1). The thing that’s worth understanding is that scope is per-project, not per-user. A user’s identity is a global thing; their permissions exist only inside specific projects.

ScopeGranted via
project.memberOwner invitation
project.contributorMember + a contributor role
project.adminMember + an admin role
node.dockPer-machine pairing token (issued once at dock time as a long-lived JWT)
thread.subscribe.ownImplicit for any project member
thread.subscribe.sharedGranted explicitly per-Thread by the owner

Permission matrix

CapabilityMemberContributorAdmin
Subscribe to own Thread
Subscribe to others’ Threads(request)(request)
Approve a Thread subscribe request
Dock a node
Promote a Memory entry from user to project
Modify project membership
View admin dashboard / token consumption

Why “approval” instead of “default open”

Coworking is good. Coworking with strangers reading every prompt you ever typed is not. The default for cross-user Thread visibility is request and approve. Admins see everything; everyone else asks.

What’s parked

  • Audit log persistence. What we record, where, and for how long.
  • On-prem relay. A managed-hosted relay is the default; a self-hostable image for compliance-sensitive customers is on the roadmap.
  • SSO. Mapping enterprise identity providers into project membership is Phase 3.