• 2 Posts
  • 18 Comments
Joined 1 year ago
cake
Cake day: July 10th, 2023

help-circle






  • you know you can easily scale up and down instance sizes on aws, or move your instance to, say oracle. I’ve done both of these. The Ansible installer makes it very easy to move. you just down your containers and copy over the volumes directory for the move.

    With these options you can start small and free. It may take a while to grow to 100 users. A 2 vcpu 2GB ram t4g.small on aws seems more than adequate and there’s a free trial through the end of the year. It’s arm64 though so small changes to the ansible lemmy.yml. The free tier t2.micro at 1 cpu 1 GB ram seemed too small.

    Oracle has an always free arm64 image with 4 cpu and 24 GB ram plus a generous boot disk and 200GB block storage so you might as well start there. It will probably last quite a while. Maybe all the way through 100 users. The only thing is while I know it’s very easy to change your instance type on AWS, I haven’t looked into it on Oracle. But again moving your instance is very easy.








  • 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