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.
-
@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. -
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] -
@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
Updateactions for all the posts that change the URI to the new URI. there are also multiple routes there usingalsoKnownAsthat could be more gradual, etc. the main barrier, as usual is the elephant in the room -
@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?
-
@jonny @jdp23 @jenniferplusplus Some of these techniques might theoretically work, but they don't satisfy the transparency objective (no changes required in other nodes). I want to do this transition relatively soon, not a decade from now.
-
@steve @jdp23 @jenniferplusplus that's the second reply to this one - if you have full control over the backend, the backend just maps the old uri structure to the new one ezpz
-
A Mastodon => GtS converter (even if it’s somewhat lossy) would be huge right now….
@[email protected] @[email protected] @[email protected] -
@jonny @jdp23 @jenniferplusplus I will have control over the backend and redirects could be a somewhat transparent option. I suspect there may be problems with "same origin" authorization checks on internal document URIs if the document URI is redirected but the document is not rewritten. TBD. Modifying the backend implementation to natively use a different path structure is another option.
-
@Scott M. Stolz But here is an interesting question. Since webfinger tells everyone what the AP URLs are, wouldn't any server that checks webfinger find the new URLs?
