Locating the Oracle Service

[benpate]

The current spec already discusses this under the section Hosting Redirects for Objects. I'd like to dial in the format for getting this done. In that section, the target server SHOULD publish an "Oracle URL" that maps old URLs to new URLs, and forwards requests directly to the new location. This is also similar to the Moves collection proposed in FEP-1580 but it allows others to query individual records instead of simply publishing a collection.

But we source servers currently can't use feature because there's no consistent way to know if it's been implemented or to locate it on the target server.

Option # 1: Explicit Definition 👍🏻

If we adopt some flavor of #56, then it would make sense to send the Oracle URL to the source server when we POST to the beginMigration endpoint. This would be a new value sent along with the target profile URL, making endpoint now look like this:

Location	Name	Description
Header Value	Authorization	Bearer
Form Value	actor	the JSON-LD profile address of the new actor on the target server
Form Value	oracle	the URL of the mapping service used to redirect object requests

Option # 2: Convention Over Configuration

Alternatively, we might define this URL within the /.well-known/ folder. However, I'd prefer to be explicit about its existence and location. If this is simply an implicit convention, then this process might break if a target server has not implemented the Oracle URL. If it's defined and sent to the source server explicitly, then source servers will know that it exists (or not) and be able to redirect requests accordingly.

[lisad]

I do like dialing in what the target server SHOULD do to be able to lookup old URLs, after all it's supposed to store them anyway. Of course a user may have deleted or archived some content along with the move, so it may not be the right thing to respond for every old URL, but best-effort is all any server can do.

I don't see why the source server should do anything. The source server is trying to get out of the business of being responsible for a user who has decided to move. The target server can advertise an oracle URL in .well-known, or on the Actor - when some 3rd party is trying to follow a link to resolve it, it would follow the steps

• Ask for the resource and find out that it is gone
• Ask for the Actor on the same server and find out that it moved
• Ask for the Actor on the new, moved service and find that it has an oracle URL
• Ask for the resource at the oracle URL
• Rewrite its pointers if it is storing any

[benpate]

This is a great solution, and I wish I could depend on other Fediverse servers to implement it. And yes, it would be great to detail this process so that we can all start building it this way.

In the situations where a third-party server is looking for moved content, but they don't follow the protocol above, then it would just tell the end user that the content couldn't be found, yes?

This seems like the eternal dilemma of "compatibility vs. cleanliness" that frequently face on the Fediverse -- in the sense that architecting it "the right way" may not be compatible with all of the existing software out there.

It makes sense to me that with this part of the spec, there's a little wiggle room for different solutions:, so long as implementors understand the trade-offs involved.

What I'm planning for my implementation is to zero out all the data in a user's posts, but to keep the header -- which includes the original URL and the URL for the new user's oracle -- for maybe 6-12 months. That way, if someone doesn't follow the protocol above, then they would be redirected to the new location in two hops -- first to the oracle on the new server, and second to the new object's location. In the future, and once some threshold of applications support "the right way" then I'd probably back this off.