search

swicg / activitypub-data-portability

Repository for data portability report and solutions for ActivityPub
https://swicg.github.io/activitypub-data-portability/
Other
11 stars 2 forks source link

Side-effects of off-domain `id` URLs of MOVED/SYNCED activities #13

Open bumblefudge opened 4 months ago

bumblefudge commented 4 months ago

I am having doubts about rewriting the id property of content that gets moved. Perhaps it makes more sense for a "wrapper" activity at the new server to contain a link to the old activity? Or, if rewritten/updated, the original/previous id should be kept in some new property to allow the history to be walked? And/or doing things the object history collection approach is relevant here?

generally, I think it's GOOD for important activities to be marked in end-user UX as "historical" or "imported" or "staged" (to use the Discourse term) activities... lazy solution is for the UX to be triggered any activity with "foreign" (off domain) id s?

bumblefudge commented 4 months ago

(just tracking this across future solutions)

bumblefudge commented 4 months ago

Update: noticed this intriguing proposal in one of the FEPs today:

image (Src: FEP-fffd)

I think it's worth having a hard, long think on how a migrated activity signals its "migration history", whether in a simple "back link" as sketched here or in an object history collection. I'm sure there's side-effects I'm not realizing to both approaches, on top of the usual scale/efficiency concerns-- it's also worth noting that the rest of the FEP-fffd concerns cross-protocol migration and later deduplication, which might be a useful framing for how it works even within AP protocol/graphs (i.e. dedup of side-effects like routing updates as an object is edited after migration).