If you want to think about a *really* hard fediverse problem that would have a *really* big payoff: don't worry so much about users moving domain-to-domain.

Amber

@[email protected] @[email protected] @[email protected] What you can do is export the keys and then modify the database of the new instance software to have the same keys... depending on support (if the software doesn't support the same key types well...)

Amber

@[email protected] I'd love to be able to move instances from the root domain to a subdomain... even that is a challenge

Jenniferplusplus

@puppygirlhornypost2 that seems a lot more manageable, actually. Still not simple, of course. I think the bulk of it would be just a redirect proxy, which isn't particularly hard. But then that proxy would also likely need to trigger update and move activities to be sent to the client's inbox after responding with the redirect, since we probably can't assume that peers will update their cache otherwise. That part is more complicated. And both need to stay in place approximately forever.

Jenniferplusplus

@puppygirlhornypost2 and then you have to figure out how to make it legible to mastodon, since they decided webfinger is actually the unique identifier for no reason.

Chrisshy Keygen

@jenniferplusplus god, I have been thinking about this so much. It would be so cool!

Jon

@[email protected] thanks, I didn’t know that was even possible!

Jenniferplusplus

Since this has been dominating my notifications for 2 whole days now, I've given it some intermittent bursts of thought.

I still have no good ideas, but I might have a workable bad idea: the new backend proxies unknown requests to the original instance, and then ingests the result itself.

The problem (one of them, anyway) is there's no particular end point to that arrangement. You just have to commit to running both backends for an unknown and unbounded period of time.

mx alex tax1a - 2020 (4)

@jenniferplusplus "so you then take an account export from the source instance and blast GET requests to the new backend" idk we're just a coyote inventing shitty forms of read-repair, we dont know anything about distributed systems

Jenniferplusplus

I mean, the proper solution is for fedi backends to be able to serialize their full catalog of objects to disk as AP documents, so that other software could import that.

But running 2 instances honestly sounds easier, in terms of coordinating between projects.

And running 2 instances answers some questions of how to handle ongoing federated messages while the adoption is in process.

Jenniferplusplus

@atax1a or that. I was thinking you wouldn't know how to enumerate that set of urls without an export. But i guess that's not true; you'll probably control the old database, you can get it with SQL.

There are definitely worse options. Just try not to hose both systems at the same time.

mx alex tax1a - 2020 (4)

@jenniferplusplus i mean either solution is going to lose fidelity because the schema is approximately a post-it note with "lol" written on it

Jenniferplusplus

@atax1a this is hilariously, and painfully, true

smallcircles (Humanity Now 🕊)

@helge @jenniferplusplus

Oops.. my bad, sorry folks. I thought we were asked to just list *really* hard things we'd like to see in fedi. Brain swallowed last sentence somehow, Jennifer.

Time for..

Steve Bate

@jenniferplusplus I've been wanting to do a loss-less move of my domain from Mastodon to another AP implementation. I can write code to dump all the data from Mastodon's database, but the biggest issue I've encountered is that most AP implementations hard-code fixed URI paths. This isn't technically required, but it seems to be easier for most developers. I'm exploring modifying another implementation to match Mastodon's URI paths.

Jenniferplusplus

@steve I'm not sure what you mean by hard coded URI paths. Like when defining their API controllers?

Steve Bate

@jenniferplusplus Yes, it would typically be a side-effect of controller or request handler design. As a simple example, one implementation might use "https://domain/users/alice" with others requiring a URI structure like "https://domain/ap/actors/alice" or "https://domain/<UUID>".

Steve Bate

@jenniferplusplus I don't want to translate all the URIs on import because the existing URIs are being used by many caches in other Fedi nodes.

Jenniferplusplus

@steve I really don't see how you avoid statically defining those routes. You have to be able to bake them into the objects you deliver to your peers. And you have to be able to look them up when other objects refer to them. And you have to be able to retrieve them when requested.

Jon

Something I’ve wondered: would it be feasible to kluge something up based on aliasing the old URIs to the right objects?

@[email protected] @[email protected]

Jenniferplusplus

@jdp23 @steve That would form the basis for what I imagined upthread, yes.