Presentation of the feature: https://piefed.social/post/667045
Example of successful migration: https://lemmy.dbzer0.com/post/45876492
Our next step would be to give this feature a try. What would basically happen is that
- we would lock our community to prevent integrity issue during the migration
- https://piefed.social/c/fedigrow@lemm.ee would become https://piefed.social/c/fedigrow , with all the existing posts and comments
- you all would subscribe to the new !fedigrow@piefed.social , and then continue as usual
Should the migration not work, we would still be able to use the current community, and then manually migrate elsewhere.
The one caveat is that from Lemmy instances, the community doesn’t have show old posts (see https://lemm.ee/c/barcelona@piefed.social), but if you were restarting a community from scratch you wouldn’t have access to your old posts anyway.
Other federated instances like feddit.online would also see the posts and comments on the new community: https://feddit.online/c/barcelona@piefed.social
The objective of this post is to address any questions or issues before we move forward. We are probably going to leave it open for 48 hours, and then reassess based on the community feedback.
The annoying thing about it is that their implementation is completely “top-down”. They just defined what is their idea of “Flair” (text/color settings) and have this stored in their database. It is completely disconnected from any of ActivityStreams or LinkedData concepts. If they had gone with a “protocol-first” approach, they could’ve proposed to use
as:Tagor even Schema.orgPropertyValueentries, attach them to the object (actor/questio/post/note) and it would be absolutely easy to federate.@rimu@piefed.social, could that be a potential rework in the future?