Move.
+
This is a draft of a future SocialCG report.
+ The basic unit of data for the ActivityPub protocol is an
+ ActivityPub Object,
+ a structured (JSON) document with a set of required and optional
+ properties. The core set of properties are defined in the
+ ActivityStreams 2
+ data model specification, and ActivityPub adds a couple of additional
+ requirements (namely, that all objects must have a type
+ property, as well as a globally unique id that serves as
+ that object's location).
+
+ In terms of data migration and portability, objects by themselves
+ are very simple: because an object's id serves as its
+ location (as specified in
+ ActivityPub Section 3.1),
+ the process of moving an object is as simple as transporting it (by any
+ appropriate protocol), and updating its id property to
+ its new location.
+
+ However, in the context of ActivityPub use cases, objects are rarely
+ encountered by themselves, in isolation. Because ActivityPub
+ is a protocol intended for building distributed social systems, it has
+ two important design aspects: one, authorship and provenance are
+ important, and two, objects are not intended to be created or mutated
+ directly, but are instead wrapped in lifecycle Activities (such as
+ Create, Update, Delete, and
+ others). In distributed system design, this is known as the Event
+ Sourcing pattern, where the state of each object is not stored directly,
+ but is instead constructed from a series of actions taken on the object.
+ The fact that these are social systems brings additional challenges:
+ the series of Actions are always attributed to (performed by) a
+ particular Actor. Also, these Actions typically have an intended
+ audience, which means that for any state change the object undergoes,
+ there may exist any number of stakeholders who must be informed about
+ those changes.
+
+ Taken together, the design aspects of the ActivityPub protocol present
+ non-trivial challenges, when it comes to data migration and portability.
+ Objects are rarely encountered by themselves, in isolation. Instead, they
+ exist as an append-only series of Actions, each performed by an
+ Actor, within a social context (each action typically has intended
+ audiences, as well as other observers and stakeholders).
+ And because of that, moving an object means not only updating its
+ id to a new location, but it also means preserving its
+ chain of actions, authorship, full social context, and often also
+ notifying all interested (authorized) observers of the move.
+
+ The ActivityPub 1.0 Specification + was intentionally silent on the subject of actor identity, + authentication and authorization, leaving those up to server + implementers. Multiple implementations arose that modeled actors + as traditional user accounts, which controlled various types of data, + such as contents (posts, notes, comments, images, etc), reactions + (likes, reposts), related data such as bookmarks, social graphs (lists + of followers and following users), actor metadata, moderation decisions + (block lists, mutes), and more. +
++ Current implementations are oriented around three main aspects of + actor identity: +
+id which (as with other ActivityPub objects)
+ must be a fetch-able URL. The id is typically used as
+ the canonical identifier for the actor
+ + - data migration basically always means migration of a given actor + first, followed by all of the data and metadata that the actor controls. + - complex mapping between Actor and users -- some Actors are controlled + by multiple users, and some users can have many Actors. + - discuss the 3 aspects of an Actor's identity: actor id (url), + actor webfinger identity, cryptographic material. +
++ - for various historical reasons, ActivityPub implementations have + centered around the concept of Instances. + - this is not inherent in the ActivityPub protocol, but is an arbitrary + set of design choices, a historical artifact + - instances bundle together several key functions (which could be + separated, in theory): + 1. Identity + 2. Storage + 3. Inbox/Outbox delivery, event subscriptions + 4. Moderation + 5. Community discovery + - the fact that these functions are bundled together makes portability + and migration even more challenging. +
++ Data Portability, Migration, and Export / Backup, are separate but + closely related concepts. +
+ ++ The ability to export all of the data for a given + actor is helpful as an additional mechanism of data recovery, + since it makes user-controlled backups possible (as opposed to server + administrator controlled backups of backend databases, etc). And + although the ability to export data, by itself, does not guarantee + data portability (since many current implementations provide only + export but not import functionality), having a well-defined and + documented export format at least makes future import functionality + possible. +
++ In the context of this report, Data Migration is defined as the + process of moving or copying +
++
+