Portability TF next week - Thursday 8am PST?

Hi folks,

Bumblefudge has given me some great feedback on LOLA, including pointing
out that there are unresolved issues around how redirecting moved objects
should work, and how many use cases different approaches would solve.
Between the two of us we don't have all the answers so I'd like to make
this a major topic in a group call (and may collect another topic or two
between now and then as I work on this).

If enough people cannot make Thursday June 20 8am PST work and would like
it to be Friday June 28, clamor for it and we can move it,

Dmitri can you add it to the schedule please?

*The topic*:  How should source servers redirect objects, if at all?

*The use case* in
https://codeberg.org/fediverse/fep/src/branch/main/fep/73cd/fep-73cd.md#migration-user-stories
:
Alice wants to move her account from Alpha to Gamma, both of which are
online and federated to one another... Alice would like Alpha to
dynamically redirect any links to Alice@Alpha content to the migrated
contents @Gamma (i.e. 301 HTTP codes and nginx-style URL rewrites).



*Approach currently suggested in LOLA
<https://swicg.github.io/activitypub-data-portability/lola.html> section
7.2.3: *Source servers should remember or be able to detect the object IDs
of objects associated with a moved account, when a GET request arrives to
try to fetch that object, and reply with a 301 to the destination server,
with a URL parameter that allows the destination server to look up the
object.

E.g.
 * a GET request arrives for
https://lemongrove.example.co.uk/2016/05/minimal-activitypub
 * the server at example.co.uk can tell by the 'lemongrove' subdomain that
this was an object associated with the account "lemongrove" which was moved
to "https://newsite.example.org/aurora"
* The server responds with 301 status code and the URL
https://newsite.example.org/aurora?redirect_ap_obj=
https://lemongrove.example.co.uk/2016/05/minimal-activitypub
* The server at newsite.example.org can lookup the URL in the
redirect_ap_obj and reply with a 301 to the objects true new URL "
https://newsite.example.org/aurora/posts/0118570514"

*Other approaches are definitely possible*.  One example that would put
less onus on the source server to remember anything or keep redirects,
would be to advise 3rd parties looking for AP objects that respond with
"404 Not Found" to try looking at the actor associated with that AP object
and see if that actor moved, then construct the same parameter-enhanced URL
as above and send to the place the actor moved to.  However, this means
that simple Web links will NOT work because it requires the actor sending
the GET to have specialized AP knowledge.

I would love to get feedback on the tradeoffs and options.  This seems
eminently like the kind of problem for which a dozen solutions can probably
be thought of and some are definitely better than others.

Lisa