True, but then you have bigger problems than just the journal.

Then simply write it in a text editor without saving it into a file, it’ll be lost after closing the program.

Can you point to a specific law that the EU has passed in this direction?

Cos according to the article all attempts to pass something like this that have been presented in the EU have been blocked. By the EU.

An alternative title could have been: “EU Possibly The Only One Who Has Been Explicitly Rejecting Backdoor Mandates Until Now”

Sure, proposals keep being presented… but I feel it’s kind of a bit early to call the EU “greatest threat” just because yet another attempt has been made. Specially when you compare it with many other places where they apply things like this without batting an eye.

I’m not saying we (Europeans) shouldn’t push (yet again) to make sure this also fails… but the title of the article is a bit misplaced, and after a history of successful rejections I feel a lot more optimistic.

Their instance has an individual identity they wished to protect.

If the intention of the separation were to prevent any interaction from anyone who isn’t an existing Beehaw user they would have closed the sign ups. But they didn’t do that (https://beehaw.org/signup is open).

The reason of Beehaw’s defederation has more to do with moderation hurdles, and how they don’t trust content coming from other instances, see Beehaws own statement about this: https://docs.beehaw.org/docs/important-questions-decisions-and-reflections/on-defederation/

Like I said: the way the federation works, it’s a moderation nightmare to be fully open. Not because as an instance host you wanna hide the content you have in your instance from the wider public, but because you have to deal with (host, mirror, cache and display along with your own content) content that is coming from a different instance which might not share your same moderation strategy.

I feel like the discussion assumes an individual users wish for seemless interactions is more important than the wish of other users to have the choice of non-interaction.

Both are reasonable asks. If a community wants to control who is allowed to access, there should be moderation tools that limit interaction to anyone who’s not been approved. However, this is a different thing from straight-up disallowing in your instance access to all users that happen to have registered their account in a particular instance. I don’t see why the identity/account provider cannot be separate from the access management and content moderation.

In fact, I feel that it would make access control EASIER for Beehaw if all new accounts actually were accounts from other instances, because that would let them audit the person applying for access in a more reliable way than they do currently in their signup form (https://beehaw.org/signup ). They would be able to check the post/comment history of the user, how many years has it been an active member, etc. before deciding if the user should be allowed to post content in their instance, and it would be protecting them from malicious actors / bots that might be pretending to be someone else. It would also potentially allow to use tools to check automatically the user for common bad patterns, which could potentially minimize a lot the human work in moderation and make the process much faster and convenient also for the person applying, so I feel this is a Win-Win if anything, not an “X has priority over Y”.

I think granular access control for communities and some other things that are coming will help when it comes to moderation tools. But it still cannot avoid having to deal with all the content from other instances in the federation, since that’s something fundamental in how activitypub works. There would need to be a new separate protocol for decentralizing the user identity between instances that don’t federate their content. Maybe something like OpenID.

Is that really what people mean by it being easier?

In Bluesky you are asked to choose a “Hosting provider” when you sign up… it;'s just that it’s set by default to Bluesky and actually trying to set something else makes the experience of signing in much harder… so actually I feel Bluesky is the one for which the process is harder, if anything.

I can’t even get a direct url to the sign up page of https://bsky.app/ …but I can link https://lemmy.ml/signup

Nobody is being forced to seek an alternative Lemmy instance to whichever they found first. In the same way that nobody in Bluesky has to use Bluesky as their hosting provider or even choose to self host their PDS.

Nice! It also seems to be under discussion on lemmy’s github here: https://github.com/LemmyNet/lemmy/issues/818

It does not have to be something mandatory…

I mean, there could be some form of “metacommunities”, something like being able to group multiple communities together in a “view” that shows them to you visually as if they were a single community despite being separated. Bonus points if everyone can make their own custom groupings (but others can subscribe to them… so there can be some community-managed groupings).

In theory you could have multiple “metacommunities” for the same topic still… but at least they could be sharing the same posts if they share communities. I feel grouping like this would be helpful because small communities feel even smaller when they are split.

I think reddit has something similar to that, multireddits or something I think they are called.

That’s the problem: the protocol pretty much requires explicit relationships between instances since they are forced to proxy/cache each other’s content. I think there’s too much responsibility on the instance… I feel it would be a moderation nightmare to host an instance with truly open federation (potentially even result in legal trouble!). So I totally understand why so many instances want to be conservative on who they federate with…

The ideal situation would be to be to be able to interact with third party instances directly (at least when the 2 instances don’t wanna agree on caching each other’s content), instead of having to use your home instance as proxy/cache… so the home instance would not need to have the burden (both legally and in terms of hosting resources) and it would just act as a way to identify the user, not necessarily as the primary content provider.

Potentially, using some sort of predictable hashing to get the same id across instances might also help in the detection of duplicate links so that they can be aggregated in a single place (sort of what was suggested at point 2 here).

I fear this could be too much of a breaking change though.

3. A way to backup your whole user data and completely restore it on any instance you want. If an instance goes under, it should be possible to keep all subscriptions, all your posts, all your comments, and migrate them to a new instance.

This would be great… also even if the “restore” part were not possible (yet?) I feel offering a way to extract your data might even be a requirement for a server to be fully GDPR compliant (though I could be wrong on that, IANAL), reddit does allow you to download your data after all.

Thanks. I wasn’t planning to go there anyway…

It’s annoying how the title throws such a general open question and then they don’t clarify this at all… there isn’t even a single match for “USA” or “America” in the whole article, you have to sort of guess.