You are here. See how this question connects to other ideas.
Select a node to open its page · Expand to read within the map
One question
Can you switch services?
Test whether records, identity and application relationships survive a move.
Imagine exporting your notes to a file. Another application reads the text but loses attachments, links between notes and sharing permissions. You have a copy of the records. You have not yet transferred the way you work.
Section 4.4 of RFC 9518 identifies switching services as a design direction. Here is a practical exercise for a notes application.
Try a small migration
Choose three notes: one with an attachment, one linking to another note, and one shared with someone else. Keep a backup of the originals, then check the replacement application:
| Item | What success means |
|---|---|
| Text and attachments | You can read them, rather than merely possess an unusable file |
| Links between notes | Links open the correct objects, or there is an explicit conversion procedure |
| Sharing permissions | Private content does not become public; missing permissions require configuration |
| Identity and addresses | You know which accounts, links or credentials remain usable and which must change |
An unsuccessful migration need not mean deliberate obstruction by the original service. Formats, permission models or destination capabilities may differ. Record the specific gap instead of merely labeling the product.
Where do data spaces and DIDs fit?
Personal data spaces concern the relationship between data and applications; Arc Space is a related product lesson. DIDs concern identifiers and their control mechanisms. These relate to migration, but adopting one does not guarantee lossless interchange between arbitrary services.
ArcBlock's 2019 article on five factors for successful dApps discusses data portability and open protocols. It documents a design direction. Whether a product delivers requires an actual check like the one above.
Sources and further reading
- Mark Nottingham · RFC 9518, Section 4.4: an Independent Submission, Informational RFC representing the author's views.
- ArcBlock · Five factors for successful dApps (2019, Chinese): historical reasoning.
- Return to the layers of decentralization and assess the migration within the wider architecture.
Check your understanding
Does an export button prove a user can leave?
No. A replacement must accept the data, and the migration must preserve the functions and relationships the user needs.