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

9.1 KiB

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.

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.