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.

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.

Scott M. Stolz

@Steve Bate

What paths do you need to match specifically?

I know that Hubzilla tries to match some of them. For example, https://example.com/channel/steve can also be reached by https://example.com/@steve

I am not sure about other things. The posts themselves probably won't have the same URLs though. But Hubzilla is extendable, and an addon could probably be created to rectify that. There are hooks all over the core code that allow you to override the default behavior. It is also theme-able.

Steve Bate

@jdp23 @jenniferplusplus I'd like to make the domain move to be transparent to the rest of the AP network. Would the aliasing require the other nodes to be modified to handle the aliases? Redirects might help a little, but the AP document contents will still have the old URIs, which may or may not be an issue if they are also redirected. More experimentation is needed.

Steve Bate

@scott I'm currently using Mastodon, so all the Mastodon AP URI paths and probably a few HTML URL paths (not sure about that, but maybe for the profile?).

Scott M. Stolz

@Steve Bate The profile already would match. Hubzilla has ActivityPub support, so it uses all of the standard ActivityPub URLs. It's required for the specs.

The issue is with direct links to all of the HTML content. That probably could be done, but it would require some programming effort.

Jon

Agreed that it needs to be transparent to the rest of the network … I remember talking about this a while ago, maybe with @[email protected] , and it seemed like maybe it could possibly work but as you say experimentation is needed

@[email protected] @[email protected]

jonny (good kind)

@jdp23 @steve @jenniferplusplus i am of the opinion that it shouldn't be that complicated, that the only part that's complicated is the currently unspec'd mutual approval action between the source and target servers, the new instance creates (if needed) versions of the migrating statuses, and then the source instance basically issues Update actions for all the posts that change the URI to the new URI. there are also multiple routes there using alsoKnownAs that could be more gradual, etc. the main barrier, as usual is the elephant in the room

Steve Bate

@scott Hmm, there are no *standard* ActivityPub URI/URL path structures. They vary between implementations. Are you saying Hubzilla would handle imported documents with *any* arbitrary AP URI path?