Oppdatert basert på ekstern tilbakemelding. Nye proposals for kildevern, podcasting 2.0, web clipper, waveforms, editor, tekst-primitiv og avisvisning. Oppdatert meldingsboks med slette-semantikk, entity resolution i kunnskapsgrafen, og AI gateway med kildevern-modus. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
122 lines
6.4 KiB
Markdown
122 lines
6.4 KiB
Markdown
# Forslag: Tekst-primitiv
|
||
|
||
## Idé
|
||
Det finnes ingen forskjell mellom en chatmelding og en artikkel — bare ulike stadier av samme ting. Enhver tekst starter som det enkleste ("hei") og kan vokse til hva som helst: få en tittel, bli rik-formatert, dras inn i en kalender, publiseres på web. Alt er samme node, samme primitiv. Brukeren bestemmer aldri "type" på forhånd — de bare skriver, og utvider når det føles naturlig.
|
||
|
||
## Kjerneprinsipp: Enhver melding kan vokse
|
||
|
||
```
|
||
"hei" → ren tekst
|
||
"hei, her er mine tanker..." → brukeren utvider → toolbar dukker opp
|
||
+ tittel → den har nå et navn
|
||
+ overskrifter, lister → strukturert innhold
|
||
+ bilder, LaTeX, embeds → rikt innhold
|
||
+ kanban_card_view → oppgave
|
||
+ calendar_event_view → kalenderhendelse
|
||
+ article_view → publiserbar artikkel
|
||
```
|
||
|
||
Ingen "oppgradering", ingen "konvertering", ingen modusskifte i data. Noden er den samme hele veien. View-configs legges til og fjernes fritt — de er additive, aldri destruktive.
|
||
|
||
### Hva dette betyr i praksis
|
||
- En chatmelding i #Mediepolitikk kan få en tittel → den er nå et notat
|
||
- Det notatet kan dras til kanban → det er nå også en oppgave
|
||
- Samme notat kan få `article_view` → det er nå publiserbart
|
||
- Alt uten å kopiere, flytte, eller miste kontekst (reply_to-kjeden, graf-edges, reaksjoner)
|
||
|
||
Dette er meldingsboks-filosofien tatt til sin logiske konklusjon: ikke bare "én primitiv, flere views", men "én primitiv som vokser organisk med brukerens intensjon".
|
||
|
||
## Hvorfor er dette interessant?
|
||
|
||
### Rekkefølgeproblemet
|
||
Brukeren vet sjelden på forhånd hva en tekst skal bli. Man skriver, tenker, og innser: "dette bør bli noe mer". Ved å la enhver melding vokse forsvinner problemet — veien fra tanke til publisering er bare å legge til, aldri å starte på nytt.
|
||
|
||
### Konsistens
|
||
- Én primitiv i hele systemet (meldingsboksen)
|
||
- `#`-mentions fungerer overalt — chat, notater, artikler — samme mekanisme
|
||
- Graf-koblinger er universelle — en mention i chat og en mention i en publisert artikkel er identisk
|
||
- Versjonshistorikk (`message_revisions`) følger med uansett hvor teksten ender opp
|
||
|
||
## Hva bygger den på?
|
||
- **Meldingsboks** — enhver tekst er en melding (node i grafen)
|
||
- **Kunnskapsgraf** — `#`-mentions oppretter graf-edges uansett kontekst
|
||
- **Message revisions** — revisjonshistorikk allerede på plass
|
||
- **View-configs** — kanban_card_view, calendar_event_view, article_view er bare pekere
|
||
|
||
## Skisse
|
||
|
||
### Visibility-trappen
|
||
En melding kan bevege seg gjennom synlighetsnivåer uten å endre identitet:
|
||
|
||
```
|
||
'private' → kun forfatter (kladd, personlig notat)
|
||
'workspace' → alle i workspacet (delt internt)
|
||
'link' → hvem som helst med URL-en (Google Docs-modell, ingen indeksering)
|
||
'public' → publisert (indeksert, i feeds, full SEO)
|
||
```
|
||
|
||
Hvert steg er reversibelt. En publisert artikkel kan trekkes tilbake til `'workspace'`. En privat kladd kan deles med én lenke uten å bli offentlig.
|
||
|
||
### Delbare URL-er
|
||
Enhver melding med `visibility: 'link'` eller `'public'` får en URL:
|
||
```
|
||
sidelinja.org/delt/<uuid> → enkel deling (lesbar med lenke, ingen SEO)
|
||
sidelinja.org/@vegard/<slug> → publisert artikkel (SEO, feed, OG-tags)
|
||
sidelinja.org/pub/<publikasjon>/<slug> → kuratert artikkel (se artikkel-publisering)
|
||
```
|
||
|
||
### `article_view` — publiseringslaget
|
||
Når en tekst skal publiseres, legges en view-config til:
|
||
|
||
```sql
|
||
CREATE TABLE article_view (
|
||
message_id UUID PRIMARY KEY REFERENCES messages(id) ON DELETE CASCADE,
|
||
slug TEXT NOT NULL,
|
||
status TEXT NOT NULL DEFAULT 'draft', -- 'draft', 'review', 'published', 'archived'
|
||
excerpt TEXT,
|
||
body_html TEXT, -- Pre-rendret HTML (KaTeX + editor → HTML)
|
||
published_at TIMESTAMPTZ,
|
||
CONSTRAINT unique_slug_per_workspace UNIQUE (message_id)
|
||
);
|
||
```
|
||
|
||
### Offentlig vs intern kontekst
|
||
En publisert artikkel har to ansikter:
|
||
|
||
**Inne i workspacet:** Artikkelen er en melding i en tråd. Den har `reply_to` til meldingen som startet diskusjonen, interne svar, graf-koblinger. Full kontekst.
|
||
|
||
**Ute på web:** Artikkelen er en frittstående tekst. Den interne konteksten er usynlig. Offentlige kommentarer lever i en separat kanal (`visibility: 'public'`) som workspace-medlemmer kan se, men som ikke blander seg med den interne diskusjonen.
|
||
|
||
```
|
||
article_node (melding i workspace)
|
||
├── reply_to → intern forelder (usynlig utenfra)
|
||
├── channel: #Mediepolitikk (intern diskusjon)
|
||
└── public_comment_channel (offentlige kommentarer, separat)
|
||
```
|
||
|
||
## Åpne spørsmål
|
||
|
||
### Versjoner og kladder
|
||
- Er det nok med `message_revisions` (lineær historikk), eller trengs navngitte versjoner / snapshots?
|
||
- Bør ulike versjoner kunne ha ulik visibility? ("kladd 1 er privat, kladd 2 er delt med lenke, publisert versjon er offentlig")
|
||
- Eller er det enklere: én tekst, én visibility, revisjonshistorikk under panseret?
|
||
|
||
### Grensen melding ↔ artikkel
|
||
- Teknisk: ingen grense. En melding med `article_view` er en artikkel.
|
||
- UX-messig: når tilbyr systemet "vil du publisere dette?" Manuelt via meny? Automatisk forslag når teksten når en viss lengde/kompleksitet?
|
||
|
||
### Offentlige kommentarer
|
||
- Hvem kan kommentere? Anonymt, autentisert, inviterte?
|
||
- Enkleste start: ingen offentlige kommentarer. Artikler er read-only for publikum. Diskusjon skjer internt eller via eksterne kanaler.
|
||
|
||
## Innsats: Lav (prinsipp) / Middels (article_view + visibility)
|
||
Prinsippet krever ingen ny kode — meldingsboksen støtter det allerede. `article_view`-tabell og visibility-utvidelse er overkommelig. Den tunge delen er editoren (se `editor.md`).
|
||
|
||
## Wow-faktor: Middels–Høy
|
||
Filosofien — at enhver tekst kan bli hva som helst — er enableren for personlig workspace, artikkel-publisering, samarbeid og kurasjon.
|
||
|
||
## Relasjon til andre proposals
|
||
- **Editor** — det tekniske skriveverktøyet som gjør alt dette mulig i UI
|
||
- **Personlig workspace** — konteksten der brukeren kladder og publiserer
|
||
- **Artikkel-publisering** — publiseringsmodellen (publikasjoner, kuratorer, feeds) bygger på tekst-primitiven
|
||
- **Meldingsboks** (feature) — tekst-primitiven er den naturlige utviklingen: "én primitiv som vokser med brukerens intensjon"
|