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

Hey, I won't be on, but OAuth is really near and dear to my heart. I 
worked on an OAuth profile for AP, and also have been working on some 
new scopes.

Evan

On 2024-06-20 10:54 a.m., Lisa Dusseault wrote:
> Today's Portability TF topics for ~ 5 minutes from now:
>
> * Source servers redirecting object requests
> * Externalities - servers DDOSed
> * If we have time - OAuth model
>
> Lisa
>
> On Fri, Jun 14, 2024 at 9:02 AM 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 <http://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 <http://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
>
>
>
>
>