synops/docs/retninger/rom_ikke_forum.md
vegard b5aa5bb243 Fjern SpacetimeDB komplett (oppgave 22.4)
SpacetimeDB er nå helt fjernet fra Synops. Sanntid håndteres av
PG LISTEN/NOTIFY + WebSocket i portvokteren (maskinrommet).

Kode fjernet:
- spacetimedb/ Rust-modul og spacetime.json
- maskinrommet/src/stdb.rs (HTTP-klient for STDB-reducers)
- frontend module_bindings/ (23 auto-genererte filer)
- spacetimedb npm-avhengighet fra package.json
- scripts/test-sanntid.sh (testet STDB-flyt)

Infrastruktur:
- Docker-container stoppet og fjernet fra docker-compose.yml
- Caddy: fjernet /spacetime/* reverse proxy
- maskinrommet-env.sh: fjernet STDB_IP og SPACETIMEDB_*-variabler
- .env.example: fjernet SpacetimeDB-seksjoner

Dokumentasjon oppdatert:
- CLAUDE.md: stack, lagmodell, kjerneprinsipper, driftsmodell
- docs/arkitektur.md: skrivestien, lesestien, datalag, teknologivalg
- docs/retninger/datalaget.md: migrasjonshistorikk, status "fjernet"
- 37 andre docs oppdatert (features, concepts, infra, ops, retninger)
- Alle kode-kommentarer med STDB-referanser oppdatert

Verifisert: maskinrommet bygger og starter OK, frontend bygger OK,
helsesjekk returnerer 200. Caddy reloadet.
2026-03-18 13:39:09 +00:00

186 lines
9.1 KiB
Markdown

# Rom, ikke forum
> Hva om Sidelinja ikke er en webapp med sanntidsfunksjoner, men en oppslukende
> sanntidsopplevelse som tilfeldigvis leverer tradisjonell funksjonalitet?
## Observasjoner
Sidelinja har vokst organisk. Vi har bygget chat, kanban, kalender, notater,
kunnskapsgraf — hver som sin feature, hver med sin spec. Sanntid ble lagt til,
men arkitekturen var fortsatt "PostgreSQL-app med sanntidskrydder."
Resultatet:
- **Forum-følelsen.** Ting er organisert i tråder, kort, lister. Brukeren
navigerer mellom sider. Det føles som et tradisjonelt verktøy med litt polish.
- **Arkitekturspenning.** Spørsmålet om hva *primæropplevelsen* er
— sanntid eller tradisjonell webapp — forblir åpent.
- **Feature-fragmentering.** Chat, kanban, whiteboard, notater — hver lever i sin
boks. "Universell overføring" og "meldingsboks" prøver å lime dem sammen, men
utgangspunktet er fortsatt separate primitiver.
## Tesen
Snu gravitasjonen:
**I stedet for:** Tradisjonell webapp → bolt på sanntid der det trengs
**Tenk:** Sanntidsrom er default → persistens er en egenskap ved ting som skjer
Forskjellen er subtil men fundamental:
- Et "dokument som flere kan redigere" vs "et rom der folk er sammen og ting
de gjør blir husket"
- "Gå til kanban-brettet" vs "åpne kanban-laget i rommet du allerede er i"
- "Send en melding i chat" vs "si noe i rommet"
## Hva ville vært annerledes?
### Sanntidslaget og arkivet
PG er eneste datakilde. Sanntid leveres via PG LISTEN/NOTIFY + WebSocket
i portvokteren. Arkivet og sanntidslaget er ikke to separate systemer —
PG er begge deler.
Ikke alt trenger sanntid. En kunnskapsgraf-utforsker, et søk i gamle
episoder, en statistikkside, en offentlig publisert artikkel — disse
bruker tradisjonelle API-kall mot PG. Sanntidsstrømmen er for det som
er levende: chat, whiteboard, live redigering.
To overflater, én datakilde:
- **Sanntidsopplevelsen** (via WebSocket) — for alt som er levende,
aktivt, samarbeidende.
- **Tradisjonelt lag** (API-kall mot PG) — for alt som er retrospektivt,
utforskende, statisk. Arkiv, søk, publisering, statistikk.
### Rommet som primitiv, ikke siden
I dag navigerer brukeren mellom `/chat`, `/kanban`, `/kalender`. I "rom"-modellen
er brukeren alltid *et sted*, og funksjonalitet er lag som kan slås av og på:
chat-laget, oppgave-laget, tidslinje-laget. Alt eksisterer i samme sanntidsrom.
### Tilstedeværelse som førsteklasses konsept
Hvem er her nå? Hva ser de på? Hva jobber de med? I en tradisjonell webapp er
dette en "feature" (online-indikator). I rom-modellen er det fundamentet alt
annet bygger på.
### Interaksjon før organisering
I dag: lag et kanban-kort → fyll ut feltene → flytt det. I rom-modellen: si noe,
tegn noe, del noe → det som oppstår kan *bli* et kort, en oppgave, en notis —
organisering skjer etterpå, ikke som forutsetning.
## Den administrative opplevelsen
Tesen ovenfor kan føles abstrakt. Mer konkret: Sidelinja bør være en
**administrativ opplevelse** — ikke et spill med avatarer, men et arbeidsmiljø
der produktive ting er lette å oppnå og strukturen følger deg, ikke omvendt.
### Formløs input, struktur etterpå
Input trenger ikke vite hva den *er* på forhånd. En tanke starter som en
løs setning i input-feltet. Etterpå kan den *føde* et kanban-kort, en
faktoid, en artikkel — brukeren drar den til riktig verktøy-panel på
arbeidsflaten, og en ny node opprettes med riktige edges. Originaltanken
forblir uendret. Verktøy-panelene bestemmer strukturen, ikke input-metoden.
Se [arbeidsflaten](arbeidsflaten.md).
### Trylle frem, legge fra seg
Trenger du et whiteboard? Det dukker opp. En videosamtale? Den starter.
En dagbok? Den er der. Og når fokuset tar en annen retning legger du det
fra deg uten at det blir borte — kunnskapsgrafen holder styr på det. Du
trenger ikke "lukke" noe eller "lagre" noe. Ting eksisterer i verden
og kan gjenfinnes.
### Siloer forsvinner
Universell overføring er ikke en separat feature — det er selve
interaksjonsmønsteret. Verktøy-paneler lever side ved side på
arbeidsflaten, og drag-and-drop mellom dem er den primære flyten.
Du flytter ikke innhold mellom apper — du drar det fra et verktøy
til et annet i rommet du allerede er i. Chat, kanban, kalender er
visninger av samme graf, arrangert på samme flate.
### Privat og delt som lag, ikke separate systemer
Privat/delt er bare en
synlighetsbryter på alt du gjør. Du chatter med en kollega og samtidig skriver
du dagbok — begge er meldingsbokser, den ene er delt, den andre er privat.
De eksisterer side om side i samme rom.
Dette åpner for naturlig flyt mellom kontekster: du sitter på bussen, snakker
inn en tanke via voice, den transkriberes automatisk og lander som en privat
meldingsboks — dagboknotis, oppgavepåminnelse, idé til neste episode. Du
trenger ikke åpne "dagbok-appen" eller "notat-appen." Du bare snakker, og
systemet tar vare på det riktig sted basert på kontekst og synlighet.
Input-metode (tekst, voice, tegning) og synlighet (privat, delt, publisert)
er ortogonale egenskaper. Ingen av dem bør diktere *hva* innholdet blir.
### PG som eneste kilde, WebSocket som sanntidslag
PG briljerer som både arkiv og sanntidskilde: relasjonelle spørringer
over historikk, fulltekstsøk, pgvector for semantisk søk, aggregeringer
og statistikk. LISTEN/NOTIFY + WebSocket gir sanntidsoppdatering uten
et ekstra system. Å trylle frem et whiteboard er bare å opprette en node
— WebSocket-strømmen sørger for at alle ser det umiddelbart.
## Spenninger og åpne spørsmål
- **Ytelse.** En alltid-på sanntidsopplevelse krever mer av både klient og
server enn tradisjonelle sideinnlastinger.
- **Kompleksitet.** "Alt er et rom" høres elegant ut, men kan bli kaotisk.
Hvordan unngår vi at det blir uoversiktlig?
- **Discovery vs fokus.** "Alt kan bli hva som helst" er kraftig, men kan
bli overveldende. Et whiteboard du tryller frem må være like lett å finne
igjen om tre uker. Kunnskapsgrafen er kanskje svaret — den er allerede
designet for å koble ting uavhengig av type.
- **~~Gradvis overgang.~~** *(Løst — se "Innebygd utviklingsstrategi" nedenfor.)*
- **Solo-bruk.** Mye av verdien i "rom" kommer fra å være der sammen. Hvordan
føles det for én person som jobber alene?
- **Er det vi allerede har?** Meldingsboks-konseptet og universell overføring
peker allerede i denne retningen. Kanskje dette ikke er en ny retning,
men en artikulering av det vi ubevisst har bygget mot?
- **Inspirasjon.** Spillverdener (MMO-lobbyer, shared spaces), Figma (alle i
samme canvas), tldraw, Gather.town. Hva kan vi lære fra disse?
## Innebygd utviklingsstrategi
To-lags-modellen gir en viktig implikasjon for utviklingen: **innebygd fallback
og to veier inn til alt.**
Ny funksjonalitet kan alltid starte som tradisjonell request/response mot PG.
Sanntidsoppdatering kommer gratis via LISTEN/NOTIFY + WebSocket — ingen
separat "løfting" til et sanntidslag nødvendig.
Dette betyr:
- **Ingenting vi har bygget er bortkastet.** Eksisterende PG-baserte features
er fullverdige og har sanntid via WebSocket.
- **Ingen stor omskriving.** Retningen er en utviklingsstrategi: bygg mot PG,
sanntid følger automatisk.
- **Risikoen er lav.** PG er stabil og velprøvd.
- **Primitivene er nøkkelen.** Så lenge noder, edges og kunnskapsgrafen er
fleksible nok, holder arkitekturen uavhengig av kontekst.
## Kritisk vurdering
### Sanntidslaget er PG-basert
SpacetimeDB ble fjernet (mars 2026). Sanntid leveres nå via PG
LISTEN/NOTIFY + WebSocket. Én datakilde, ingen synkroniseringskompleksitet.
### "Formløs input" er vanskelig i praksis
Det høres elegant ut, men noen må bestemme hva noe *blir*. AI? Brukeren
etterpå? Automatiske regler? Notion, Roam Research og mange andre startet
med lignende ambisjoner og endte opp med å gi brukeren eksplisitte
strukturverktøy — fordi ambiguitet i praksis skaper friksjon, ikke flyt.
Risikoen er at vi bygger noe som føles magisk i demoen og forvirrende i
hverdagen.
### Grensen mellom "nåtid" og "arkiv" er uklar
En samtale fra i går som fortsatt er relevant — er den "nå" eller "arkiv"?
Et kanban-kort som har stått stille i to uker? Vi trenger regler for når ting
flyttes mellom lagene, og de reglene kan bli like komplekse som
reglene de erstatter. "Tid og arkiv" er renere *i prinsippet*,
men i praksis er "aktiv" et spektrum, ikke en binær tilstand.
### Solo-bruk er underadressert
Vegard er primærbruker. "Rom"-konseptet henter mye av sin kraft fra
tilstedeværelse og samarbeid. For én person som produserer podcast er det
en reell risiko at sanntidslaget er overhead sammenlignet med et godt
organisert tradisjonelt verktøy. *Mildnet* av at PG-basert sanntid har null overhead — WebSocket
leverer oppdateringer uten ekstra lag å vedlikeholde.
### Omfanget
*Betydelig mildnet* av at sanntid nå er innebygd i arkitekturen via
PG LISTEN/NOTIFY + WebSocket. Ingen vurdering "bør dette være sanntid?"
nødvendig — alt som skrives til PG propageres automatisk.