synops/docs/retninger/rom_ikke_forum.md

# 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. SpacetimeDB ble lagt til
for sanntid, men arkitekturen er 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.
- **Databasespenning.** PG og SpacetimeDB har et komplisert eierforhold.
  SpacetimeDB-loven løser grensesnittet, men ikke det underliggende spørsmålet:
  hva *er* primæropplevelsen?
- **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?

### SpacetimeDB som verden, PG som arkiv
SpacetimeDB er ikke en "sanntidskache foran PG" — det er verdenen brukerne
lever i. PG er arkivet som husker hva som har skjedd.

Rollene blir klare og adskilte:
- **SpacetimeDB** = sanntidslaget. Aktivt samarbeid, live interaksjon,
  ting som skjer *nå*.
- **PostgreSQL** = arkivet. Alt som noensinne har skjedd. Søk, historikk,
  statistikk, revisjon.

Men viktig: sanntidslaget er *bare* et sanntidslag. Ikke alt trenger
sanntid. En kunnskapsgraf-utforsker, et søk i gamle episoder, en
statistikkside, en offentlig publisert artikkel — disse snakker rett med
PG-arkivet som tradisjonelle nettsider. De trenger ikke gå gjennom
SpacetimeDB. Begge lagene leser og skriver til det samme arkivet.

Dermed har vi to parallelle overflater:
- **Sanntidsopplevelsen** (via SpacetimeDB) — for alt som er levende,
  aktivt, samarbeidende. Chat, whiteboard, live redigering.
- **Tradisjonelt lag** (rett mot PG) — for alt som er retrospektivt,
  utforskende, statisk. Arkiv, søk, publisering, statistikk.

Dataflyt mellom dem: ting som oppstår i sanntidslaget synkes til PG.
Ting i PG kan løftes inn i sanntidslaget når de blir aktive igjen.
Men det er ingen eierskapskonflikt — de to lagene har fundamentalt
forskjellige roller. Det er ikke to konkurrerende sannheter, det er
*nåtid* og *arkiv*, med to overflater som passer til hver sin rolle.

### 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å
I dag velger du visning først: "nå er jeg i chat", "nå er jeg i kanban." Men
meldingsboksen er allerede designet for at input ikke trenger å vite hva den
*er* på forhånd. En tanke bør kunne starte som en løs setning og bli et
kanban-kort, en faktoid, en kalenderoppføring — uten at brukeren måtte
bestemme det på forhånd. Visninger er flyktige linser. Innhold er permanent.

### 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" som eksplisitt feature blir overflødig fordi det
ikke finnes separate steder å overføre *mellom*. Du endrer ikke *hvor*
noe er — du endrer *hvordan* du ser på det som allerede er der. Chat,
kanban, kalender er ikke apper — de er visninger av samme tilstandsrom.

### 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.

### SpacetimeDB som naturlig motor
SpacetimeDB tenker "dette eksisterer i verden nå" — ikke "lagre dette i
riktig tabell." Å trylle frem et whiteboard er naturlig i en verden-modell:
det er bare et nytt objekt med en tilstand. I PG-modellen må du opprette
rader, definere relasjoner, sette opp persistens. SpacetimeDB låner seg
til flytende, formløs interaksjon på en måte PG ikke gjør.

PG briljerer i rollen som arkiv: relasjonelle spørringer over historikk,
fulltekstsøk, pgvector for semantisk søk, aggregeringer og statistikk.
Når du spør "hva snakket vi om i mars?" er det PG som svarer. Når du
spør "hva skjer nå?" er det SpacetimeDB.

## Spenninger og åpne spørsmål

- **Ytelse.** En alltid-på sanntidsopplevelse krever mer av både klient og
  server enn tradisjonelle sideinnlastinger. Er SpacetimeDB klar for dette?
- **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, universell overføring og
  SpacetimeDB-loven 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 i det tradisjonelle laget — rett mot PG,
vanlig request/response, kjent terreng. Den fungerer med en gang. Når det
senere gir verdi (samarbeid, sanntid, live interaksjon) kan den løftes inn
i sanntidslaget. Men den trenger ikke det for å være nyttig.

Dette betyr:
- **Ingenting vi har bygget er bortkastet.** Eksisterende PG-baserte features
  er ikke "gammel arkitektur" — de er det tradisjonelle laget, og det er et
  fullverdig lag.
- **Ingen stor omskriving.** Retningen er ikke en migrasjon med en frist. Den
  er en utviklingsstrategi: bygg tradisjonelt, løft til sanntid ved behov.
- **Risikoen er lav.** Hvis SpacetimeDB skuffer, har vi fortsatt et komplett
  tradisjonelt system. Hvis det leverer, får ting gradvis en rikere opplevelse.
- **Primitivene er nøkkelen.** Så lenge meldingsboksen og kunnskapsgrafen er
  fleksible nok, kan begge lag bruke dem. Arkitekturen holder uavhengig av
  hvilket lag en feature lever i.

## Kritisk vurdering

### SpacetimeDB er en ung teknologi
Å lene seg tungt på SpacetimeDB er et veddemål. Hvis prosjektet stagnerer,
endrer API, eller har skaleringstak vi ikke ser ennå — er vi eksponert.
*Mildnet* av at det tradisjonelle laget mot PG alltid finnes som fallback:
SpacetimeDB er ikke alt-eller-ingenting, men et lag for det som trenger
sanntid. Resten lever trygt mot PG uansett.

### "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
SpacetimeDB-loven 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 to-lags-modellen: solo-bruk
kan lene seg tyngre på det tradisjonelle PG-laget, og sanntidslaget
aktiveres når det faktisk gir verdi (live innspilling, samarbeid).

### Omfanget
*Betydelig mildnet* av utviklingsstrategien ovenfor. Retningen krever ikke
en omskriving — den er kompatibel med inkrementell utvikling. Den
gjenværende risikoen er mer subtil: at vi bruker mental energi på å
vurdere "bør dette være sanntid?" for hver feature i stedet for å bare
bygge. Pragmatisk default bør være: bygg tradisjonelt, løft senere.