A few days ago, Beehaw posted an announcement in their Chat community about the challenges of content moderation and the possibility of leaving Lemmy. That post was eventually locked.
Then, about two days ago, Beehaw posted an announcement in their support community that they aren’t confident about the long-term use of Lemmy, due to so-called concerns about Lemmy.
If you currently use Beehaw and want to stay on the federated Lemmy network, consider migrating your account to another instance like lemm.ee.
That’s interesting. Does Mobilizon actually not do any mirroring between instances? How does it work when a Mobilizon user accesses a group/community that isn’t in their home instance and posts some content there?
About the Wordpress plugin: my impression is that it only works as a broadcasting activitypub feed, but the blog authors registered in that Wordpress instance do not have any way to use that account to subscribe to any other ActivityPub feed, correct? if so, that piece of the puzzle would still be missing, and it’s there where we typically find mirroring.
As far as I understand it (and I could be wrong), there is no way in the ActivityPub protocol for a user from another instance to actually publish content (eg. a reply or a comment) directly into a different instance (that is, without hosting it in their own instance first), so at the moment the way it works in services like mastodon/lemmy is that the user posts content on their own instance referencing the content from the second instance that they are replying to, and then the second instance mirrors it and displays it as a reply of the original post.
This, as far as I understand it, is the origin for the need of mirroring, and not really any thirst for “censorship resistance” or “faster rendering time”. I feel the problem is still originating from limits in ActivityPub. Or am I wrong? Is there a way to do this in the current protocol without mirroring?
I don’t think the need for faster latency justifies the mirroring. You could still get a fast time by sending the requests directly to the original host, without proxying/mirroring them at all from the service offering the frontend. Just allow for cross-domain requests to call directly the API from the client, without needing server-to-server requests for that. Of course if the host is slow then the request will be slow, but if it’s fast the request will be fast. The responsibility for performance when providing content should fall on the content host. The instance where the user has an account could provide some token for identification as proof of the user belonging to it, and have third party content providers validate that proof and decide on their end whether the user is allowed to access/post content there directly (being subjected to the moderation of the content provider, who is the one hosting the content).
The more troublesome part of this approach would be having to rely on client-side aggregation of the content coming from different providers in order to build a feed. But I think this could still be viable. Or it could be handled by another different type of instance that acts as indexer but doesn’t really mirror the content, just references it. This also would only be necessary if the user really wants an aggregated feed, which might not always be the case, sometimes you just want to directly browse the feed of a particular community or your subscriptions from a particular instance.
I mean, I get that for some use cases mirroring would be a good thing, but that could be entirely a separate layer without requiring it as part of the communication. Making it mandatory places a huge responsibility in the instance host without it being necessarily something that every user needs or even wants. I don’t want to be dependant on what other instances my particular instance decides to mirror so I can access them. What’s the point of the fediverse if in order to access content from two instances I have to create separate accounts just because they don’t like each other’s content policy?