Hello,
There is a unique problem of the fediverse. When an instance goes offline, its communities will never sync again.
Recently, vlemmy.com shutdown. Quite a few communities synced with discuss.online and other instances. Because vlemmy.com is not longer brokering communication, these communities will never be in sync again.
We have a several options:
- Leave them there. Do nothing.
- Leave them there but make a post that it’s dead and hope people see it.
- Purge the communities. Act like they never existed.
- Build some elaborate system to work around vlemmy being gone. This would take a lot of work and collaboration with other instances.
Let me know what makes the most sense to you as users. Are any of you still using vlemmy communities? What about long-term planning? Maybe this isn’t an issue now but what if lemmy.world vanished?
Please, let me know what you think. I’m torn on this one.
Thanks, Jason
I think the ideal solution would be devising some way for the content to live on cached in other servers and continue to sync comments and upvotes among them. It would be a shame for useful content to go away, and allowing for communities and instances to rise and fall and live and die seems like something decentralized content should expect to happen without leaving information holes.
This would be much easier if the original owners of the instances helped bring it down. Their servers have private keys that verify ownership of the content for the fediverse to work in a trustworthy way.
Without these keys the content has to stay in a sort of read-only state.
I like 3. acknowledge it’s dead, maybe provide a re-direct to a child community
This assumes they can find that post. They’d never know if someone searches and lands on a post and not the feed. Or if they only look at their main feed and never review the community.
My initial thought was to build an archive server that grabs all the federated instances’ content via the public APIs. Then each instance would then have the option to purge after. However, this prevents folks from discovering it. Unless they are aware of the archive. I bought the domain lemmy.rehab for this. Perhaps, we could even create an instance that hosts only a backend for these dead communities that no one owns. Then moderation would be a nightmare.
The second option was post a sticky post that said this community was dead and no longer synced. But for how long is that useful? What if someone finds a post from years ago and comments and never visits the main feed to see it’s dead?
Another option is to put in a request for the core devs to have archived communities. Read-only. However, these communities will remain in a constant out-of-sync status. Comments and posts on discuss.online will never show on lemmy.world or the other way around.
I’m not certain of any option.
My initial thought was to build an archive server that grabs all the federated instances’ content via the public APIs. Then each instance would then have the option to purge after. However, this prevents folks from discovering it.
It would ideally still be indexed by web crawlers, so the content of defunct sites could still be shared.
That’s true. That could be useful. I could do that somewhat simply too.
Is there any way to lock the community? So that it stays there for archival purposes, not all topics need to be uptodate, it could have useful information or posts. Just keep it there and lock it.
We could make them so only moderators can post to them. That’s a great idea.
I’m leaning towards the do nothing option.
The problem is that if anyone comments or likes on discuss.online it’ll forever try to sync back “home”. I’m not sure that it expires yet. Forever network noise.
Is it possible for discuss.online to have a reference list somewhere of dead/offline communities? If someone tries to like a post on them, or comments on them, could the user receive a warning that this won’t be sent through? Ideally, could there be some indicator on each post + the main page of the community that this community is on a dead instance? Always nicer to have that before someone spends an hour crafting a really good reply not knowing it won’t be going anywhere.
I’m somewhat limited by core Lemmy functionality and the time available to extend it. However, I have an open wiki page, https://wiki.discuss.online, where I could create a list. I can build tools that report these communities and post them there.
If that network noise causes problems, address it. Otherwise, I don’t see why you should spend effort on it.
It’ll be problematic at scale. Nothing but log noise right now. However, it’s difficult to parse through real issues in logs, currently.
Restriction to mods only seems like a good idea.
I think it’s an excellent short-term bandage. But we will need something for the long-term.
This topic is of extreme importance to the success of widespread adoption of the fediverse.
And I’m not seeing much discussion about it, despite having posted about it elsewhere, As an aside, I can’t atm log in to the account where I brought this up, due to instability, or maybe a ddos. No telling, but that I can’t log in shows a weakness that the general users won’t tolerate. I suspect I’ve lost another account, along with the community I created and the attendant work, when a fmhy.ml went offline.
While non-tech people will come, there’s a good chance they’ll leave when lemmy.fmhy.ml, for example, disappears, taking their community and all their contributions with it.
There are many reasons why servers and domains will evaporate. And users will emigrate from an unstable, unreliable environment.
Redundancy and backup are critical. Maybe p2p is the solution, I don’t know. The fix is above my pay grade.
But this weakness will be exploited. Pissed off instance owners, blackhats working for moneyed interests to whom the fediverse represents a multi-billion dollar threat, drive failures, lightning strikes, the ‘how’ doesn’t matter. It’s simply a matter of ‘when,’ and what will result.
This concept must become more resilient in order to be viable over the long term.
You’re welcome to bring your community here. I’ve survived a few attacks that have taken others down. I’m a software engineer and infrastructure guy. My goal is 99.9% uptime.
I’m also working on some of these issues, or at least the tools to help identify them.
I think many servers will come and go mostly due to cost. There isn’t a great way to cover costs today, and the cost get higher and higher as you grow. I’m in a unique situation than most, where I’m willing to take losses for a long time before donations catch up.
Based on my experience and observations, it appears that things will vanish, and I want to find a way to preserve them and react to it without ruining the image of the fediverse or Lemmy.
Thank you for the invitation, your efforts, and your financial commitment.
Servers will come and go, and for many reasons. Those to whom computers are black boxes will come, get lost, be easily discouraged, and go elsewhere. For the fediverse to supplant the dominant, monolithic platforms, it has to be stable and simple to use.
I’m insufficiently conversant to discuss the ‘how’ of making things secure and redundant. Maybe a p2p architecture, I don’t know. But something along those lines that would have the fediverse resistant to decay.
I had restarted the lost community before receiving your kind offer. But if I start another, it will be here.
And again, thank you for all you’re doing.
I mean the service is still up despite my instance being down. I was up and running on another instance in 5 minutes.
I think this is expectations just not matching the state of development we have now, it’s new! Federation built on project urls will give way to stable instances when exactly stuff like this happens, but make no mistake we’re in the reputation building phase right now. Being proactive about the unforseen is hard.
I fully expect some support for instance migration, there’s already a few tools to back up. In the meantime I imagine best practices should include a note to make a couple accounts on different instances. Might help people understand the architecture as a bonus.
