lemm.ee has shut down at 00:14 UTC.
unfortunately I realized too late that I have had hundreds of saved links to posts and comments from there, so I did not have enough time to save them, but anyways it is interesting that maybe a third of the post links I could try were dead. I think linkrot is happening much faster here than on reddit, even if just counting deleted posts.
Deleting your account deletes your content, unlike deleting your Reddit account. Hence the linkrot.
I learnt pretty early on that saving posts using the save button was not a good way to save the information 😮💨
Not quite. If your comments federated out to an instance that either a) doesn’t get the delete request or b) ignores the delete request, your comments will very much stay out there in the fedeverse with not much you can do. Yes posts on the original instance may be gone, but anything that get pushed out via ActivityPub is a crap shoot.
Yes with ActivityPub there’s always failed federation. But Lemmy will send the delete request out when you delete your account. Other software or instances might not honour it, but the intent is there.
As opposed to reddit who do not remove comments when an account is deleted, only mark it as a comment from a deleted account.
I’m not against Lemmy’s implementation, but it does require you to collect information you need at the time not assume it will always be there.
Ah, I get where you’re going with that and understand your view. My point was more for users who think that deleting an account will really get rid of it everywhere and I didn’t want them getting their hopes up.
That’s weird. I moved over from lemm.ee and transferred data. The saved posts transferred too.
No that’s expected, as part of your profile info. But if the original authors delete the comments, then they will also be deleted in your saved items.
The linkrot is real but not unexpected when anyone can spin up and shut down instances. Nothing is forever
Goodbye ee
You were waiting for this one for a month, aren’t you? :)
Damn, since I saw the warning thread I was hurrying my slow ass to back up my stuff, which I gladly did (some days ago), lemmy.zip is my new home now.
I feel sorry for the users that didn’t get the chance to backup their stuff… An auto backup feature for Lemmy backend might be worth checking out perhaps?
At the very least, social networks like this really need a two server type system: the authenticator who identifies that you are really who you say you are and handles personal settings, communication, and access to the fediverse, and the content provider that hosts the communities.
How do you ban users in this scenario?
What do you mean? The authenticator instance could ban users, the moderators and the content provider instances could ban users, content provider instances could defederate from authenticator instances and viceversa.
Not sure I’m seeing the issue you are seeing, it’s just basically forcing lemmy instances to instead of being both to just be one or the other. The benefit is that the actions on one is free from the drama on the other. One would be dedicated to hosting users, the other would be dedicated to hosting communities, less burnout overall.
Complete bans (at the home instance level) would require synchronization between the content provider instance and the authenticator instance.
Mod actions are caused by users comments on content, so the two aspects are closely intertwined, you can’t dissociate the content from the users.
At the moment, admins synchronize in a group to deal with toxic users, usually leading to the ban of those users on their home instance. Having a split between two types of admins adds an additional layer that could actually increase the admins workload.
Complete bans (at the home instance level) would require synchronization between the content provider instance and the authenticator instance.
What are you referring to as a ban? Complete bans already require synchronization between different federated instances. Sometimes the home instance of a user is unable to entirely delete the content of a user because of it.
Mod actions are caused by users comments on content, so the two aspects are closely intertwined, you can’t dissociate the content from the users.
Not really. Mod actions are over a community, not user history. They are perfectly able to remove user comments within their community, and since they are the authoritative source that controls whom it is spread to that has greater influence. That never stops the same content by the same user from appearing elsewhere.
At the moment, admins synchronize in a group to deal with toxic users, usually leading to the ban of those users on their home instance.
They would still do the same, but the “usually leading to the ban of those users” perhaps does more to reveal what your actual problem is than anything else. You and me will have to disagree, because admins should not be authoritarian figures, but should only have control within their domain.
-
If they want to administrate over a group of users, they can have control over which users are and aren’t allowed over that particular group. They can issue their own warnings to users.
-
If they want to administrate over communities, they can have control over which communities are allowed and how users are allowed to interact with those. They can remove users from those communities entirely.
The small but loud minority of toxic users can just have their authentication instances defederated if those instances refuse to do anything with them. If it is an authentication instance doing the defederation, then it will affect all of their users. If it is a content provider instance, it will affect all of their communities. In the current system, it does both because both are coupled into the same instance, so it’s even compatible with it.
It stops bad faith actors from trying to pollute communities to slur entire instances, like lemm.ee or blahaj, because of their problems with their userbase, by simply stopping it from being an issue. Administrators don’t have to worry about policing communities or users if they don’t want to, they would be able to better choose whom they are catering to without bad faith backlash elsewhere.
Almost nothing of the current structure changes, except that dedicated instances have the functionality they don’t need disabled. Both can still block each other to their heart’s content, and if your problem is having more “splits” - that is literally what federated instances are, there can always be more … Maybe your problem is with the fediverse and its distributed nature? You are making it out to be as if there is only ever a big bad group of toxic users and that all administrators always completely agree on all bans to make your argument work. At that point, just create your own reddit clone.
I addressed a few of your points in the parallel thread with @Ferk@lemmy.ml (actually, it seems like you read it as you commented below)
As I stated in one of the comments
At that point, the content instances would be merely storage. This model is already possible now, but the vast majority of instances host both users and content, because it is more interesting to have users to build a local community than just being a storage server.
If some admins were interested in only being storage servers, you would see more instances not allowing user registrations, but all the 35th most active instances allow them: https://lemmy.fediverse.observer/list
I had a second look, and instances not allowing sign up are either going to shutdown (lemmy.one) are false positives (https://bookwormstory.social/signup) or are single-person instances:
Your vision is possible now, but it seems like almost no one wants to implement it.
Why would people want to implement something they don’t know the benefits of? That’s what my comment and increasing awareness is all about, in a thread about an outcome that could have been prevented by the idea.
-
RIP home server, you will be missed