this post was submitted on 29 Jun 2025
294 points (98.7% liked)

Fediverse

20451 readers
203 users here now

A community dedicated to fediverse news and discussion.

Fediverse is a portmanteau of "federation" and "universe".

Getting started on Fediverse;

founded 5 years ago
MODERATORS
[email protected]
[email protected]
294
lemm.ee has shut down for good (sh.itjust.works)
submitted 2 days ago* (last edited 2 days ago) by [email protected] to c/[email protected]
70 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 14 hours ago (1 children)

Exactly. That means instances would not longer have that responsibility. It would be responsibility of the hoster, meaning less pressure for the instance. Once they ban the user, the content would not be shown.

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

The interesting part is that after it’s triggered, then the process is pretty much automatic.

There have been cases where federation deletion was not processed correctly, so it would add an additional layer of potential issue

Why would it be any different for a content hosting server?

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.

[–] [email protected] 1 points 14 hours ago* (last edited 14 hours ago) (1 children)

it is more interesting to have users to build a local community than just being a storage server.

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.

it is currently recommended to mod from local accounts

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.

[–] [email protected] 1 points 14 hours ago (1 children)

The reason I’m in lemmy.ml and not some smaller instance is because of problems like the ones showcased here.

Quite a few instances are managed by non-profits which are much less prone to service disruptions, like https://fedecan.ca/en/ for lemmy.ca.

The local account would continue being the primary source of access to the content…

Isn't that contradictory with the users - content separation?

note that having a separate hosting service doesn’t mean that the hosting service must be the one managing access to the content.

That seems contradictory with the previous point. My understanding was that

  • users would use Lemmy.user accounts to browse content (this is the recommended way to avoid user management for the content instance admins)
  • mods would use Lemmy.content accounts to moderate communities (users would have to switch to those type of accounts from the first type if they want to start / mod a community)

Is this correct, or am I missing something?

[–] [email protected] 1 points 14 hours ago* (last edited 13 hours ago) (2 children)

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 @[email protected] ).

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.

[–] [email protected] 1 points 13 hours ago

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.

[–] [email protected] 2 points 13 hours ago

Ah, I see. So something like https://activitypods.org/ ?

That would be an improvement indeed, but probably not something we will see any time soon.