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.
-
Chrisshy Keygenreplied to Jenniferplusplus last edited by
@jenniferplusplus god, I have been thinking about this so much. It would be so cool!
-
@[email protected] thanks, I didn’t know that was even possible!
-
Jenniferplusplusreplied to Jenniferplusplus last edited by [email protected]
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)replied to Jenniferplusplus last edited by
@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
-
Jenniferplusplusreplied to Jenniferplusplus last edited by
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.
-
Jenniferplusplusreplied to mx alex tax1a - 2020 (4) last edited by [email protected]
@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)replied to Jenniferplusplus last edited by
@jenniferplusplus i mean either solution is going to lose fidelity because the schema is approximately a post-it note with "lol" written on it
-
Jenniferplusplusreplied to mx alex tax1a - 2020 (4) last edited by
@atax1a this is hilariously, and painfully, true
-
smallcircles (Humanity Now 🕊)replied to smallcircles (Humanity Now 🕊) last edited by
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..
-
@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.
-
@steve I'm not sure what you mean by hard coded URI paths. Like when defining their API controllers?
-
Steve Batereplied to Jenniferplusplus last edited by [email protected]
@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>".
-
@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.
-
@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.
-
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] -
-
@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/stevecan also be reached byhttps://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. -
@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.
-
@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?).
-
@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.
