Forwarding

[sandhawke]

Forwarding is the idea that a service where you once had an account will be helpful by redirecting people who come looking at your old address. This includes posts, media attachments, subscriptions, mentions, replies, reactions, etc. With proper forwarding, you can move your online identity from one instance to another without losing followers, inconveniencing followers, damaging discussion threads, or breaking web links to your content.

In addition to giving users freedom and market mobility (avoiding vendor lock-in), forwarding gives instance admins a way to terminate service without harming their users. For example, a site could give users 3 months to transfer their content to other sites of their choosing, and then switch over to long-term forwarding. The hope is that forwarding can be done at a very low cost, basically with HTTP redirects, perhaps by a small server running nginx with a (large) static config file. We might call this "afterlife" mode for a "dead" instance. Once a domain is in forward-only mode, it could be transfered to a trustworthy party, supported by donations from anyone who wants forwarding to continue.

Some protocols may provide ways for links to be updated so that the need for forwarding declines over time, but there will probably always be URLs in email, printed on paper, or otherwise stored in immutable media, so that conceptually forwarding should continue in perpetuity.

Technical aspects:

The question/issue here is whether systems can practically provide forwarding. Has this been implemented? Is it in common use? Are there things stopping it?

Non-Technical aspects:

Can we set a cultural expectation that by default admins are expected to do this when they shut down their service, unless they were clear up-front they would not? What about when they suspend an account for violating ToS?

What happens if someone forwards from s1 to s2, then puts some unacceptable content at s2 and gives out the s1 address for it? Will the s1 admin get in trouble? (It might be the s1 address in the tweet, but folks will see the s2 address in the URL bar.) Will the s1 admin (who doesn't want to be in this business any more) have to honor takedown notices, removing the forwarding for that content?

Some fediverse discussion of this issue in replies to : https://mastodon.social/@sandhawke/6614295

[sandhawke]

Explaining a little more how I'm naively imagining this might work, in the hope people can tell me if this works:

Some of the links associated with me on mastodon.social:

https://mastodon.social/@sandhawke https://mastodon.social/@sandhawke/6619913 https://mastodon.social/users/sandhawke https://mastodon.social/users/sandhawke/updates/2413955 https://mastodon.social/users/sandhawke.atom https://mastodon.social/users/sandhawke/updates/2413955.atom https://mastodon.social/api/salmon/8936 https://mastodon.social/.well-known/webfinger?resource=acct%3Asandhawke%40mastodon.social`

Let's imagine we're having nginx handle the redirecting, and we're using permanent redirects, because that's what the user asked for. And let's say I've moved to sandro@hawke.org. So we just add:

rewrite ^/(users/|@)sandhawke.*$ https://hawke.org/users/sandro/_redirect_from/$uri permanent

The tricky thing here is that the username and item numbering are different on the new host, and we want the old host to be as simple as possible, so we need to keep track of that mapping on the new host. So the _redirect_from handler would look up where that resource has ended up and redirect again to land you in the right place.

I put the _redirect_from handler after the new user name so in theory I could move off hawke.org to yet another instance, and hawke.org could also do simple static forwarding. In that case, the _redirect_from handler at the new-new site would have to understand both mappings.

For webfinger, I think we shouldn't redirect, we just return the same content as before, including a bunch of URLs that will end up redirecting. Or maybe there's a better way, not sure. To implement this with just nginx, one could use a config like https://github.com/agrueneberg/nginx-webfinger . If it's just a few users moving, you can let webfinger be handled as usual.

For salmon, I'm not sure. I'll have to learn more about that one.

Will this all work?

I guess I can try this by setting up some instances (of mastodon or whatever) and messing with their nginx configs. Maybe hardcode what _redirect_from is doing at first. Slightly longer term, transfering the content can be done by an app, and it would create the mapping that _redirect_from will have to use.

But maybe somebody knows offhand why this wont work...?

[AstraLuma]

I think part of this is federated identity, where multiple Agent URLs refer to the same person.

This becomes a thing if ActivityPub is used as a publishing protocol for an incidental producer.

For example: PlayStation has social sharing features. If Sony added AP/AS2 support, you would likely want a way to link this specialized provider with your general purpose social network.

There's also use cases for segmented identities: public vs personal, SFW vs NSFW, topical identies, etc.

[sandhawke]

@astronouth7303 I'm hoping to keep this issue quite narrow and straightforward, as one technique for solving a couple very important problems (a user wants to switch providers, and a provider wants to shut down). I agree there are a bunch overlapping and related issues that could be addressed in other ways.

[nightpool]

I think that we stand a good chance of solving A, but B is much harder. Providers who want to shut down often don't want to even run small static HTTP servers for a long time. In good situations, you might get a few months notice. Sometimes it's not even that—there's a legal issue, and they just shut down everything within the week. See the Ozimals shutdown that happened a few days ago for an example.

So I think the thing that needs to be hashed out is 1) when do we consider a redirect as "permanent" (i.e., we change the URL we use to fetch content) and 2) how do we prevent this being used to hijack accounts in an irreversible and destructive fashion?

