Een embed-pijplijn: AP eerst volgens de FEP, dan provider, dan oEmbed
Robins besluit: shaer-ibs (oEmbed) en shaer-277 (fediverse-embeds) worden een
ding. Een lezer ziet straks dezelfde kaart, of het nu een geciteerde
fediverse-post is of een ingesloten video. Het verschil zit niet in wat je ziet
maar in wat er FEDEREERT, en dus in de volgorde van resolutie:
- ActivityPub-object -> het FEP-pad. Een quote van een fediverse-object draagt
echte semantiek (FEP-044f quote + FEP-e232 Link-tag, de geciteerde auteur
wordt geadresseerd, permissions gelden). Nooit via oEmbed, want daar zit
niets van dat alles in.
- Bekende provider -> de bestaande speler (YouTube/Spotify/Bandcamp/...).
- oEmbed-discovery -> de generieke weg, en de voorkeur voor alles buiten de
fediverse.
- Anders -> een kale link blijft een kale link.
De io is geinjecteerd, zodat de volgorde te testen is zonder netwerk. liveIO
bindt 'm aan de echte fetchers: alles via safeFetch (weigert private ranges,
begrenst redirects) en met een body-cap, zodat een vijandige URL in een post de
server niet aan het rondsnuffelen krijgt op interne hosts.
New file:
src/services/EmbedResolver.js
- resolveEmbed met de vier stappen, alle vier naar dezelfde kaartvorm
- findOEmbedEndpoint, looksLikeAPObject, fromOEmbed, fromAPObject
- liveIO: SSRF-veilige binding met body-cap
test/embed-resolver.test.js
- 10 tests: volgorde (AP wint van provider en oEmbed, provider wint van
oEmbed), oEmbed-discovery, degradatie naar link, en dat liveIO grote
bodies weigert en niet gooit op een geweigerde fetch
remarks: 200 tests groen. Dit is de kern; nog aan te sluiten (fase 2, zie de
bead): de compose-kant (URL in een post -> kaart), het emitten van de quote
richting de fediverse met notificatie aan de auteur, en de render die de
bestaande quote-kaart hergebruikt voor alle vier de soorten.
-robo
Co-Authored-By: Claude Opus 4.8 <noreply@…>