server/docs/proposals/artikkel_publisering.md

# Forslag: Artikkel-publisering og publikasjonsmodell

## Idé
Utvide Sidelinja til en publiseringsplattform der individuelle skribenter og redaksjonelle team kan skrive, samarbeide på, og publisere tekster. Inspirert av Substack (individuell publisering), men med en kollaborativ og kuratorisk dimensjon: en tekst eies av noen, samarbeides med noen, og publiseres av én eller flere.

## Designfilosofi

### Vakre tekster
Sidelinja-artikler skal føles som noe mellom en Substack-essay og en akademisk publikasjon. Ingen sidebar-rot, ingen widget-helvete. Bare tekst, typografi og innhold.

**Prinsipper:**
- **Typografi først.** Seriffont for brødtekst (Georgia, Literata), god linjehøyde (1.6–1.8), komfortabel lesbredde (60–75 tegn). Overskrifter i sans-serif for kontrast.
- **Luft.** Generøse marginer. Innholdet puster.
- **Mørk/lys.** Respekterer `prefers-color-scheme`. Begge moduser like gjennomtenkte.
- **Matematikk er førsteklasses.** KaTeX for LaTeX-notasjon, server-side-rendret.
- **Ingen visuell støy.** Metadata diskret plassert. Fokus er teksten.

**Inspirasjon:** Gwern.net (typografi + fotnoter), Distill.pub (interaktive figurer), Stratechery (ren leseopplevelse), Edward Tufte (informasjonstetthet uten rot).

### Teksten som primitiv
En artikkel er ikke en egen ting — den er en melding med `article_view` (se `tekst_primitiv.md`). Samme meldingsboks-filosofi: én primitiv, flere formål. Det som gjør dette til noe mer enn "bare en editor" er *publikasjonsmodellen*.

## Hvorfor er dette interessant?

### Publiseringslandskapet har et hull
De fleste plattformer tvinger deg til å velge:
- **Individuell blogg** (WordPress, Substack) — du skriver alene, du publiserer alene
- **Redaksjonelt fellesprosjekt** (nettavis, magasin) — alt er felles, individet forsvinner

Virkeligheten er mer nyansert:
- Individuelle skribenter skriver sitt eget
- Samarbeidende team gjør sin kollaborative greie
- Alle publiserer sitt eget (personlig feed/blogg)
- En redaktør/publikasjon kan *kuratere* — plukke opp individuelle tekster til en felles utgivelse
- Lesere abonnerer fast på noen skribenter, velger selektivt fra andre

Sidelinja kan modellere alt dette fordi primitiven er riktig: **en tekst eies av en forfatter, kan ha medforfattere, og kan publiseres i flere kontekster**.

### Naturlig forlengelse av eksisterende features
- Redaksjonen har chat, AI-behandling og kunnskapsgraf. Artikler er neste steg — fra intern diskusjon til publisert innhold.
- Grafkobling: en artikkel arver automatisk koblinger til temaer, aktører og episoder via `#`-mentions.
- SEO: podcast-innhold er vanskelig å søkemotor-indeksere. Artikler gir tekstlig innhold som rangerer.
- Show notes 2.0: kan bli fullverdige artikler med egne URL-er.

## Hva bygger den på?
- **Tekst-primitiv** (proposal) — `article_view`, WYSIWYG-editor, lagringsformat
- **Kunnskapsgraf** — artikkel er en melding (node) med edges til temaer/aktører
- **Personlig workspace** (proposal) — personlig publisering
- **Jobbkø** — AI-assistert skriving, faktasjekk, oppsummering
- **Caddy** — servering av publiserte artikler

## Skisse

### Publikasjonsmodellen

#### Publikasjon som node
En publikasjon er en ny `node_type` — en kuratert samling tekster med egen identitet:

```sql
ALTER TYPE node_type ADD VALUE 'publikasjon';

CREATE TABLE publications (
    id           UUID PRIMARY KEY REFERENCES nodes(id) ON DELETE CASCADE,
    name         TEXT NOT NULL,
    slug         TEXT NOT NULL UNIQUE,      -- URL-prefiks
    description  TEXT,
    avatar_url   TEXT,
    owner_id     TEXT REFERENCES users(authentik_id) ON DELETE SET NULL,
    created_at   TIMESTAMPTZ NOT NULL DEFAULT now()
);
```

Typer publikasjoner:
- **Personlig feed** — implisitt, én per bruker, knyttet til personlig workspace
- **Redaksjonell publikasjon** — opprettet manuelt, flere kuratorer
- **Tematisk feed** — automatisk generert fra graf-spørringer ("alt tagget med #Skolepolitikk")

#### `PUBLISHED_IN`-edge
En tekst publiseres i en publikasjon via en graf-edge:

```sql
-- Ny relation_type: 'PUBLISHED_IN'
-- source_id = melding (artikkel)
-- target_id = publikasjon
-- origin = 'user' (forfatter publiserer selv) eller 'curator' (redaktør plukker opp)
-- context_id = NULL (eller referanse til kurateringsforespørsel)
```

En tekst kan ha flere `PUBLISHED_IN`-edges — publisert i forfatterens personlige feed *og* i redaksjonens magasin. Ingen kopiering — bare flere edges til samme node.

#### Samarbeid: medforfattere
En tekst har én `author_id` (eier) i `messages`. Medforfattere modelleres som:

```sql
-- Ny relation_type: 'CONTRIBUTED_BY'
-- source_id = melding (artikkel)
-- target_id = entitet (person) eller bruker-node
-- confidence = NULL
-- origin = 'user'
```

Medforfattere kan redigere teksten (tilgangskontroll i appkode). Kreditering vises i publisert artikkel.

