It doesn't seem to have too much options if these are all:

• https://github.com/misskey-dev/misskey/blob/faef125b74cd5ae32c69f2d997b5fc9c179ca475/packages/backend/src/config/types.ts

It doesn't seem to have too much options if this is the entire set:

• https://github.com/misskey-dev/misskey/blob/faef125b74cd5ae32c69f2d997b5fc9c179ca475/packages/backend/src/config/types.ts

It's unsupported in Diaspora as well:

• https://github.com/diaspora/diaspora/issues/6737
• https://www.loomio.org/d/70t8W4zG/public-posts-that-expire

In reply to @bkil:matrix.org
Hello! What's cookin'? We were giving a hand in moving a #friendi.ca:matrix.org account between two hosts according to the guide just a few days ago. The full migration wasn't a success for some technical reason that still needs to be debugged, but I could now answer your most important question. Its built-in support for account move makes all of your former followers automatically follow your identity transparently.

I've also opened an issue for being less reliant on cooperation with the host. Note that this still doesn't protect against the case when the host had destroyed, stolen or its owner died. Only users making weekly backups could protect against that, but then their connections will have to be approved manually in that case after they finish an import somewhere else. Come to think of it, if the signing key would also migrate, I don't quite see why they couldn't follow the new identity - I have to ask that.

• https://github.com/friendica/friendica/issues/11102

Allow export & move account when banning a user

I've also opened an issue for being less reliant on cooperation with the host. Note that this still doesn't protect against the case when the host was destroyed, stolen or its owner died. Only users making weekly backups could protect against that (and/or a client feature to turn client-server sync cache into an incremental backup of an earlier export), but then their connections will have to be approved manually in that case after they finish an import somewhere else. Come to think of it, if the signing key would also migrate, I don't quite see why their followers couldn't follow the new identity after an import - I have to ask that.

• https://github.com/friendica/friendica/issues/11102

Allow export & move account when banning a user

In case there's anyone new here, who hasn't heard: A lot of people think Web3 (as it pertains to Social Media anyway) should in some way utilize IPFS to store data. Perhaps using an IPFS Pinning Service to ensure they continually "own" their own data at all times.

Perhaps the simplest, low-tech, and easiest way to implement this would be some kind of Daily Export Feature that existing Fedi apps would have which just does the standard exports (that they can already do) but saving to IPFS, and then emailing the CID pointing to the entire backup set by email. Because of how IPFS does deduplication, as long as each post, image, or file, etc was stored as a single file, then the amount of IPFS consumption each day would only go up by the amount of the "new" data for that day, even though each backup is a complete account history.

The more super advanced Web3/IPFS concept is of course the "Let's do Social Media directly over IPFS" idea, which is orders of magnitude more difficult. But even then based on design choices there are simpler ways and more difficult ways of course.

In case there's anyone new here, who hasn't heard: A lot of people think Web3 (as it pertains to Social Media anyway) should in some way utilize IPFS to store data. Perhaps using an IPFS Pinning Service to ensure they continually "own" their own data at all times.

Perhaps the simplest, low-tech, and easiest way to implement this would be some kind of Daily Export Feature that existing Fedi apps would have which just does the standard exports (that they can already do) but saving to IPFS, and then emailing the CID pointing to the entire backup set by email. Because of how IPFS does deduplication, as long as each post, image, or file, etc was stored as a single file, then the amount of IPFS consumption each day would only go up by the amount of the "new" data for that day, even though each backup is a complete account history.

The more super advanced Web3/IPFS concept is of course the "Let's do Social Media directly over IPFS" idea, which is orders of magnitude more difficult. But even then based on design choices there are simpler ways and more difficult ways of course.