[nightpool]

Maybe a good path forward is that we could require implementors to support multiple URLs for a given "logical" actor? And then if we receive a redirect for any URL, we add, but don't remove, URLs, and display a message to the user. Then going forward we check both. If one goes down, then that's great—we have the new one. If one stops redirecting, we could either use both or ask the user or something.

A good argument for putting this in as a AS2 verb or something similar is that it gives you first class undo. I'm not sure what a explicit "disavow" message would look like if this was just on the HTTP side.

[sandhawke]

On hijacking, how about a rule that if you get the same redirect, and never get a plain 200 OK, over a span of 30 days, then you make it permanent?

On protocol changes to handle sudden shutdown, that's a different issue, in scope for #1

On sites not wanting to run a forwarder after they go away: Sure, of course. We all have some internal desire to be irresponsible and just walk away when things go bad. But if there were an easy way to do the responsible and ethical thing, then (1) it would be more reasonable to pressure folks to do it, and (2) more folks would end up doing it, and (3) after a while the folks who don't do it would look even worse. There could also be a legal obligation to do it, which sites might agree to in order to attract users.

[sandhawke]

I've been trying to enumerate and test the possible issues here. Here are two. Does this seem like a useful direction to proceed?

looking at profile after move

1. Henry makes a profile on t0.example, with name "Henry"
2. Henry moves to t1.example
3. Claire looks up henry@t0.example

Assert: Claire sees the correct profile, with the name "Henry"

This might fail, for example, if the client didn't follow the redirect, or if it wasn't built to allow the id resulting from a lookup to be different from the one that starts the lookup.

notification of new item after move, subscription to old site

1. Henry has a a feed of his posts on t0.example, with two posts, "test1" and "test2"
2. Claire subscribes using his feed URL t0.example/users/henry/feed
3. Henry moves to t1.example
4. Henry adds a third post, "test3" on t1.example

Assert: Claire is notified with the content of test3

With WebSub, if the subscription database is transfered as part of the move, I think this would work automatically. If the secret is not transfered, then Claire won't be notified until after her lease runs out. Henry could perhaps be given some control over lease.seconds, or at least told what it is. In either case, there might still be issues with Claire software checking or making assumptions about the URLs it will see as part of this subscription.

[AstraLuma]

Does it count if the client shows intermediate lookups? Eg, notifies that Henry has moved from t0.example to t1.example?

[sandhawke]

I'm not sure, but my sense is that would be okay. It might even be a good idea, yeah.

[ghost]

We seem to be approaching this from different directions, but that's ok.

In earlier federation forums a 30x redirect on webfinger was the generally accepted consensus for indicating a moved resource. How you implement this turns out to have interesting consequences. I took it to mean that webfinger could redirect any resource it knew about, but which wasn't local.

In this case, henry moves from t0 to t1. A work colleague tries to webfinger henry@t0 because that's on his business card. t0 is dead (unreachable). In our current implementation, I believe it's possible (this was five years ago and haven't really thought about it since) to finger henry@t0 at the nearest directory server (or any node that knows harry), and it will do the right thing and redirect to the current webfinger at t1. At least this way t0 doesn't need to continue providing any services and there's a way for the webfinger to end up in the right place. Some projects have rejected the concept of directory services, so finding a "node that knows harry" might be contentious or problematic for them.

In our current implementations, the two issues 'looking at profile after move' and 'notification of new item after move, subscription to old site' are both handled through nomadic identity. I believe they are also handled just fine in Friendica using the account relocation mechanism - which is essentially the same mechanism proposed by Diaspora (work in progress). So these aren't really a concern in my view. All your followers/connections are notified of the move (or added location) and told to update their URLs appropriately; and if the mechanism is working correctly that's exactly what happens. Finger @deadserver seems to be the only bit that could be contentious.

Granted, you're going to have a problem with browser or offline bookmarks, but there's not much we can do server side to fix that. You could redirect on the short term, but with no way to tell the browser to update its bookmarks you're still going to end up with a dead bookmark 'n' months/years from now when the redirector is shut down.

[sandhawke]

There's a thread about this in mastodon at https://discourse.joinmastodon.org/t/migratory-accounts/268/9

[nightpool]

@sandhawke potential issue with the redirect-only case that came up in masto dev chat today:

Having just forwarding allows for authorization problems, where malicious user Alice dumps her old followers and old posts on unsuspecting user Bob.

I think the easiest way to solve this is to have a set of "valid urls" somewhere that the fetched profile identifies and authorizes. This would also be useful for a bunch of other applications, such as multi-domain systems, allowing for access to the same profile using different schemes (.onion?), etc.

[sandhawke]

Yep, I realized this last night in the context of forwarding blocked users, and posted about it to the discourse thread on it, with basically the same solution: your profile on t1 must list t0. Alternatively, the http client following the redirects could make sure the _redirect_from step above is done, but that doesn't seem like a great architecture.