### URL-struktur
```
sidelinja.org/@vegard/                      → Vegards personlige feed
sidelinja.org/@vegard/skolepolitikk-2026    → Enkeltartikkel (personlig)
sidelinja.org/pub/sidelinja-magasinet/      → Redaksjonell publikasjon
sidelinja.org/pub/sidelinja-magasinet/artikkel-slug  → Artikkel i publikasjon
sidelinja.org/feed/@vegard.xml              → Personlig Atom-feed
sidelinja.org/feed/pub/sidelinja-magasinet.xml  → Publikasjons-feed
```

### Kurateringsflyt
```
Forfatter skriver tekst i sitt workspace
  → Publiserer i personlig feed (@vegard/slug)
  → Redaktør ser teksten (følger forfatteren, eller finner via graf)
  → Redaktør "kuraterer" teksten til sin publikasjon
     → Ny PUBLISHED_IN-edge med origin: 'curator'
     → Teksten dukker opp i publikasjonens feed
     → Forfatter varsles, kan godkjenne/avslå
```

### Abonnementer
Lesere kan følge:
- En forfatter (personlig feed)
- En publikasjon (redaksjonell feed)
- Et tema (automatisk feed fra graf)

**Ekstern distribusjon:** Atom/RSS-feeds for alt. Ingen e-postavhengighet (anti-Substack). Lesere bruker sin egen feed-reader.

**Intern distribusjon (fremtidig):** Notifikasjoner i appen. Men RSS er minimum viable — funker fra dag 1 uten notifikasjonssystem.

### Innholdsformat og rendering
Se `tekst_primitiv.md` for editor og lagringsformat. Tillegg for publiserte artikler:

- **KaTeX server-side rendering** — `body_html` i `article_view` inneholder ferdig-rendret HTML med KaTeX. Ingen JavaScript for lesere.
- **Sidemerknad-fotnoter** (Tufte-stil) — vises i margen på brede skjermer (>1200px), popup på mobil.
- **Podcast-embeds** — `{{segment:uuid}}` rendrer innebygd lydspiller med transkripsjon.
- **OG-tags** — automatisk generert Open Graph-metadata per artikkel.

### Typografi-stack (CSS)
```
Brødtekst:    Literata / Georgia / serif      (1.6 linjehøyde, 60–75ch bredde)
Overskrifter: Inter / system-ui / sans-serif  (stramt, tydelig hierarki)
Kode:         JetBrains Mono / monospace      (med ligaturer)
Matematikk:   KaTeX default                   (skalerer med brødtekst)
```

## Åpne spørsmål

### Publikasjonsmodell
- Bør en forfatter godkjenne at teksten kurateres av en publikasjon, eller er det implisitt tillatt?
- Kan en publikasjon ha eksklusivitet (teksten publiseres *bare* der)?
- Hvem eier kommentarfeltet på en kuratert tekst — forfatteren eller publikasjonen?

### Samarbeid
- Er `CONTRIBUTED_BY`-edge nok for medforfatterskap, eller trengs en egen `article_collaborators`-tabell med rolleinfo (forfatter, redaktør, korrekturleser)?
- Sanntids samredigering (Yjs) fra dag 1, eller auto-save + manuell koordinering?

### Kommentarer: to kanaler, én node
En publisert artikkel har to separate diskusjonsrom:

1. **Intern kontekst** — den opprinnelige `reply_to`-kjeden og workspace-channelen artikkelen tilhører. Usynlig utenfra. En artikkel som startet som et svar i #Mediepolitikk beholder hele den interne tråden — men den lekker aldri ut.

2. **Offentlig kommentarkanal** — en separat channel med `visibility: 'public'`, knyttet til artikkelen via `article_view.comment_channel_id`. Workspace-medlemmer ser begge kanaler. Publikum ser bare den offentlige.

Åpne spørsmål rundt offentlige kommentarer:
- Hvem kan kommentere? Anonymt, autentisert (Authentik), kun inviterte?
- Moderasjon: forfatter, workspace-admin, eller begge?
- Enkleste start: ingen offentlige kommentarer (read-only for publikum). Arkitekturen tillater det via nullable `comment_channel_id`, men det bygges først når behovet er reelt.

### Tematiske feeds
- Automatisk feed basert på graf-spørringer ("alle artikler med MENTIONS-edge til #Skolepolitikk") — er dette en publikasjon, eller et separat konsept?
- Trolig: en publikasjon med `type: 'auto'` og en lagret graf-spørring. Men det er et steg videre.

### Versjonering
- Bør publiserte artikler ha synlig versjonering (à la Wikipedia)? `message_revisions` gir historikk allerede, men det er et spørsmål om det eksponeres til lesere.

### Bilder og media
- Content-addressable via `media_files` (eksisterende), eller CDN?
- Bildeoptimalisering (responsive `srcset`) for publiserte artikler?

## Innsats: Middels-Stor
Datamodellen (publikasjoner, `PUBLISHED_IN`-edges) er overkommelig. Typografi og leseopplevelse krever CSS-arbeid. Kurateringsflyten er det mest komplekse — men kan bygges inkrementelt.

## Wow-faktor: Høy
Kombinasjonen av vakker typografi, individuelle forfattere, kollaborativt forfatterskap og kuratoriske publikasjoner — integrert med kunnskapsgraf og podcast-embeds — er noe som ikke finnes andre steder. En publiseringsplattform der en politisk analyse kan ha formler, lydklipp fra intervjuer, og koblinger til kunnskapsgrafen.

## Relasjon til andre proposals
- **Tekst-primitiv** — fundament: editor, `article_view`, lagringsformat
- **Personlig workspace** — kontekst: der individet skriver og publiserer fra
- Denne proposalen handler om *hva som skjer etter at teksten er skrevet* — publisering, kurasjon, distribusjon, leseopplevelse