As Emilia pointed out in the May 3 SWICG call:

We cannot require servers to make content available for export especially for certain reasons for blocking or suspending an account. If an account was suspended because the admins don't like the content, it may make sense to still allow access for the account to be ported elsewhere as it helps the account holder move somewhere where there content is more welcome. However, if an account was suspended or deleted because of any illegal content, this should clearly not be made available for porting. The requirements language around this issue should be clear that there are some necessary exceptions to making data available.

This may sound off-topic at first blush but I think it's important to have this somewhat underdiscussed corner-case clearly defined so that expected behavior for content/sideeffects from "moved actors" can be meaningfully distinguished!

There was an interesting SH thread about it this week:
https://socialhub.activitypub.rocks/t/handling-410-gone-when-retrieving-an-actor/4307

Parking these thoughts here so that #22 can make vague references to it that get fleshed out in later PRs.

I think it's reasonable to try meeting end-user expectations around privacy, but it's slightly tricky because the concept of private objects versus public objects wasn't really specified in the original protocol, and very public-oriented implementations have kind of taken center stage, leaving privacy a kind of "unimplemented extension" in many ways. There are kind of two suggestions here:

1.) No one privacy extension should be hard-coded or tightly coupled into the LOLA spec.

2.) At the same time, there's nothing wrong with picking one illustrative example and thoroughly explore it as a representative one. There's one loose standard (invented by Mastodon and implemented by Pixelfed and other major servers... but I'm not sure there was a FEP written? ) called "authorized fetch", which specifies how cross-server authN can be done to check a hosting server's authZ policies for a given content, which is maybe the closest we have to a harmonized private-object extension. My recommendation would be to think through what happens if source server supports this extension/vocab/property but destination server doesn't, and vice versa.

I want to set this as a stake in the ground for any of the solutions this working group comes up with.

For example, if we decide to enhance ActivityPub objects with content addresses, that would be an additional address, not a replacement for the HTTPS URI.

One problem on the modern fediverse is that some servers are not maintained or well moderated. By the time users decide to move to another server, their old server might be defederated by the destination server or by most of their followers.

We should have a way to migrate from a defederated server, or express it as a non-goal.

• Figure out how to properly register it
• @bumblefudge suggests: 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
• Add the actor URL because it will be needed to verify the legitimacy of objct IDs in 'previously' against the source

If we end up making some recommendations for new features in data portability, I think it would be a good idea to include a reference implementation as one of the deliverables of the group.

It currently reads in Section 2:

The primary user need to solve with LOLA is to allow Fediverse users to move their accounts in response to moderation and defederation decisions.

IMHO these are important, but by no means the only ones. Here are some others:

• the source server has announced they will "go out of business"
• the source server may start charging their users (more) money
• the user may want to set up their own server at a domain of their own
• the user may be dissatisfied with performance, uptime, or other hosting characteristics.

I'm bringing this up because if a user with any of the non-mentioned reasons reads this document, they may stop reading at the first sentence of section 2 with the impress that "this is not for me".

The Mastodon Move process does not automatically move the user's following list. This is done manually, with a backup and restore.

It should be possible to re-follow all the same accounts automatically, without a backup/restore cycle, or mark this as a non-goal.

• make it clear that the most urgent use case is to support use cases that allow defederation to work well
• explicitly talk about the use case that the content is available after an account move and that this may affect choices like defining a new Activity type such as "Import"

Even if we prefer to copy from a list of content objects other than the outbox, it would be good to explain how a destination server ought to copy from the outbox of a server that doesn't support LOLA, because there are surely good ways and less good ways to do this. The section would likely be non-normative.

A source server with an ActivityPub outbox that doesn't technically support LOLA could still offer affordances to assist in a move going smoothly, especially the UX options for setting up redirects and notifying followers.

This was suggested by @evanp in the SWICG call May 3, 2024.

On today's TF kickoff call, Aaron G brought up an interesting point-- migrating between a server that supports lots of extensions/FEP-specific Activities (with, say, custom properties defined in a supplemental @Context file), to a more "bare bones" server that does just the standard minimum, what happens with those Activities? Do they create a Collection called "IdunnoWhatTheseAre"? Are they silently dropped, or displayed with a warning that contents may be more rich than they appear? It might be worth adding a section (at least a non-normative warning under "Interoperability Considerations"?) that states assumptions.

I'm not sure I like this phrase. "Copy" sounds like an exact duplicate, and chances are it won't be:

• the source and destination servers may run different software with different schemas
• the source and destination servers may run the same software but at different versions (and thus perhaps different schemas)
• the source and destination servers have different DNS names and user handles, and some of the content will need to be adjusted
• the destination server already may have some content, and what is imported needs to be reconciled with what's there already.

Maybe "fetching content" instead of "copying content" would be better? Certainly other possibilities ...

The current specification outlines how to use a domain name for portability by backing up a server and restoring at another server. This isn't well implemented except for the almost trivial case of using the same fediverse software and a custom backup format like a database dump or tarball.

It would be interesting to delve into this further. Registering a domain (yourname.example) or using a subdomain (social.yourname.example) are great ways to have an identity that you own (more or less) that you can transfer to other AP implementations and services. Because AP uses HTTP for data retrieval and data delivery, it's relatively transparent to other instances on the fediverse if you move.

Any discussion of data portability on the fediverse needs to cover this topic.

Summarizing for reference - NOT a complete list of feedback but the ones I think I can tackle in the next rev

• Shift to more formal language. For example, explain how user can communicate an intent to setup a redirect URL rather than give examples of how that might happen with a Web UX.
• Add that the source server issuing an OAuth token MUST associate it with a user account and only that account.
• Add more detail on how to do/handle rate limiting. what specific HTTP response code, and what the party being told to rate limit should do next.
• Explain better that the phases are NOT normative, they're to understand an important flow that is enabled by the tools specified, -- and that no state need be communicated between servers around phases.
• Explain 3.2.4 "Content may be filtered at the source" better. This can be done by a source server anyway, it doesn't depend on other FEPs, it does depend on user communicating intent.
• Section 3.4 "feels like a thread... replace with more prescriptive" ? I can fix this - it is intended to be an introduction to concepts that are more prescriptively defined later - but I should explain that and label it as non-normative
• Fix the reference to "account name" in 6.1 - not a well-defined AP term
• Explain the first reference to a "migration outbox" better -the reader shouldn't have to read ahead to 6.7.1 to understand the refrence in 6.1. Explain that the destination server SHOULD copy data from the migration outbox if available rather than the regular outbox.
• Instead of group membership section, explain a general policy and template for new activity types or purposed collections
• “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.” - confused
• the example of translating type is complicated… i feel like this only works if the “original” version of any doctored object is stored (somewhere?), because what if you migrate again, do you send the original or your translated version to the 3rd server?
• 6.8 doesn't explain how the destination server is supposed to know what view permissions are. Also considerations for things that have a 'to' list but are NOT public?
• 7.2.3 the 'redirect_ap_obj' parameter - require escaping - explain how it's not an information leaking problem - explain the benefit of this approach that it allows AP-unaware browsers to be redirected

If the template is useful to keep around, maybe rename index.html to template.html so that the current working draft will be rendered in HTML to the preview URL at each merge to main? @dmitrizagidulin @lisad

The value of movedTo is not very tightly defined. It says:

The user marks the old actor as having moved with the <code>movedTo</code> property.

This doesn't say if it can be a list or a single value, a boolean or a URL.

If it's a URL, which I assume, this should also specify if it's a URL to an Actor object or something else.

The Mastodon Move process does not transfer content like text, polls, images, videos, audio, etc. from the old server to the new server.

If the old server goes down, that data is lost.

It would be good to have a mechanism for transferring the old content to the new server, either as a "move" (no longer exists at the old server) or a "copy" (exists at both old and new server). Or, this can be marked as a non-goal.

I'm moving this issue from the w3c/activitypub#421 because I believe it is a data portability issue.

The primary use case is when when organizations set up a "test.example.com" Mastodon server, sign up a few dozen users, and use it for a month or two. When they decide to make it "production.example.com" or whatever real domain they want to use, they find out that all their previous content and connections are lost. Not good!

A similar use case is when the community domain name is retracted by the registrar. For example, the queer.af fediverse server run by ActivityPub co-author @erincandescent was disabled by the Taliban government which runs the Afghan top-level domain .af. This was resolved by the community through other means, but still represents an important test case.

A final use case is when the community willingly changes the name for some more benign reason -- a change of focus, etc.

We wrote this up as a testable migration proposal over on the FEPs repo - should we consider aligning the section "Approaches for moving followers and following" with it, or mentioning it as one possible way of doing things there? It feels like a big discussion, so probably best scheduled in advance and give people an email heads up to read it if they have opinions...

Using the Mastodon Move feature for data portability is not helpful if your origin server has gone offline.

We should have a way for someone to recover an account from a server that has gone down, or mark it as a non-goal.

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?