Re: Portability TF next week - Thursday 8am PST?

Thanks, Lisa!
I added the Thurs call to the swicg calendar!
https://www.w3.org/events/meetings/d83b5200-20aa-49c3-a1d0-851392df2f53/


On Fri, Jun 14, 2024 at 12:03 PM Lisa Dusseault <lisa@dtinit.org> wrote:

> 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
>
>
>
>
>
>