I have had concerns about this since I joined. Personally I don’t mind that the votes are public and can see a case for it, however the wider community is doing a very poor job of informing the users how this all works, and that will result in very bad outcomes.

Lemmy (the wider community) privacy does stink (and how to change that)

Thanks! I’m for mass adoption and want admins to succeed. That starts with keeping users educated (and admins covered).

This is largely assumed by someone like yourself or I who understands the implications. I am finding it evident that a lot of people are not aware.

There is also a distinction to a potential screenshot, a scrape or archive no one visits, and a federated copy on a widly used instance you have lost access to.

I edited my comment above to include a project I am working on to hopefully help admins get this across and educate users on how to appropriately engage to their comfort level.

This keeps on being asserted but it is far from true. If defederation happens or your local goes offline, posts/comment history/profile/votes will remain on other widely used instances and out of your control.

A large instance has already defederated with 2 other larger instances. If you run a personal instance I feel it will be very, very common for you where you will be locked out of managing your data.

You can expect defederation to happen all the time as that is a deliberate part of the open federated model.

And that is to say nothing about federation simply breaking sometimes.

I already have content that exists on other instances that will remain forever and I’ve only been around a short while. I don’t care personally, but people keep asserting this claim that only bad actors or scrapers will dupe your data. Federated data is very different than a non-federated copy for many reasons and that matters to some people. Everyone should understand deleting your account, or modifying your content will often not remove your content outside your instance, and many people engage outside their local. It will likely exist in federated, Lemmy searchable form forever in some capacity (in the current iteration anyway).

Not trying to spread FUD, but if we want to maintain users, they have to be educated as they will find out eventually and not be happy.

Due to the nature of such an open policy in sharing information (how open federation actually functions) could be frightening for someone uneducated on what privacy totally means, I have created this optional privacy policy introduction that will prime the user for what they are engaging in.

Personally I think everyone should be walking around with no pants, but I’d rather we talk each other’s pants off than scare off, or find our pants removed by surprise.

https://github.com/BanzooIO/federated_policies_and_tos/blob/main/optional-privacy-policy-intro.md

The analogy works to some extent, but it is a gross oversimplifications in most regards. But yeah, keeping up with maintaining a small mail server if you expect not to continually end up in SPAM is a royal pain.

Will be interesting to see how it develops. Could see a movement towards RBL type block lists, but with the lack of tools available at the moment I think most admins are going to end up having to take some pretty drastic actions at times.

I’ve been looking to do the same for the many pros I’ve seen posted here, but maybe someone can give me some clarity on a very big downside to me.

From my understanding most instances are pretty liberal with federating anyone, then blacklisting bad actots or problematic instances. However as adoption grows is there not the potential for larger instances to move towards a whitelist, and possibly move towards only federating with known, established instances or ones with established conditions? Possibly flat out banning personal instances due to moderation overhead?

Perhaps my understanding is incorrect, but seems to me that there could be a big future risk your personal server turns into an island and all of your past engagement is no longer in your control.