When the admin of a instance wants to stop the server (for example costs are running too high) but your communities are active and you don’t want them to die along with it, is it possible to migrate the communities to another instance?
This is currently not implemented, but at least moving over subscribers to a community on another server is in principle no different to account migration on Mastodon and will be probably implemented sooner or later. Moving content over is another matter and IMHO unlikely to happen anytime soon.
This will indeed be required at some point. Not breaking links within the federation would be non-trivial.
In my own experiments with ActivityPub’s lesser-known client-to-server protocol, I found that it was possible to author messages that predate whenever a message is posted. Theoretically, this could open the door for importing statuses between Actors.
At the very least, a migrated group would just need to perform an “Announce” activity on the old group’s messages to mirror them, up to a point. I’m not saying that it would be ideal if thousands of messages needed to be moved over, but maybe there are smart ways to optimize that that doesn’t require thousands of cross-server requests.
The technical barriers seem indeed solvable, but it is also a legal/moral question of who actually owns the content and if contributing users gave consent to move content to a new instance.
… it is also a legal/moral question of who actually owns the content and if contributing users gave consent to move content to a new instance.
I’d argue there’s a pretty strong case for implicit consent around archiving/migrating projects within the Fediverse given how it already works. If you make a post anywhere in the Fediverse, you’re basically consenting for that post to be distributed by any other computer that’s a member of the fediverse. That’s what federation does. I get that there’s a nuanced difference between a communities home server and one that federated the community and people get persnickety about moderation policies and what servers they peer with… but it’s a pretty nuanced difference.
I can’t think of how US copyright law would distinguish between what a federated server does vs the home server. Both would be considered to be “distributing” the material, and federated servers would have no right to do so in the absence of some kind of implied consent. Probably instances should have a ToS that makes this clear, but I don’t think any Lemmy instance has a legal team that thinks about this stuff.
But overall, I’d think that the nature of how federation works would give archive and migration projects much firmer ground to stand on than outside the federated world.
While I agree that this is the technical reality, I highly doubt most people understand this and discussions on the wider Fediverse also show that a lot of contributors/users do not agree with this when told. At most there is an general acceptance of use for technical reasons only as caching on other instances is necessary for load-balancing.
How would you for example feel if a community you contributed over many years to was exported to Facebook’s new ActivityPub enabled service and served alongside ads (or worse)?
How would you for example feel if a community you contributed over many years to was exported to Facebook’s new ActivityPub enabled service and served alongside ads (or worse)?
I don’t have a major problem with this. I take an interest in copyright and technology, and in broad strokes knew what the fediverse was before I joined. If I felt like I needed to agree with or endorse the culture/policies/admin-personal-views of every instance that federates my posts I wouldn’t be here.
I also feel like there isn’t really a policy framework that “works” for this kind of narrow view of what’s allowed in the Fediverse.
- If the Fediverse that people love is allowed, the Fediverse they hate is allowed provided it abides by the same legal and technical constraints. The only recourse people have is to defederate, and in the limit of defederating with everyone you disagree with, you’re left alone on a fedi-island talking to yourself. While there’s likely a place for niche fedi-solarsystems, it seems evident to me that the Big Tent Fediverse that becomes/remains socially relevant must at least tolerate commerce and archival work. The pervasiveness and impact of these things is too large to exclude.
- There’s also a long history of archival culture that is at odds with this view of “my content, my rules”. Libraries don’t ask publishers/authors for permission to lend books, and couldn’t exist if they did. Archive.org has help saved the history of countless communities from loss due to corporate hosts shutting down. If the admin of a major Lemmy instance threw a tantrum and shut down, destroying many major communities, I have to think that the Lemmyverse would frame the ensuing archival effort as the fight against the bad actions of a powerful admin destroying our collective history. Individual concerns about whether all posters/commenters agree with the minutae of how the preservation effort is conducted would be sidelined, and rightfully so in my opinion. Preservation is a technical fact of how the fediverse functions, and should be a policy fact of how we choose to operate it.
I realize that not everyone in the Fediverse agrees with this kind of thinking, but I think this kind of approach consistently handles a variety of stresses and bad actors much more successfully than most alternatives.
There is a big difference to posting to your home instance (with rules you agreed to and admins you trust) + having some content temporarily cached on other instances to lower the server load Vs. migrating a community including all its content to a totally different service with different rules, owners and monetization strategies.
There is also a big difference between having the service that you agreed to host your content archiving it and 3rd parties scraping content for archiving or other purposes. The latter can’t be prevented on the public web, but it really isn’t the same at all.
Edit: Archiving content (as important as it can sometimes be), should really be opt-in. The problem you describe is mainly because so much content these days is hosted by bad-actors that only try to monetize and exploit their users and only under that framework does scraping those bad actors without permission for archiving purposes sound like the morally right thing to do. What we are trying here is to get away from these bad actors and actually respect human beings in their choices, what ever those might be.
I understand why you say those things have big differences, but when one tries to articulate those differences in a legal and policy framework that allows the things one wants but not the things one doesn’t want, I think the lines separating the differences becomes grayer and grayer until they are in danger of disappearing altogether. I personally am in support of tooling to migrate communities, policies that allow it under appropriate circumstances, and a culture that embraces it “when necessary”. The details of appropriateness and necessity are complicated, but for me there’s a bright line well short of “ask everyone before preserving anything” where preservation/migration projects are allowable.
But I don’t have a lot more to say about this in the absence of a concrete real world context. If the fediverse continues to thrive, I’m sure we’ll see those contexts arise at some point and can discuss how people are viewing the situation and whether they’re able to encode those views into rules and enforce them. It will be interesting to see develop.
Edit: Your edit came in as my post was landing. I couldn’t disagree more that archiving should be opt-in. The most important preservation is the preservation of content that someone wants to destroy. And bad actors cannot be avoided, rather it’s bad actions that must be limited… through the consistent application of good policy equally to people whose intent you trust and people whose intent you distrust.
not really, you can just start advertising the new community
