volkris

@sabreW4K3 Well that's a pretty nonsensical take.

The use of some decentralization techniques? It is decentralized because it uses decentralization techniques, and that's all there is to it. It is far more decentralized than this platform because of the techniques it uses. It focuses on users instead of centralizing around instances.

From the point of view of power dynamics? GTFO with that BS.

No, BlueSky is decentralized. It is more decentralized than this platform. These people are trying really really hard to bend things and find problems that don't really match reality.

And they need to be called out over it.

I really wish this platform was more decentralized, but that's not how the engineers designed it, and we need to call them out over it.

@Sprite I could imagine two schools of thought on that.

(and I’m not saying one is right or not)

The other side is I imagine a ban represents an intention to disconnect, including the connection that would be required to let the person know they’re banned.

That also avoids drama that a misbehaving user might stir up in response to the ban.

Technically, in this distributed system, banning is more about ignoring someone. Instances can’t trust each other, so by keeping banning on the receiver side instead of the sender side, the ban-er has more control over the banning.

Moderation in the Fediverse is about making sure MY users on MY instance get the experience they want, regardless of what any other instance does.

It all comes down to the distributed structure here.

@Sprite I don’t think this is really possible in a distributed system like Fediverse since there isn’t a centralized list of bans.

You’d have to go to every instance one by one asking if you’re on their ban list, and since that list of instances is huge and changing by the day it’s just not practical under the design of this system.

@Sprite I don’t know if it would be a HUGE leap forward, but it’s a case of might as well.

AFAIK, ActivityPub allows arbitrary fields to be added to the Profile object, so sites might as well add some sort of adult/nonadult tag (maybe not 18+ as ages of majority differ internationally).

It would be as useful as alcohol sites putting up splash screens checking users’ ages before they access the website: No, not trustworthy, but checks the box for legal compliance.

And yes, some users might want to have their interactions skewed toward older folks, again yes, not trustworthy, but it would help some.

@ikantolol

Perhaps that’s what you get without defederation :)

But I say that with my eternal emphasis that each user should be empowered to shape their own experience here, as much as practical, even if that includes an experience that some of us might view as cesspoolish.

@BenJammin @Double_A

@sparr

I’ve heard (but not confirmed) that some lemmy domains are having issues with firewalls blocking them, maybe as DDOS avoidance features, so your instance is unable to reach out and see if the user exists.

I’ve heard that from multiple people and forum posts at this point.

@lemmy @liaizon @Mastodon

@jpm

Think of Lemmy as being just a different Mastodon client that happens to display things to their users with a different skin.

You interact with content on a Lemmy instance the same way as you interact with content on a different Mastodon instance.

(Technically they’re both ActivityPub clients, for the more correct terminology)

There do seem to be some kinks to iron out between the clients, though. The ! thing might be one where they disagree on how to handle it.

@programming

@astroturds

Result: interesting, my reply from a Mastodon instance showed up, but on the web interface I don’t see my username.

Maybe a little rough edge to look into.
@ValueSubtracted

@astroturds

If you’re interested in a little more behind the scenes info on how this works, (and since I want to make a test post to see how it shows up in Lemmy):

Since there’s no central clearinghouse for content in the distributed Fediverse, each instance broadcasts its users’ new posts, but only to other instances that need to see that content, generally because they host at least one user interested in it.

So you’ll see times when your instance won’t have received any older content before its first user followed the remote account. After that, the remote instance knows to start sending content to your instance, to that user really, but then your instance knows about the content.

In other words, your instance begins its subscription to the remote account by having any user begin to follow it.

@ValueSubtracted