server/docs/retninger/bruker_ikke_workspace.md

Bruker, ikke workspace

Primærenheten er brukeren og brukerens edges. Workspaces er ikke containere — de er frivillige samlings-noder som gir felles kontekst.

Observasjoner

I dag er workspaces den organisatoriske enheten. Du "er i" et workspace, og det bestemmer hva du ser: kanaler, boards, kalendre. Vil du se noe fra et annet workspace må du bytte. Det er en container-modell — ting bor i workspaces.

Men i node+edge-modellen gir dette ikke mening. En node er ikke "i" noe — den har edges til ting. Og brukeren er ikke "i" et workspace — brukeren har edges til noder, personer, topics, samtaler.

Tesen

Brukeren er sentrum. Du logger inn og ser dine edges — alt du er koblet til. Ikke "velg workspace" som første handling, men "her er alt ditt."

Workspace som samlings-node, ikke container

Et workspace eksisterer fortsatt som konsept, men det er en node i grafen — ikke en organisatorisk boks:

• Tradisjonell modell: Workspace inneholder kanaler, boards, filer. Brukeren er "i" workspacet.
• Node-modell: Workspace er en node. Noder har edge til den. Brukeren har edge til den. Workspace-noden bærer felles kontekst (tema, pruning-profil, AI-konfig).

En node kan ha edge til flere workspaces. En faktoid om en gjest er relevant for både podcast-prosjektet og research-samlingen. Ikke kopi — samme node, to edges.

Personlig er default

Alt uten workspace-edge eller mottaker-edge er privat — tilhører bare deg. "Personlig workspace" er ikke en egen ting du oppretter. Det er fravær av deling. Dine private notater, dagbok, voice memos — de har bare edges til deg.

Administrasjon er edges med roller

Brukerstyring forvaltes i nodene selv, ikke i et sentralt admin-panel:

Edge-type	Hva den gir
Eier-edge	Full kontroll — slette, endre tilgang, endre innstillinger
Admin-edge	Kan invitere/fjerne andre, endre konfigurasjon
Deltaker-edge	Kan gi input og motta
Leser-edge	Kan kun motta (observatør, lytter)

Du oppretter en kommunikasjonsnode (podcast-prosjekt). Du er eier automatisk. Du inviterer Trond → deltaker-edge. Trond kan gi input men ikke slette eller endre tilgang. Du gir Trond admin-edge → nå kan han invitere andre og endre innstillinger på den noden.

Dette skalerer fra en privat notat (kun eier-edge til deg) til en organisasjon (samlings-node med mange admin- og deltaker-edges).

Brukeropplevelsen

Når du logger inn ser du:

• Dine aktive samtaler — kommunikasjonsnoder med edge til deg
• Dine noder — alt du har skapt eller er koblet til
• Dine samlings-noder (det som før var workspaces) — grupperer kontekst, men du trenger ikke "gå inn i" dem
• Din mottaksflate — alt som er relevant for deg nå, vektet

Du kan filtrere etter samlings-node hvis du vil fokusere ("vis bare podcast-prosjektet"), men det er et filter — ikke en modebytte.

Felles kontekst på samlings-noder

En samlings-node (workspace) bærer kontekst som arves av tilknyttede noder:

• Pruning-profil — hvor aggressivt slettes binærdata?
• Tema — visuelt uttrykk (CSS custom properties)
• AI-konfigurasjon — hvilke prompts, hvilken modell, hvilke regler
• Tilgangsnivå — default synlighet for nye noder opprettet i denne konteksten
• Kapasitet — ressursgrenser for maskinrommet (f.eks. maks samtidige transkripsjoner)

Implikasjoner

Kryssgående noder er naturlig

En node med edge til to samlings-noder arver kontekst fra begge. Konflikter (ulik pruning-profil) løses med prioriteringsregler: mest konservativ vinner, eller eier-edge bestemmer.

Onboarding forenkles

Ny bruker trenger ikke "settes opp i et workspace." De får edges til de nodene de trenger tilgang til. Ferdig. Endre tilgang = endre edges.

Forlate et prosjekt er å fjerne edges

Ingen "slett bruker fra workspace." Fjern deltaker-edges. Brukerens private noder som hadde edge til samlings-noden beholder den edgen (det er brukerens innhold), men de mister tilgang til andres noder.

RLS og sikkerhet: samlings-noder som harde siloer

Viktig arkitekturbeslutning: "bruker, ikke workspace" er en UX-modell, ikke en sikkerhetsmodell.

Ren edge-basert tilgangskontroll — der hver lesing traverserer grafen for å sjekke om brukeren har en sti til noden — ville kvelt databasen når grafen vokser. I dag har PG bunnsolid RLS med workspace_id = current_setting(...) — instant og vanntett.

Løsningen er å skille UX fra sikkerhet:

• UX-laget: Brukeren ser sine edges. Ingen "velg workspace." Filtrering etter samlings-node er frivillig.
• Sikkerhetslaget: Under panseret har hver node fortsatt en workspace_id (eller samlings-node-id) som RLS sjekker. Det er den harde sikkerhetsgensen — billig, velprøvd, instant.
• Finere tilgang innenfor siloen: Edge-basert tilgang (eier, admin, deltaker, leser) sjekkes innenfor en silo, ikke som erstatning for den.

Samlings-noder er altså ikke bare frivillig organisering — de er sikkerhetsiloer i databasen. Brukeren merker det ikke, men PG trenger det.

Spenninger og åpne spørsmål

• Overblikk. Uten workspaces som organisatorisk enhet — hvordan unngår du at alt flyter sammen? Samlings-noder er svaret, men de må være intuitive å opprette og bruke uten å bli "workspaces med ny navn."
• Kryssgående noder og siloer. Hvis noder har workspace_id for RLS, kan en node da tilhøre to samlings-noder? Kanskje via en "primær silo" for RLS + sekundære edges for visning. Trenger gjennomtenkt design.
• Arv og konflikter. En node med edge til to samlings-noder med ulike pruning-profiler — hva vinner? Trenger klare regler som er intuitive for brukeren.
• Migrering. Eksisterende workspace-modell har innhold. Kan workspaces bli samlings-noder gradvis? RLS-modellen gjør dette enklere — workspace_id kan bli samlings-node-id uten endring i sikkerhetslogikk.

Forhold til andre retninger

• Rom, ikke forum — "rommet" er ikke et workspace, det er summen av dine edges
• Universell input og mottak — mottaksflaten er "noder med edge til meg", ikke "noder i mitt workspace"
• Maskinrommet — leser samlings-node-edges for kontekst (pruning, kapasitet, AI-konfig)