No point in moving your identity if your content server shuts down unexpectedly. I'm actually working on nomadic content over ActivityPub right this moment. Centralising it destroys everything I've done with nomadic identity over the last dozen years. We have clonable identities (identity and content) right now with live synchronisation. If your server cert expires or goes offline right this second, go to your clone and nothing has changed. You have all your content, friends, and settings. Everything. I'm not giving this up and neither should you. Content-addressable mechanisms don't work because the url changes if you edit the object. Every project has completely different URL paths and object-type mappings.
I'm currently convinced the only way to solve this is with a mapping table, so that /item/something on my system can be found at /object/something on your system (or whatever). We also have 30-40 different object types that most other projects haven't even considered. This is the only way to make them portable. Just store the object in the mapping table instead of the local path mapping for that object. Done. The portable url could just be $apgateway/$did/$resource-id. If my software supports that kind of object I'll redirect to where we store that kind of object. If it doesn't, I'll just return the portable object.
@smallsees@erlend@dmitri (also the spec indirectly explains how to build a microservice that could run for $1/mo on a little heroku-style platform you could point myname.com at-- we can hopefully provide a prototype soon and, if people demand it, add more explicit detail about how to build one's own or adapt the idea to other form factors?)