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

Oh I have climate commitments this coming weekend, and am doing server
stuff this week, but will see what happens.

I think the only issues I can throw in are externalities :- one is a server
everyone is trying to get off being ‘DDoS’ed” by users and possbeing
DDoS’ed by malice as well. And the server might be being overburdened as
well possyhr reason people are leaving.
And as a separate case a destination server everyone’s trying to move to.

A.

Aaron Gray - @AaronNGray@fosstodon.org

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and Computer Scientist.



On Tue, 18 Jun 2024 at 17:08, Dmitri Zagidulin <dzagidulin@gmail.com> wrote:

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