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 god though fuckin seriously

Jenniferplusplus

@atax1a "the fediverse is more than just mastodon" not to your mastodon admin. Give them options, then we'll see what's what.

Jon

Yeah totally agreed. But my understanding is that even without moving the data, there are problems just running a different back end on the same domain - maybe something about keys not getting updated?

@[email protected] @[email protected]

Helge

Enforcing a standardized ActivityPub OpenAPI schema for all services would get you like 30% towards the goal.

The rest is converting between databases. As one already has an interchange format: ActivityPub. This should be solvable ... I'm not saying it's easy. Also the first step is missing.

smallcircles (Humanity Now 🕊)

@helge @jenniferplusplus

App-free computing support. Choreograph distributed services into tailored social experiences to address specific use cases for stakeholders as designed, instead of shoving them into rigid app that constitute siloed fixed menu (feature) mass dining halls. And people have to use a mismatched patchwork of them to juggle food (data) between. Add a social browser, an IDE with good social solution DX.

And we can cook.
Half serious..
Or just dreaming.

smallcircles (Humanity Now 🕊)

@helge @jenniferplusplus

Another hard challenge, big payoff.

Spritely's fantasary-level ambitious, but not to create a fedi virtual world game experience, but model the social experience of the "Software Development" game title instead. Full social web support for all our design and dev tools across the entire "social stack".

Then you also have the tools to go peopleverse next-level. More, see:

From Fediverse to Fantasary and Peopleverse

Background to this post is my follow-up thread (plus spice-up) to @cwebber great mega-ultra Bluesky fedi discussion thread (that costs you a day of handling replies, Christine :sweat_smile: ). The description of the Sp…

Spritely Networked Communities Institute (community.spritely.institute)

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.