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.
186 lines
9.1 KiB
Markdown
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.
|