Changeset f2a7181 in Klonkt for deploy

Timestamp:

08/07/2026 09:10:41 AM (5 weeks ago)

Author:

roboburr <roboburr@…>

Branches:

main

Children:

d14bf1c, e5fc801

Parents:

917b22a

git-author:

Robin <roboburr@…> (08/07/2026 09:10:39 AM)

git-committer:

roboburr <roboburr@…> (08/07/2026 09:10:41 AM)

Message:

Hosterwissel, sleutels en waar de fediverse hiermee heen gaat (HOSTING.md)

Vraag van Bart: geldt een ActivityPub Move ook voor de private sleutel als alleen
de hoster wisselt en de actor gelijk blijft?

Nee, en dat verdient uitleg in het draaiboek. Move verhuist een actor van het ene
id naar het andere; blijft het domein gelijk, dan blijft het actor-id gelijk en is
er niets te verhuizen. De fediverse ziet alleen de URI en weet niet welke machine
erachter staat. Een Move draagt bovendien geen sleutels over.

Wat overblijft is de vraag die er echt toe doet: sleutel meenemen of vervangen.
Meenemen betekent dat de oude hoster permanent een bruikbare kopie houdt --
ActivityPub kent geen intrekking. En vervangen kan Klonkt niet: getOrCreateKeys()
maakt alleen aan als er niets is. Genoteerd als shaer-s6g.

Opgezocht in plaats van uit het hoofd geschreven: FEP-521a (Representing actor's
public keys) is FINAL en staat meerdere sleutels per actor toe via
assertionMethod, maar zegt bewust niets over rotatie of het intrekken van een
oude. FEP-ef61 (Portable Objects, DRAFT) gaat naar de wortel: server-onafhankelijke
ids via DIDs, en de mogelijkheid de sleutel bij de GEBRUIKER te leggen in plaats
van bij de server. Dan lekt een hosterwissel niets, want de hoster had hem nooit.

Beide staan nu in het document, met het onderscheid tussen waar dit heen hoort te
gaan en waar het vandaag staat.

File:

• deploy/HOSTING.md (modified) (1 diff)

deploy/HOSTING.md

@@ -174 +174 @@
   minor, and a 🛟 help request is a distress signal. That a guardianship exists
   may be visible to you for support. What is in it is not yours to read.
+
+### If someone changes hoster
+
+An ActivityPub `Move` does **not** apply here. Move takes an actor from one id to
+another and tells the followers to re-follow. If the domain stays the same, the
+actor id stays the same, and there is nothing to move: the fediverse only ever
+sees the URI and cannot tell which machine answers it. Changing hoster with the
+same domain is a server migration. Copy the data across and the world notices
+nothing.
+
+Which leaves the key, and Move would not have helped with that either — a Move
+carries no keys; the new actor simply has its own.
+
+So the choice is: take the key along, or make a new one.
+
+Take it along and everything keeps working — **and the old hoster keeps a working
+copy, permanently.** ActivityPub has no revocation. Nothing marks a key as no
+longer valid; it is only superseded once other servers refetch the actor.
+
+Klonkt cannot rotate keys today. `getOrCreateKeys()` creates a pair when there is
+none and never replaces one. So for now, treat a change of hoster as what it is:
+the previous hoster can go on signing as that person, and the only real mitigation
+is choosing hosters you would trust after the fact.
+
+Say this out loud to anyone leaving you, and to anyone arriving.
+
+The fediverse is working on the root of this. FEP-521a (final) already lets an
+actor publish several keys at once, which is what a graceful rotation would need —
+though it deliberately stops at the representation and says nothing about when an
+old key stops counting. FEP-ef61, *Portable Objects* (draft), goes further: it
+gives objects server-independent ids and allows the signing key to live with the
+**user** instead of the server. On that model a change of hoster leaks nothing,
+because the hoster never held the key. That is where this should end up; it is not
+where it is today.
 
 ### The legal shape