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.

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.

Hosting involves removal of content

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).

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.

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?

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.