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.