Russ

No, because since it’s only a third party app implementation, tags wouldn’t follow if I go from my phone to my desktop or any other device. It also just seems kinda… Strange?

Do you keep a journal of those you meet in-person? No judgement if you do, but if your reaction to that question was “Eww, no!” but also do user tagging I would be very curious as to what the difference is for you.

Anyways, for problematic people they either get blocked or banned (the egregious ones) which by nature of it being a first-party feature is already synced.

According to another user in here, blocking on Mastodon actually works. So seems like it is possible to do in the Fediverse.

I was not aware of this, but their implementation of how they do this does bring up the limitation I mentioned. The other user cannot see your posts only if you are on the same server:

If you and the blocked user are on the same server, the blocked user will not be able to view your posts on your profile while logged in.

I actually thought blocks were public already.

They’re not, well - the operator of your instance could go into the database and view it that way in the same way that they can see your email address. But aside from someone who has database access to your instance, blocks are not public. What is public is the list of defederated (“blocked” so to speak) instances for an entire instance (this can be viewed by going to /instances of any instance), which might be what you were thinking of?

And personally I don’t see how it would be an issue if people that I haven’t blocked can see who I’ve blocked.

How exactly would you enforce that, though? If your blocks were public, all the person who you’ve blocked would need to do is open a private browsing window and look at your profile to see that they’ve been blocked.

If we’re looking at blocks as being a safety feature, I would think that having your blocks broadcasted to every single instance would be classified as harmful and a breach of your privacy. This is why although an instance that you register with has to have your email address that you signed up with, they don’t broadcast it to all other instances (same with the encrypted value of your password) - because otherwise it would effectively be public.

Perhaps I’ve just got the wrong stance, but considering that you can never block someone from viewing your content with an absolute guarantee (if the blocks were broadcasted, you still couldn’t prevent someone from just simply logging out, or standing up their own instance and collecting the data anyways) I would not consider that tradeoff to be worthwhile. Not that my stance has any weight since I’m not a maintainer for Lemmy (or any of the Fediverse software), but I wouldn’t be surprised if that has at least come up to those who are developing the various Fediverse software.

Aside from the rest of the discussion that has already occurred here, I’m not actually sure how this would work from a technical perspective.

You and I are on two completely different instances, if I were to block you, how is your instance supposed to know this in order to stop you from reading my comment?

The only way I could see that working is if the list of users you blocked were federated too, and effectively made public (like votes currently are) - which seems counterproductive to the problem at hand.

Then what happens if you post in a community where someone you’ve blocked is a moderator? Or if you block the admin of another instance? If you can “cloak” yourself from being moderated by just blocking them, that seems like an exploit waiting to happen. As far as I’m aware, on Reddit blocking a user doesn’t hide your comments from them - but they can no longer reply to them, and I assume this is why that is the case. Unless that has very recently changed.

The biggest difference between Lemmy (and all software within the Fediverse - for example, I’m pretty sure Mastodon is this way as well), is that there is not one singular authoritative server. Actions like this need to be handled on all instances, and that’s impossible to guarantee. A bad actor running an instance could just rip out the function that handles this, and then it’s moot. I mean, they wouldn’t even need to do that - they’d have the data anyways.

You could enforce it if both users are on the same instance I suppose, but this just seems like it would only land with the blocking feature being even more inconsistent.