5 ms·

Say I migrate my ActivityPub server from ProductX to ProductY, but I want to keep all the usernames and external follow relationships intact. We need external

by nicky0 4y ago

Say I migrate my ActivityPub server from ProductX to ProductY, but I want to keep all the usernames and external follow relationships intact. We need external people who follow @me@myserver.example.com seamlessly still follow at the new server, which has a different code an URL structure. Will it "just work"?

RobotToaster 4y ago
If you mean changing domain names, I think in theory you can setup redirects with Webfinger.
- vidarh 4y ago
  You're right, you can, and it works. E.g. my Mastodon id is @vidar@galaxybound.com, but my Mastodon server is hosted on m.galaxybound.com. The webfinger on galaxybound.com is just a redirect. In addition to redirecting the webfinger query, the webfinger results themselves can point to an inbox etc. elsewhere.
mariusor 4y ago
Why does the new server need to have a new url structure? Why do the URLs need a "structure" anyway? That's what TFA and OP are actually saying. Mastodon - partly due to the fact that it predates federating through ActivityPub - doesn't have the concept of URL as a unique identifier for an object (in the ActivityPub sense), but uses numeric ids, or uuids in some places. If you really want "a structure", I wonder why nobody is implementing ActivityPub services[1] using the simplest and dumb way of mapping objects in storage using their ids. Ie: an actor has the ID https://example.com/user1 https://example.com/user1, therefore it's inbox/outbox should be https://example.com/user1/inbox|outbox https://example.com/user1/inbox|outbox. Then, an activity created by that user can be found at https://example.com/user1/outbox/{unique-activity-id} https://example.com/user1/outbox/{unique-activity-id}. If the activity is a Create (the only ones with a side effect of creating an object), then this object can have the id https://example.com/user1/outbox/{unique-activity-id}/object https://example.com/user1/outbox/{unique-activity-id}/object, samd. [1] My own fediverse software does this for multiple types of storage: filesystem hierarchy, k/v store, database tables, but I haven't seen anything else similar.
- danpalmer 4y ago
  > using the simplest and dumb way of mapping objects in storage using their ids > https://example.com/user1/outbox/{unique-activity-id} https://example.com/user1/outbox/{unique-activity-id} This isn't actually the simplest way, and is what makes it hard to move between software. Mastodon might use /userid/outbox/activityid, GoToSocial might use /users/<id>/posts/<id>, and so on. The "simplest" way to do this is to treat the URLs as the ids themselves, which is what the Activity Pub spec defines. This should be the most interoperable.
  - rakoo 4y ago
    But it doesn't matter what each software does because the necessary endpoints are defined in your actor object linked from your webfinger entry. That's the only endpoints the user agent is supposed to see and use. Now if you're saying the ActivityPub spec is tragically underdeveloped, sometimes on purpose it seems, and doesn't define actually useful stuff but leaves it "to the particularities of implementations" then I fully agree with you
    - danpalmer 4y ago
      Maybe true with endpoints in the actor object, but clients should be able to refresh any object from its URI at any time, I believe this is a spec requirement rather than just advised, although I could be wrong. As for Activity Pub lacking clarity, I do completely agree, it's going to be years before we have a good understanding of what the spec actually necessitates in production implementations.
      - rakoo 4y ago
        This would be "interoperable" in that it's easy to go from one framework/software to the other, but it's still not transparent. The current way of doing things is to use the url of the object in the search bar, and thus use the search bar as the "new" url bar. In practice it is more interoperable because all softwares then behave the same.
