It's possible to switch my current server software to Misskey?

[tassoman]

When you setup a federated activitypub server, is not advised to use an already federated domain. Except you're able to restore profiles and signing keys.

Do you think would be possible to import old user profiles and signing keys from a Pleroma style server to a new Misskey installation?
Maybe it's simpler to install in a 3rd level domain, then let profile migrate themselves in a few weeks?

Do I have choice to configure Misskey new server to force other servers refresh signing keys?

[dosubot[bot]]

Switching from Pleroma (or similar) to Misskey is technically possible, but there are important caveats. Misskey does not provide built-in tools or scripts to import user profiles and signing keys from Pleroma; such a migration would require custom/manual intervention and is not officially supported out of the box. Reusing an old federated domain with new keys or a new database can cause federation issues, such as delays in follow requests and other activities, because remote servers cache signing keys and federation state—these issues can persist for weeks until other servers refresh their caches. There is no way to force remote servers to immediately refresh their cached keys from Misskey; the best practice is to use a new subdomain and let federation update naturally over time, which is generally simpler and safer for profile migration. Enabling the signToActivityPubGet option in Misskey's config may help with some federation issues, but it does not guarantee immediate key refresh by other servers. For most cases, installing Misskey on a new subdomain and letting users migrate their profiles is the most reliable approach.
Source 1 | Source 2

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[tassoman]

@dosu what the option signToActivityPubGet really do?

[dosubot[bot]]

The signToActivityPubGet option controls whether Misskey signs HTTP GET requests to ActivityPub endpoints with an HTTP signature. This is important for federation: some servers (like Mastodon) expect these GET requests to be signed, and if they're not, you can get federation errors like 401 Unauthorized when trying to follow or interact with users on those servers. Enabling this option (which is the default) helps ensure smooth federation and compatibility with most ActivityPub servers. Disabling it might help with rare federation issues, but can break communication with others, so it's best to keep it enabled unless you're troubleshooting a specific problem.

To change this setting, use the admin panel or the /api/admin/update-meta API endpoint, then restart your instance—editing the config file alone won't update it after setup. More details and context here: Misskey issue #16466, Misskey PR #16026, Misskey discussion #9194.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[tassoman]

@dosu Consider the problem from the perspective of a federating server, what happens when another server, for example mastodon type or misskey type, tries to federate my new Misskey server and can't find old posts (they was written in the old server), and finds profiles and signing keys are changed (they are coming from the new installation)

[dosubot[bot]]

From the perspective of a federating server (like Mastodon or another Misskey), if your new Misskey instance replaces an old server on the same domain and old posts are missing, remote servers will get 404 errors when trying to fetch those posts—users will see broken links or missing content. If the profiles and signing keys have changed, remote servers will try to verify signatures using their cached keys, which will fail until they eventually refetch and update their cache. During this period, federation actions (like follows, replies, or DMs) may fail or be delayed, and some servers may repeatedly request the new keys or profile data until their cache updates. There is no way to force remote servers to refresh their cache immediately; the process depends on their own refresh cycles and federation traffic patterns. These issues can persist for weeks until caches naturally update across the network.
Source 1 | Source 2

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}