Ferk

interoperability == API standardization == API homogeneity

standardization != monopolization

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.

Yes, but the loophole I was mentioning allows companies to not release the code even when it's GPL, that's why I was mentioning the AGPL (which is different from the LGPL).

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

I think many hobby developers also see "hobby" developing as part of their career, so they would happily try and have their hobby align with future employment possibilities. Since companies avoid GPL, those devs will rather choose a license that is more attractive to those potential employers when they see their portfolio.

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.

Thunar is a much better alternative, in my opinion.

To me, the problem is not really so much about "locking people in" (it's also unclear what you mean by that, if they were already using that ecosystem before using uutils aren't they already locked in?)

To me, the problem is how the MIT removes legal protections when it comes to ensuring accountability to changes in the source.. how can I be sure that the version of uutils shipped with "X Corp OS" has not had some special sauce added-in for increased tracking, AI magic, backdoor or "security" reasons? They are perfectly free to make changes without any public audit or having to tell their users what their own machine is doing anymore.

If you are using a GPL library that is statically linked to code with a different license the result is one binary that has inside both GPL and other license code, which would not be allowed under the GPL terms, because it requires that the binaries that use the source code must have their source code available in full (including other source and modifications that are part of the same binary).

The only case in which you don't need to provide the source for GPL software is if you don't actually distribute the binary to customers.. private binaries do not have to be published with their source, as long as you never made the binaries public and never gave it to anyone else. Only when you give it to someone you need to provide the code.

This allows for a loophole in which if you are providing a service, then you can run the software privately in your private server without sharing the source code to the clients using the service, since they do not really run the server program although they indirectly benefit from its results. This is why the AGPL was created, since it has a clause to force also those offering services to make the source of the server available to the users of the service.

Yes. Did I deny that?

Can anyone confirm or deny if what I said is wrong?

I get downvoted for stating one advantage an AGPL fork would have, and yet nobody seems to be disagreeing with what I said... *shrugs* 🤷