vidarh 4y ago
That will just work for any new software which follows the move mechanism built into Mastodon. Not all do still, but it's fairly new. When I moved from mastodon.social to my own instance, about ~80%-90% of my followers automatically migrated. Most of the ones left were on older version of Mastodon, and some non-Mastodon servers like Misskey. What does not migrate currently is your old posts. If you control the target server, you do get a dump of your old posts and you can import them with some effort, but it's not automated. E.g. in my case, if you go to [1] you can see my old posts and a notice from mastodon.social that I have moved. The 40 followers remaining on that account are the few followers who either have not moved or have manually followed on my new account but not bothered to unfollow on my old. Moving the posts have a few issues. One concern the Mastodon devs have that I don't agree with is that it might make it easier to "fake" your history. But you can trivially do that if you set up your instance anyway, and the exported posts are signed so they could check the signature on import, for what little benefit that'd give. The other is that anyone who have linked to the old posts would link to the old site. Fixing that (e.g. with redirects) would potentially require a mapping. It's doable, but would require a new mechanism (e.g. an activity posted from the new server telling the old server of the new URLs after import - the mechanism for the old server to know the new server is where you're moving is already in place). [1] https://mastodon.social/@vidarh https://mastodon.social/@vidarh
- danpalmer 4y ago
  Not quite. You can move Mastodon server, but you can't move _software_ on the same server.
  - vidarh 4y ago
    Yes, you can. You will need to have both running at the same time if you want to use the built in migration mechanism in Mastodon (assuming the new software supports it), and so will need to ensure the URL space does not collide, e.g. by giving one of them a different hostname and adding an alias to the webfinger response. If you are going to migrate software on the same server you'd likely be in a better place if you just generate static pages from the Mastodon export for the actual posts after doing the follower migration. If you're outright replacing the Mastodon server you might get away with just importing the followers as well, as long as the software you're interacting with is well behaved and do webfinger lookups. You can improve on that by ensuring the inbox url stays the same, worst case with a redirect.
supermatt 4y ago
> I want to keep all the usernames and external follow relationships intact ActivityPub doesnt have the concept of a "username" in the sense that you are thinking. An activitypub "preferredUsername" field is just a preferred display name for that actor. Instead they have actor ids - which are just URIs. Behind the scenes, mastodon (and similar) simply treat @me@myserver.example.com as a webfinger ref. They do a lookup via webfinger which returns the actor id, and then they connect to that URI to return the respective object(s). Of course, because your mastodon instance is also likely hosting your actor AND its respective collections AND its activities, then ALL the URIs are ALSO tied to their domain. In order to "migrate" they (probably - im not 100% sure) send updates for your actor object (and your other activity types) to your outbox and distribute to your followers, who will then update their own references to your actor, its aliases (such as the webfinger ref), and other associated collections and activities. Its 100% possible to have a webfinger alias on your own domain and use separate hosts for your actor, specific collections, and each individual activity, should you wish. Mastodon can reach other activitypub actors and activities configured in this way, but it cant provide a similar service for its own users, due to its current implementation (it expects to be the originator of activities for its associated actors).

by nicky0 4y ago

RobotToaster 4y ago

If you mean changing domain names, I think in theory you can setup redirects with Webfinger.

vidarh 4y ago
You're right, you can, and it works. E.g. my Mastodon id is @vidar@galaxybound.com, but my Mastodon server is hosted on m.galaxybound.com. The webfinger on galaxybound.com is just a redirect. In addition to redirecting the webfinger query, the webfinger results themselves can point to an inbox etc. elsewhere.

mariusor 4y ago

Why does the new server need to have a new url structure? Why do the URLs need a "structure" anyway? That's what TFA and OP are actually saying. Mastodon - partly due to the fact that it predates federating through ActivityPub - doesn't have the concept of URL as a unique identifier for an object (in the ActivityPub sense), but uses numeric ids, or uuids in some places. If you really want "a structure", I wonder why nobody is implementing ActivityPub services[1] using the simplest and dumb way of mapping objects in storage using their ids. Ie: an actor has the ID https://example.com/user1 https://example.com/user1, therefore it's inbox/outbox should be https://example.com/user1/inbox|outbox https://example.com/user1/inbox|outbox. Then, an activity created by that user can be found at https://example.com/user1/outbox/{unique-activity-id} https://example.com/user1/outbox/{unique-activity-id}. If the activity is a Create (the only ones with a side effect of creating an object), then this object can have the id https://example.com/user1/outbox/{unique-activity-id}/object https://example.com/user1/outbox/{unique-activity-id}/object, samd. [1] My own fediverse software does this for multiple types of storage: filesystem hierarchy, k/v store, database tables, but I haven't seen anything else similar.

