Changeset 19430fa in Klonkt for src/services/ArchiveImportService.js

Timestamp:

08/14/2026 12:40:43 AM (4 weeks ago)

Author:

Robin <roboburr@…>

Branches:

main

Children:

5a49eba

Parents:

919b82d

Message:

GUID's blijven altijd behouden bij een verhuizing

Robin vroeg of we bestaande GUID's hergebruiken. Het antwoord was zes vakjes:

zip ophaalknop

posts nieuw bij andere origin altijd nieuw
tracks OUD BEHOUDEN altijd nieuw
playlists OUD BEHOUDEN altijd nieuw

Vier keer nieuw, twee keer niet, en die twee uitzonderingen waren niet
besloten maar ontstaan: de zip schreef INSERT OR REPLACE met het id uit het
archief zonder dat daar ooit over nagedacht is. Die scheve tabel was precies de
oorzaak van de shortcode die Robin op TikTik zag: post uit de zip met
[[track:oud]], nummer uit de pull met een nieuw id.

Zijn besluit: altijd behouden. Nu is het één regel.

WAAROM DAT MAG. Het interne id is niet de AP-URI. ​https://nieuw/ap/notes/<id>
is een ander adres dan ​https://oud/ap/notes/<id>, dus je claimt niets van een
ander door het GUID te hergebruiken. Het oude argument in de code ("een id op
andermans domein publiceren is een vervalsingsoppervlak") haalde die twee door
elkaar. Wat je wint: elke interne verwijzing blijft kloppen, [[track:]],
[[playlist:]] en [[album:]] wijzen na de verhuizing nog naar het goede ding.

Wat NIET verandert is de AP-URI. Die is domeingebonden en hoort nieuw te zijn,
en daar is de migration-collectie voor. idsBehouden gaat voortaan alleen daar
nog over.

Gemeten door dezelfde inhoud via BEIDE routes over elkaar heen te halen:

posts oud 6 | nieuw 6 | zelfde id 6 | afwijkend 0
audio_tracks oud 3 | nieuw 3 | zelfde id 3 | afwijkend 0
playlists oud 1 | nieuw 1 | zelfde id 1 | afwijkend 0

Geen dubbele. Zip en ophaalknop zijn daarmee inwisselbaar geworden, en dat was
eerder de combinatie die stukging.

Changed files:
src/services/ArchiveImportService.js

• posts houden hun id, ongeacht de origin
• de waarschuwing zegt nu wat er echt verandert: het AP-adres, niet het id

src/services/MigrationService.js

• posts, tracks en playlists nemen het id van de bron over
• "staat hij hier al" is daarmee een blik in de tabel in plaats van een omweg via ap_migration; verwijderen en opnieuw ophalen werkt vanzelf
• de eerderPl/eerder-omwegen konden weg

test/archive-import.test.js

• de origin-test omgedraaid: het AP-adres verandert, het id blijft

test/fep1580-migration.test.js

• de shortcode-test toetst nu de UITKOMST (wijst naar een bestaand nummer) in plaats van de route ernaartoe
• nieuwe test voor het botsingsgeval, waar het bijtrekken wel nodig is

remarks: het bijtrekken van [[track:]] blijft bestaan als vangnet voor een
botsend id. In het normale geval doet het niets meer, en dat is de bedoeling.
Suite 991 groen.

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

File:

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

src/services/ArchiveImportService.js

@@ -285 +285 @@
   rapport.origin = manifest.origin || null;
 
-  // IDENTITEIT. Gelijke origin -> de AP-ids blijven, en daarmee vinden de boosts
-  // en antwoorden die er al naar wijzen hun post terug. Anders nieuwe ids, want
-  // een id op andermans domein publiceren is een vervalsingsoppervlak en andere
-  // servers halen het daar toch op.
+  // IDENTITEIT. Het INTERNE id blijft altijd (Robins besluit, 14-8).
+  //
+  // Dat is iets anders dan de AP-URI. Die is domeingebonden en wordt hoe dan
+  // ook nieuw: https://nieuw/ap/notes/<id> is een ander adres dan
+  // https://oud/ap/notes/<id>. Je claimt dus niets van een ander door het GUID
+  // te hergebruiken, en je wint dat elke INTERNE verwijzing blijft kloppen:
+  // [[track:]], [[playlist:]] en [[album:]] wijzen na een verhuizing nog naar
+  // het goede ding.
+  //
+  // Voorheen hing dit aan de origin, en alleen voor posts; tracks en playlists
+  // hielden hun id al wel. Die scheve tabel was precies waarom een post uit de
+  // zip met [[track:oud]] naast een nummer uit de pull met een nieuw id kwam te
+  // staan, en je de shorthand als kale tekst in je bericht zag.
+  //
+  // `idsBehouden` gaat hieronder alleen nog over de AP-URI: gelijke origin
+  // betekent dat ook die identiek blijft, en dan valt er niets te vertalen.
   const idsBehouden = !!(manifest.origin && eigenOrigin && manifest.origin === eigenOrigin);
   rapport.idsBehouden = idsBehouden;
   if (!idsBehouden) {
     rapport.waarschuwingen.push(
-      `origin verschilt (archief ${manifest.origin || '?'} vs deze site ${eigenOrigin || '?'}): nieuwe AP-ids, de oude blijven als verwijzing staan`,
+      `origin verschilt (archief ${manifest.origin || '?'} vs deze site ${eigenOrigin || '?'}): de berichten krijgen een nieuw AP-adres. Hun interne id blijft, dus verwijzingen binnen je site blijven kloppen.`,
     );
   }
@@ -307 +319 @@
     const o = JSON.parse(files.get(pad).toString('utf8'));
     const oudId = decodeURIComponent(String(o.id || '').split('/ap/notes/')[1] || path.basename(pad, '.json'));
-    const nieuwId = idsBehouden ? oudId : randomUUID();
+    // Altijd het id uit het archief. Staat er hier al iets met dat id, dan is
+    // dat hetzelfde object, en dat handelt de botsingscontrole hieronder af.
+    const nieuwId = oudId;
     idKaart.set(oudId, nieuwId);