Vrienden krijgen de geschiedenis mee, en een block blijft een dichte deur
Robins besluit (30-7): wie later vriend wordt, moet de oudere friends-only
posts alsnog kunnen zien. Dat kon niet: friends-only was een moment-opname
(bezorgd aan de volgers van dat moment) en de outbox verborg fan-only juist,
dus de backfill die bij een nieuw volgen draait had niets op te halen.
Drie stukken, samen de lus:
- De outbox antwoordt naar PUBLIEK: outboxAudience beslist per lezer. De
eigenaar (bearer) en een geverifieerde geaccepteerde volger of guardian
krijgen de friends-only geschiedenis mee; anoniem en een vreemde met
alleen een handtekening krijgen de publieke set, precies als voorheen.
Bijvangst: de auteur ziet nu ook zijn EIGEN friends-only posts in de app.
- De backfill identificeert zich: signedGetJson tekent de GET als de
volgende site ((request-target) host date, wat verifyRequest checkt), dus
de servende kant herkent de vriend. Een server die de handtekening
negeert gedraagt zich exact als vroeger.
- Het moment dat de vriendschap ontstaat is het moment dat de geschiedenis
meekomt: op de Accept van onze Follow draait de backfill.
En Robins scherpe toevoeging: een geverifieerde caller die deze instance
BLOKKEERT krijgt een LEGE collectie, niet eens de publieke set. Een block is
een dichte deur, en een gesigneerde fetch is aankloppen met je naam erop. De
block wint ook van een verweesd volger-rijtje.
Changed files:
src/services/ActivityPubService.js
- signedGetJson; backfill gesigneerd; backfill op Accept(Follow);
outboxAudience als pure, testbare beslissing
src/routes/activitypub.js
- de outbox-route beslist via outboxAudience; blocked = lege set
New file:
test/friends-history.test.js
- anoniem blijft publiek; identificatie is geen vriendschap; volger en
eigenaar lezen de geschiedenis; block wint van alles, ook van een
stale volger-rij
remarks: 341 tests groen, server start.
-robo
Co-Authored-By: Claude Opus 5 <noreply@…>