danpalmer 4y ago
> using the simplest and dumb way of mapping objects in storage using their ids > https://example.com/user1/outbox/{unique-activity-id} https://example.com/user1/outbox/{unique-activity-id} This isn't actually the simplest way, and is what makes it hard to move between software. Mastodon might use /userid/outbox/activityid, GoToSocial might use /users/<id>/posts/<id>, and so on. The "simplest" way to do this is to treat the URLs as the ids themselves, which is what the Activity Pub spec defines. This should be the most interoperable.
- rakoo 4y ago
  But it doesn't matter what each software does because the necessary endpoints are defined in your actor object linked from your webfinger entry. That's the only endpoints the user agent is supposed to see and use. Now if you're saying the ActivityPub spec is tragically underdeveloped, sometimes on purpose it seems, and doesn't define actually useful stuff but leaves it "to the particularities of implementations" then I fully agree with you
  - danpalmer 4y ago
    Maybe true with endpoints in the actor object, but clients should be able to refresh any object from its URI at any time, I believe this is a spec requirement rather than just advised, although I could be wrong. As for Activity Pub lacking clarity, I do completely agree, it's going to be years before we have a good understanding of what the spec actually necessitates in production implementations.
    - rakoo 4y ago
      This would be "interoperable" in that it's easy to go from one framework/software to the other, but it's still not transparent. The current way of doing things is to use the url of the object in the search bar, and thus use the search bar as the "new" url bar. In practice it is more interoperable because all softwares then behave the same.

vidarh 4y ago

That will just work for any new software which follows the move mechanism built into Mastodon. Not all do still, but it's fairly new. When I moved from mastodon.social to my own instance, about ~80%-90% of my followers automatically migrated. Most of the ones left were on older version of Mastodon, and some non-Mastodon servers like Misskey. What does not migrate currently is your old posts. If you control the target server, you do get a dump of your old posts and you can import them with some effort, but it's not automated. E.g. in my case, if you go to [1] you can see my old posts and a notice from mastodon.social that I have moved. The 40 followers remaining on that account are the few followers who either have not moved or have manually followed on my new account but not bothered to unfollow on my old. Moving the posts have a few issues. One concern the Mastodon devs have that I don't agree with is that it might make it easier to "fake" your history. But you can trivially do that if you set up your instance anyway, and the exported posts are signed so they could check the signature on import, for what little benefit that'd give. The other is that anyone who have linked to the old posts would link to the old site. Fixing that (e.g. with redirects) would potentially require a mapping. It's doable, but would require a new mechanism (e.g. an activity posted from the new server telling the old server of the new URLs after import - the mechanism for the old server to know the new server is where you're moving is already in place). [1] https://mastodon.social/@vidarh https://mastodon.social/@vidarh

danpalmer 4y ago
Not quite. You can move Mastodon server, but you can't move _software_ on the same server.
- vidarh 4y ago
  Yes, you can. You will need to have both running at the same time if you want to use the built in migration mechanism in Mastodon (assuming the new software supports it), and so will need to ensure the URL space does not collide, e.g. by giving one of them a different hostname and adding an alias to the webfinger response. If you are going to migrate software on the same server you'd likely be in a better place if you just generate static pages from the Mastodon export for the actual posts after doing the follower migration. If you're outright replacing the Mastodon server you might get away with just importing the followers as well, as long as the software you're interacting with is well behaved and do webfinger lookups. You can improve on that by ensuring the inbox url stays the same, worst case with a redirect.

supermatt 4y ago

> I want to keep all the usernames and external follow relationships intact ActivityPub doesnt have the concept of a "username" in the sense that you are thinking. An activitypub "preferredUsername" field is just a preferred display name for that actor. Instead they have actor ids - which are just URIs. Behind the scenes, mastodon (and similar) simply treat @me@myserver.example.com as a webfinger ref. They do a lookup via webfinger which returns the actor id, and then they connect to that URI to return the respective object(s). Of course, because your mastodon instance is also likely hosting your actor AND its respective collections AND its activities, then ALL the URIs are ALSO tied to their domain. In order to "migrate" they (probably - im not 100% sure) send updates for your actor object (and your other activity types) to your outbox and distribute to your followers, who will then update their own references to your actor, its aliases (such as the webfinger ref), and other associated collections and activities. Its 100% possible to have a webfinger alias on your own domain and use separate hosts for your actor, specific collections, and each individual activity, should you wish. Mastodon can reach other activitypub actors and activities configured in this way, but it cant provide a similar service for its own users, due to its current implementation (it expects to be the originator of activities for its associated actors).