Changeset fbfd7a1 in Klonkt for src/services/ArchiveImportService.js

Timestamp:

08/13/2026 10:34:36 PM (4 weeks ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

6c4ff7e

Parents:

4101c89

Message:

Je berichten verhuizen mee: FEP-1580 plus een webinterface ervoor

FEP-7628 verhuist je volgers en zegt zelf dat de inhoud een ander probleem is.
Dat probleem stond open: na een Move bleven je berichten op de oude instantie
staan, en elke reactie van een derde wees naar een URI die verdwijnt zodra dat
domein opgezegd wordt. FEP-1580 regelt dat, status DRAFT.

DE AUTORISATIE IS DE MOVE, NIET EEN CODE. De bronkant behandelt een ondertekend
verzoek namens de doel-actor alsof de bron-actor het zelf deed. Dat mag omdat
moveAccount() no_backreference weigert: moved_to staat er alleen als de
doel-actor ons al in alsoKnownAs had. Beide kanten hebben ooit ja gezegd, dus er
is geen tweede vertrouwensmechanisme nodig. Een typefout komt hier niet binnen,
want die haalt de move zelf niet. Dat dit veilig is leunt op de keyId-binding
uit shaer-xd8i: zonder die controle is "wie tekende dit" te zacht om je hele
geschiedenis aan af te geven.

NIEUWE IDS ZIJN GEEN BUG, DE VERTAALTABEL IS HET ANTWOORD. Een verhuisd bericht
krijgt een eigen URI, want het staat op een ander domein. De migration-collectie
mapt oud naar nieuw en derden lezen die om hun eigen verwijzingen bij te werken.
Zonder die collectie is de draad kapot, met die collectie is het een
verhuisbericht. Niet-publieke items staan er alleen in voor wie ze mocht zien:
een lijst met de URIs van je fan-only posts is een lek, ook zonder de inhoud.

Er gaat geen Create de deur uit. Je volgers hebben die berichten jaren geleden
al gezien; driehonderd posts die als nieuw de tijdlijn in klateren is geen
verhuizing maar spam.

Daarnaast /admin/migrate: exporteren, importeren en ophalen via de
webinterface, zodat verhuizen geen SSH-toegang meer vraagt. Importeren gaat
altijd eerst droog, met een verslag en pas daarna een knop die het echt doet.

Getest op twee draaiende instanties, A verhuisd naar B via de echte
moveAccount. Anoniem zag A 3 van de 4 berichten; ondertekend als de doel-actor
kwamen alle 4 mee, inclusief de fan-only. Titel, webadres en publicatiedatum
blijven staan. Media komt echt over: gedownload, in de mediatabel, B serveert
het. Migration-collectie 4 rijen totaal, 3 publiek.

Changed files:
src/services/ActivityPubService.js

• isMoveTarget: het hele autorisatiepredicaat van de bronkant
• outboxAudience en mayReadNote: de doel-actor krijgt onze eigen kijkrechten
• buildActor adverteert migration en moves, ook leeg (de FEP wijst er apart op dat "niets verhuisd" anders niet te onderscheiden is van "kent dit niet")
• signedGetJson geexporteerd, de ingest heeft hem nodig
• isMoveTarget en signedGetJson in de default export (movedLock verstopte zich een dag eerder precies zo)

src/services/ap-core.js

• FEP-1580-termen in de JSON-LD-context

src/services/ArchiveImportService.js

• een import uit een zip vult dezelfde vertaaltabel; de spec wil dat een geexporteerde collectie identiek behandeld wordt

src/routes/activitypub.js

• /ap/users/:slug/migration en /moves
• de blocked-collectie gaat open voor de doel-actor, want zichtbaarheidsvoorkeuren moeten meeverhuizen

src/config/database.js

• ap_migration en ap_moves, plus sites.migration_complete

src/server.js

• /admin/migrate aangesloten

src/views/pages/admin.ejs

• knop naar Migreren

src/services/i18n.js

• mig.* in nl/en/de

New file:
src/services/MigrationService.js

• de doelkant: ingest-routine, migration- en moves-collectie, statusvlag

src/routes/admin-migrate.js

• exporteren, droog importeren, echt importeren, ophalen bij de oude Klonkt

src/views/pages/admin-migrate.ejs

• de pagina

test/fep1580-migration.test.js

• 22 tests over beide rollen, plus de regressietest bij 4101c89

remarks: FEP-8b32 ontbreekt volledig (shaer-j1v0), dus er staat geen
handtekening onder de moves-collectie en we zijn niet naleveringsklaar. Bewust
geen leeg proof-veld: een derde die het controleert wordt dan misleid. De DERDE
rol zit er ook niet in, Klonkt leest nog geen migration-collecties van anderen,
dus andermans verhuizing repareert onze verwijzingen nog niet. Alle betrokken
FEPs zijn DRAFT, ook 7628 die we al volgden; 1580 is vers en de auteur schrijft
zelf dat het een audit verdient.

-robo
Co-Authored-By: Claude Opus 4.8 <noreply@…>

File:

• src/services/ArchiveImportService.js (modified) (3 diffs)

src/services/ArchiveImportService.js

@@ -26 +26 @@
 import { MEDIA_ROOT } from '../config/paths.js';
 import { FORMAT_VERSION, parseFollowingCsv } from './ArchiveExportService.js';
+import * as Migration from './MigrationService.js';
 
 const sha256 = (buf) => crypto.createHash('sha256').update(buf).digest('hex');
@@ -255 +256 @@
     }
 
-    schrijf.push({ soort: 'post', id: nieuwId, oudId, obj: o });
+    schrijf.push({ soort: 'post', id: nieuwId, oudId, obj: o, oudeUri: o.id || null });
     rapport.posts += 1;
   }
@@ -360 +361 @@
       }
     }
+
+    // FEP-1580: een import uit een export is GEEN apart geval. De spec zegt
+    // met zoveel woorden dat objecten uit een geëxporteerde collectie net zo
+    // behandeld moeten worden als objecten die van de bron zijn opgehaald.
+    // Dus vult ook deze weg de vertaaltabel, en werkt de reactie van een derde
+    // op een verhuisd bericht straks net zo goed bij als bij een live ingest.
+    //
+    // Alleen zinnig als de ids VERANDERD zijn: bleven ze gelijk, dan wijst de
+    // oude URI al naar het goede object en valt er niets te vertalen.
+    if (!idsBehouden && eigenOrigin) {
+      for (const s of schrijf) {
+        if (s.soort !== 'post' || !s.oudeUri) continue;
+        Migration.recordMigrated(site.slug, {
+          origin: s.oudeUri,
+          target: `${eigenOrigin}/ap/notes/${encodeURIComponent(s.id)}`,
+          sourceActor: manifest.actor || '',
+          isPublic: !(s.obj && (s.obj['shaer:fanOnly'] || s.obj['shaer:apVisibility'] === 'direct')),
+        });
+      }
+    }
   })();