hmm weird. This bot is announcing an 18.2 release (and I think people are installing it.) https://matrix.to/#/#lemmy-support-releases:discuss.online

But the repo is still showing 18.1 as the latest.

so consider a smaller local instance like I'm setting up. If it's ever anything more than me and my mom it's gonna be a bunch of people I know and their friends. And if my instance is their entry point to the fediverse then yeah I want it to be as private as we can make it for them.

But also, even if someone's IRL identity was masked, I've only been around a week and I'm starting to recognize handles on the fediverse. Ideally we make friends here and it's a community for us.

Now imagine how humiliating it would be if someone malicious gained control over an instance and published everyone's subscriptions/likes etc. Sure more savvy users probably do have separate accounts but honestly most will not.

the point is not to encrypt your user id, check this out if you haven't seen it I think I explain it better here: https://lemmyadmin.site/comment/46. It's a lot more privacy. And thinking as an admin that wants to provide a safe space for my users, I think it's worth the effort. I took a very quick look at the tables related to person and I'd bet you could treat these similarly to community_follower:

TABLE "comment_like" CONSTRAINT "comment_like_person_id_fkey" FOREIGN KEY (person_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "comment_saved" CONSTRAINT "comment_saved_person_id_fkey" FOREIGN KEY (person_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "community_block" CONSTRAINT "community_block_person_id_fkey" FOREIGN KEY (person_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "community_follower" CONSTRAINT "community_follower_person_id_fkey" FOREIGN KEY (person_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "person_follower" CONSTRAINT "person_follower_follower_id_fkey" FOREIGN KEY (follower_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "post_like" CONSTRAINT "post_like_person_id_fkey" FOREIGN KEY (person_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "post_read" CONSTRAINT "post_read_person_id_fkey" FOREIGN KEY (person_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "post_saved" CONSTRAINT "post_saved_person_id_fkey" FOREIGN KEY (person_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "private_message" CONSTRAINT "private_message_creator_id_fkey" FOREIGN KEY (creator_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE
TABLE "private_message" CONSTRAINT "private_message_recipient_id_fkey" FOREIGN KEY (recipient_id) REFERENCES person(id) ON UPDATE CASCADE ON DELETE CASCADE

There, you've already found a reasonable way around it! 😀

lets take community subscriptions specifically. Here's a handful of rows from community_follower with my person_id. Why couldn't you hash community_id with my public key and then I provide my private key to whatever ui client I'm using to populate my feeds when I log in?