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

[bumblefudge]

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]

(just tracking this across future solutions)

[bumblefudge]

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

(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).