Update account portability spec to address many good comments from Bumblefudge #22
Conversation
…rview for clarity
…he normative section. Adds examples of optionally adding copied content to outbox with new Copy activity type.
…(or servers?) in examples.
lola.html
Outdated
| <li>1A Account-level redirect: Yes</li> | ||
| <li>1B content-level redirect to a home page: Yes if source can manage it</li> | ||
| <li>1C Content-level redirect to same content: Possibly - needs more discussion</li> | ||
| <li>1D Partial move account (split account): As long as servers are willing to support the UX for partial move, this should be possible.</li> |
There was a problem hiding this comment.
Also probably best dealt with in a later extension FEP, or non-normative notes for now that get spec'd later.
lola.html
Outdated
| <li>1B content-level redirect to a home page: Yes if source can manage it</li> | ||
| <li>1C Content-level redirect to same content: Possibly - needs more discussion</li> | ||
| <li>1D Partial move account (split account): As long as servers are willing to support the UX for partial move, this should be possible.</li> | ||
| <li>1E Block list move: Yes</li> |
There was a problem hiding this comment.
This should be covered by the general category of "Extension-defined Activities and Objects", right? (Assuming blocklists are defined enough in a FEP...)
lola.html
Outdated
|
|
||
| <p> | ||
| If the source server has has ‘likes’ information on objects, it should include that collection in each object as per <a href="https://www.w3.org/TR/activitypub/#likes">https://www.w3.org/TR/activitypub/#likes</a>. If the source server has ‘shares’ information, that is included as per <a href="https://www.w3.org/TR/activitypub/#shares">https://www.w3.org/TR/activitypub/#shares</a>. | ||
| If the source server has has ‘likes’ information on objects, it should include that collection in each object as per <a href="https://www.w3.org/TR/activitypub/#likes">https://www.w3.org/TR/activitypub/#likes</a>. If the source server has ‘shares’ information, that is included as per <a href="https://www.w3.org/TR/activitypub/#shares">https://www.w3.org/TR/activitypub/#shares</a>. The source server MAY limit the size of particularly large likes and shares collections. |
There was a problem hiding this comment.
I'm not so sure-- how does the destination server know they got a subset? can the destination server ask for the rest if they know they only got a subset? etc.
lola.html
Outdated
| @@ -581,14 +589,57 @@ <h4>Example Copied Object</h4> | |||
| "@context": ["https://www.w3.org/ns/actvitystreams", | |||
| {"@language": "en"}], | |||
| "id": "https://newsite.example.org/amy/items/02751cab-7dd7-416b-905b-...", | |||
| "previously": ["https://rhiaro.co.uk/2016/05/minimal-activitypub"] | |||
| "previously": ["https://rhiaro.co.uk/2016/05/minimal-activitypub"], | |||
There was a problem hiding this comment.
love me a backlink!
is "previously" a neologism, btw, or is the "previously" semantic defined in some FEP or extension already? maybe a tracking issue should be made for all new Activity types and properties in each merge, so that a @Context file can be written up in final t-crossing and i-dotting stage of the report
lola.html
Outdated
| @@ -515,7 +515,7 @@ <h4>Changing Object IDs</h4> | |||
| <h4>Actor ID</h4> | |||
|
|
|||
| <p> | |||
| The actor ID of an object MAY change or be kept the same. In the personal account migration use case, presumably old and new content should be harmonized, and the new actor “owns” the content so it SHOULD be the new actor. However, if an implementation is using account portability functions for a different use case, such as merging individual contributions into a group blog, it MAY keep the original actor. A destination server should attempt to provide appropriate GUI affordances to be able to tell whether to keep or rewrite the Actor property. For example, an account page with text like “Move my content from old account” would indicate a wish to update the actor ID. | |||
| The actor ID of an object MAY change or be kept the same. In the personal account migration use case, presumably old and new content should be harmonized, and the new actor “owns” the content so it SHOULD be the new actor. However, if an implementation is using account portability functions for a different use case, such as merging individual contributions into a group blog, it MAY keep the original actor. Nomadic identities may also result in keeping the same actor. A destination server should attempt to provide appropriate GUI affordances to be able to tell whether to keep or rewrite the Actor property. For example, an account page with text like “Move my content from old account” would indicate a wish to update the actor ID. | |||
There was a problem hiding this comment.
i'm hoping to ship a PR very soon (maybe today!) outlining one form of this, if the evolving draft here isn't easy enough to imagine in an e2e flow.
lola.html
Outdated
| <p>Some consequences of this philosophy:</p> | ||
|
|
||
| <ul> | ||
| <li>Account migration might not be the best tool for users to do account backups. It might be better than no tool, but trying to migrate data to another live location involves enough different choices than account backup, that it is likely that the result would be some data loss.</li> |
There was a problem hiding this comment.
I like the idea of punting #14 to the export/import standard, because it's much easier there to achieve nuanced fallbacks for destination server not 100% understanding the imported content and offering the user choices about where to stick the things it doesn't understand at all and how to handle things it understands that have an extra property or two. A PR making this punt explicit could close #14 imho, assuming the other interlocutors are on board with this "best-effort" philosophy
lola.html
Outdated
| <p> | ||
| Although a follower list may not be the same on old and new servers, it seems like it would fit most users’ intended use cases if content addressed to their followers on their old server is now readable by their followers on a new server. Otherwise, a destination may allow the user to select appropriate permissions before or after an account migration through their own UIs. | ||
| </p> | ||
| <p>It would be really great to have interoperable schemas for permissions. In the meantime, even without explicit permissions, a destination can make some pretty good choices.</p> |
There was a problem hiding this comment.
there's not a FEP for it, but the "Authorized Fetch" thing mentioned in #23 is... maybe worth discussing on a call at least (assuming there are enough people on the call that know how it works better than I do!)?
lola.html
Outdated
| @@ -626,9 +648,16 @@ <h4>Keeping historical values</h4> | |||
| </p> | |||
|
|
|||
| <p> | |||
| Most other values not specified here MAY change. A server may have a good reason to transform some values - for instance translating the ‘content’ value to a format that it supports, and/or translating the ‘type’ to a type it supports. | |||
| Most other values not specified here MAY change. The 'content' or 'type' values MAY change. | |||
There was a problem hiding this comment.
This might also justify a reference to the "best effort" philosophy, as well as an explicit punt to export/import as a better strategy if fine-grained fidelity or giving the user more info about (or even controls over) those transformations, retypings, dropped properties, etc.
| </p> | ||
|
|
||
| <pre> | ||
|
|
||
| <actor URL>?redirect_ap_obj=<source object ID> | ||
| <actor URL>?redirect_ap_obj=<percent-encoded source object ID> |
|
Amazing, if we keep working at this rate we'll be at v1 sooner than we know it! |
accepting all the suggested changes Co-authored-by: Bumblefudge <caballerojuan@pm.me>
See issue #21 - plus we had some discussion and of course once I'm editing I saw ways to make things simpler, better explained, more consistent or more formally defined.