lemm.ee has shut down for good
from WhyJiffie@sh.itjust.works to fediverse@lemmy.ml on 29 Jun 21:29
https://sh.itjust.works/post/41231302
from WhyJiffie@sh.itjust.works to fediverse@lemmy.ml on 29 Jun 21:29
https://sh.itjust.works/post/41231302
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.
threaded - newest
speaking of that, there was a userscript that is able to find the same post on other instances. I should look it up, in case it can also work with posts of offline instances
it should, as long as the post was synchronized in the past…
lemmy.zip/c/meta@lemm.ee
seekms your username was different on lemm.ee:
lemmy.zip/u/WhyJiffie@lemm.ee
hmm that’s interesting because I did not have a lemm.ee account! :Djust 3 tons of links to it.edit: I misunderstood it, no I didn’t have an account there
also in the meantime I did some research. it turns out I was probably remembering the Lemmy Universal Link Switcher userscript: greasyfork.org/…/469273-lemmy-universal-link-swit…
it can look up posts by their activitypub id, which is the de-facto ID of a post, that is same across all instances. this ID is the url of the content on the original instance. so, the following could be an activitypub id, if the post was actually created on lemm.ee: lemm.ee/post/64477597
to look up a post by this, the userscript uses the
/api/v3/resolve_objectAPI endpoint.it searches your local instance, and if you are authenticated it also queries the host in the url, lemm.ee in this example. but of course this remote query does not work anymore.
now here comes the twist. I know I always read lemmy through sh.itjust.works, so whatever I saved should be known by this server. and the link that I save, often does not point to the origin instance, because clients work that way.
so it seems 2 lemm.ee links that I tried to look up were not actually posted there, because bmy server does not know a post that has this ap id, I just somehow got a link that points to the lemm.ee version of that post or comment…
Fortunately the messaging app I misuse for link collection always loads the title and image of the webpage, so by some manual work I should be able to find the actual links to each of them.
$ curl -sw'\n' \ https://lemmy.ml/api/v3/resolve_object?q=https%3A%2F%2Fsh.itjust.works%2Fcomment%2F19488525 \ | jq -r '.comment.comment.content' | head -n 1 ~~hmm that's interesting because I did not have a lemm.ee account! :D~~ just 3 tons of links to it. $Edit to add: Lemmy seems to URL-encode ‘
:’ and ‘/’ sometimes :/Awesome. Zip managed to cache my ee account so I can at least refer back to any place I posted or commented off of ee. Wonder how long it’ll keep it for
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 😮💨
Yeah bookmarks are a lot better than using specific save systems
Bookmarks won’t help if the content gets removed. You’ve got to copy the important information elsewhere.
I tend to use either a note app (Joplin) or a self-hosted wiki for that.
I always take a screenshot because I am lazy but just copying the text, like you say, is better
Yeah fair, most of my bookmarks aren’t really things that are important to save, just funny things I want to share later or something.
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.
Ah got it!
Goodbye ee
You were waiting for this one for a month, aren’t you? :)
I was literally filling out an application for another server when it went down. Sad day.
Unfortunately I waited too long and now I can’t see my subs that I wanted to migrate.
this you? lemmy.zip/u/Aku@lemm.ee
Yep thats me!
🫡
Are you sure? Are lemm.ee posts showing as deleted for you? It looks like the copies of anything posted to lemm.ee still exist on the instances that it was federated with. Try this link !animation@lemm.ee, I am pretty sure it should still work on your instance.
It’s not all the lemm.ee posts, just a significant amount of them.
also in the meantime I realized my hundreds of lemm.ee links are not actually links to lemm.ee hosted posts, but just links to the lemm.ee view of them. I was just very often copying the wrong link that still worked, but wasn’t the definitive one
o7
Hello world, lemmee refugee here, & first post on piefed! I had exported my settings before the ship went down, figured we could import it in another instance to save my comments and communities, but I don't see any option to import here. Does piefed speak with Lemmy yet it's not part of Lemmy?
Piefed speaks to Lemmy instances, yes.
You can import data here: https://piefed.social/user/settings/import_export
Thanks for your support! It was great having you for the time we had you.
The linkrot is real but not unexpected when anyone can spin up and shut down instances. Nothing is forever
It’s mostly not because of instance shutdown though. especially on lemmy, because lots of posts are readable elsewhere after shutdown.
It was my first home. I thank them for bringing me in.
🫡 you were good to us .ee, may you forever rest in peace.
Out of the loop, why did they shut down?
Not enough admins, and those there were burnt out.
Furthermore, I thought that they were supposed to be a temporary instance for the reddit influx as well.
I’m sure I was sufficiently notified, but I am not big on reading updates on ny instace, so this came as a surpise just now.
Thanks for the server! Onwards to the next!
The original shut down thread was posted over 3 weeks ago.
sopuli.xyz/post/28167574
RIP home server, you will be missed
It’ll be greatly missed. It was nice to have an instance with a reasonable defederation policy where I could interact with anyone basically.
Nice for you, bad for the mods. Only way to do that without outsourcing mental strain to other people is to self host
Yeah I remember I few people saying modding .ee was hell because of infinite streams of users from the same instances and their refusal to defederate
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.
Since he said that the authenticator is the one that handles the communication & access, I expect banning the person from the authenticator would already automatically prevent anyone using that authenticator (or any other authenticator federating with it) from seeing the content.
As I understand it, the only thing the content provider would do is hosting the data. But access to that data would be determined by the service doing the access control, in the same way current instances are doing it.
Hosting involves removal of content, which is triggered by actions performed by users.
At the moment, if a Lemmy.world user spams CSAM content everywhere, other admins can reach out to the LW admins, they ban the users and purge the content.
In a users/content model, with Lemmy.users and Lemmy.world still being the content, other admins have to reach out to the Lemmy.users instance, get them banned, then to the Lemmy.world admins to trigger the purge of the content on the communities.
On top of that, it is currently recommended to mod from local accounts, as report federation will be fixed in Lemmy 1.0, not released yet: github.com/LemmyNet/lemmy/issues/3781
The main part of the “admin burnout” comes from the management of users. There isn’t really that much to manage on the content part that isn’t linked to users.
Exactly. That means instances would not longer have that responsibility. That would be on the hosting service, meaning less pressure for the instance. Once they ban the user, the content would not be shown, it would be purged from the federating network of that instance, regardless of whether the hosting service actually deletes it or not (but I expect it would be better if the protocol makes it so banning a user sends a notification to the hosting service).
It’s more complex than that, at the moment, because the purge also involves mirrored content in other federating instances. The interesting part is that after it’s triggered, then the process is pretty much automatic. When purging, Lemmy.world admins don’t have to manually go around asking to all the other instances to delete the content. The purge request is currently being notified automatically to instances federating with it. Why would it be any different for a content hosting service?
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: lemmy.fediverse.observer/list
There have been cases where federation deletion was not processed correctly, so it would add an additional layer of potential issue
As I stated above, it is currently recommended to mod from local accounts, as report federation will be fixed in Lemmy 1.0, not released yet:
What that means is that on top of your Lemmy.user account, you would need a Lemmy.content account that would be able to fully moderate the community as a local account. Users don’t like to juggle between different accounts to moderate and participate.
Imho, it comes down to how much you care about the content of the community you are building. The reason I’m in lemmy.ml and not some smaller instance is because of problems like the ones showcased here.
If I could self-host my own content I would not mind being somewhere else. In fact, I’m considering setting up something through brid.gy. The fact that there isn’t a separation of the hosting means that if I want to secure my content I need to have my own 1-person instance which is not something the protocol is very well suited for. Plus it’s likely most lemmy instances would not federate with it anyway since, understandably, they may prefer an allowlist approach rather than blocklist. The only sane way would be to have the instances have full control of the access as they are now, with storage being in a separate service that can be managed separately, the hosting service.
Would this change at all if there was a hosting service?
I expect you would still be recommended to mod from local accounts (the “authenticator”), even if the content hosting was a separate service. The local account would continue being the primary source of access to the content… note that having a separate hosting service doesn’t mean that the hosting service must be the one managing access to the content from the fediverse.
Quite a few instances are managed by non-profits which are much less prone to service disruptions, like fedecan.ca/en/ for lemmy.ca.
Isn’t that contradictory with the users - content separation?
That seems contradictory with the previous point. My understanding was that
Is this correct, or am I missing something?
Then I think we had a different understanding. My understanding was something akin to what bluesky does with the PDS, the data service just hosts data and hands it over to the other service which is the one actually doing the indexing of that data and aggregating it into communities. The data of the community might be hosted in the hosting services, but it’s accessed, indexed and aggregated through the authentication service.
The access management, the accounts, the distribution of data, etc. that’s still in the server managing the federation. That’s the way I understood it, at least (I’m not the person that originally started this train, that was @TheObviousSolution@lemmy.ca ).
This allows the content to potentially not be completely lost if an instance dies because it would be easier to carry your data to another instance without losing it. It’s the same principle as in bluesky but applied to the fediverse.
Ah, I see. So something like activitypods.org ?
That would be an improvement indeed, but probably not something we will see any time soon.
There’s several solutions, I was just stating the “at least” solution because everything needed for it is already present. You just need to remove functionality depending on the type of service you want to host.
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.
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.
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
I had a second look, and instances not allowing sign up are either going to shutdown (lemmy.one) are false positives (bookwormstory.social/signup) or are single-person instances:
<img alt="" src="https://lemmy.dbzer0.com/pictrs/image/36730518-eb47-4aee-aa64-603dde0e4fb0.webp">
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.
If admins goes missing like the feddit.de ones did, the same problem would still impact that instance, be it a user or a content instance
If admins just want to shutdown without willing to transfer the instance / domain like the lemm.ee ones did, the same problem would still impact that instance, be it a user or a content instance
Using instances with non profit like fedecan.ca/en/ (lemmy.ca and piefed.ca) seems a better way to mitigate that risk.
I think you are misunderstanding the problem being solved. Expecting all instances to become non-profits and manage even more responsibility exacerbates the problem and inhibits the fediverse growth. Non-profits also have their share of pitfalls and is an entirely different beast.
lemm.ee told you the reason they were shutting down - not enough people to keep the place running and burnout. I can’t force you to see how minimizing and distributing responsibility helps those issues if you don’t want to. Less responsibility, easier for people not to ditch projects or end them.
That has nothing to do about what they decided to do afterwards. I thank them for not transferring the instance domain to a completely different party without user consent, and people would have disagreed with that so it’s best everyone found their own solution. It would even have put their account information at risk.
Lemm.ee had the option to close their registration at any time. But registrations are only one source of user management.
In a scenario where Lemm.ee would have become a content instance, but kept their federation policy, they would still have received all the reports about posts on the communities they hosted, wherever the reported user comes from.
Lemm.ee was the instance with the most active communities after LW, there’s no way to avoid a certain level of responsibility.
Like I said, I can’t force you to see it.
Being a dedicated content instance provider would also inherently imply dedicating that instance to a certain, more controlled type of content. An authentication instance might want to cater to a geography, which will probably decide to interact with the rest of the world and to provide adequate verification and certification mechanisms. A content instance might want to cater to a geography or a subject, resulting in specialized participation, with certification and verification based on the content, not the user.
You keep seeing monolithic instances that congregate the most communities as a plus. That’s a negative in my perspective on the fediverse. It shouldn’t be competing reddit clones with the one having the most communities winning out.
Those control mechanisms were available to lemm.ee. There’s a reason most active instances mostly defederate from certain instances.
I don’t, I’m the one regularly pushing for more decentralization of communities (reddthat.com/post/20197120 , e.g. !privacy@lemmy.dbzer0.com vs !privacy@lemmy.ml)
But I would rather have instances use the tools they currently have (and hopefully more will come with Piefed development catching up) rather than trying to re-engineer the whole platform when some instances don’t use the existing moderation tools.
Like I said, I can’t force you to see it. The fact that you think it would mean re-engineering the whole platform means you aren’t getting it. It’s almost literally the suggestion of least effort, it’s largely an organizational change that encourages instances not to cope with more responsibility than they can deal with by encouraging decoupling the current structure into two more specialized ones.
If you want re-engineering the whole platform, then I would suggest having all instances be authentication instances and rather than “host” communities to allow users to broadcast to community labels. Have any number of moderation groups be able to be created in an organized on that label or a personalized way by allowing users to select their own curators, perhaps even extrapolating it from the downvotes of trusted users and prioritizing the ranking of those they value. Work on providing a ground.news of discussions instead of biased takes and prunings from those in charge. Allow fast tracking of moderation across these adhoc groups for specially toxic content. That would solve the problem of nobody really going from a 10000 user community that has 100 daily posts to a 10 user community with 2-3 posts a week, because they would all operate within the same community but every user would be able to customize their perspective. The risk then is to balance the bubble they’ve created with transparency of all the other bubbles people are creating to interact with the community. Each particular instance would be able to be as biased as it wants to particular users or groups of users, but their content would truly be broadcast and federated.
youtu.be/ZOVkYAxHvkk?t=51
A solution to this is Nostr. One identity across the entire network.
Twitter-like Platform/client dies overnight? No problem, all data still there.
Reddit-like platform/client dies overnight? No problem, all data still there.
PC dies overnight? No problem, all data still there.
Data is sync’d across multiple relays, you can run your own, and clients are interoperable.
It’s my go-to now, for everything. A person’s posts, their followers/audience, chats, etc never needs to be migrated.
Media is stored using the Blossom protocol which was created for Nostr.
V4V(Value 4 Value) is also a thing, so instead of just Likes/Reactions you can tip/Zap Sats (Bitcoin over Lightning) but that’s optional.
Centralised identity is something that Nostr does right. But it's got a nazi bar problem
It’s not centralised though. It’s quite decentralised actually.
As for your “nazi bar problem”, I’d suggest you review the relays you connect to. That’s the beauty of free speech, and power of choice.
You just lost all the anticryptobros with that last sentence.
I think this is the only thing Nostr fixes. It has a lot of other issues, I feel which makes it difficult to scale. Like you can’t block anyone, just mute. It’s only the text that is distributed, media is still centralized, etc… You cant stop someone from following you. Metadata about you gets leaked to the network like who you are muting. It doesn’t work well if you use two different clients, like desktop and android.
The content isn’t gone.
It’s still retained by the various instances that lemm.ee federated with, and entering the url of a lemm.ee post on those instances should still let you find their local copies if they have it.
yeah but it turns out a lot of my lemm.ee links are not actually to content that’s originating from there, but lemm.ee-view links for which if I search, there’s no result.
Fortunately I also have the title and image permanently loaded for these links, so I can find them with some manual work