As for the data transfer costs, any network data originating from AWS that hits an external network (an end user or another region) typically will incur a charge. To quote their blog post:

A general rule of thumb is that all traffic originating from the internet into AWS enters for free, but traffic exiting AWS is chargeable outside of the free tier—typically in the $0.08–$0.12 range per GB, though some response traffic egress can be free. The free tier provides 100GB of free data transfer out per month as of December 1, 2021.

So you won’t be charged for incoming federated content, but serving content to the end user will count as traffic exiting AWS. I am not sure of your exact setup (AWS pricing is complex) but typically this is charged. This is probably negligible for a single-user instance, but I would be careful serving images from your instance to popular instances as this could incur unexpected costs.

It’s still a fingerprint, the most vague information correlated with other data points can make a useful fingerprint. This is how a lot of the companies can track you even if you aren’t logged in, you using any service creates a pattern that with enough aggregate data can be used to approximate who you are.

Each instance serves the content from that instance, so from my understanding the only thing other instances can see are subscribed communities to be able to federate posts. Upvotes/Downvotes can possibly be tracked per user as they are federated on a per-vote basis currently, though this is just something I read and don’t have sources at the present.

Being an admin of an instance, I can’t even see my own history of visited posts. I can’t verify this, but I doubt this information is being stored in the database currently.

This being said, each instance has full control over their API server and the web-based application being served, so they could add monitoring to either to gather this data. If they did this on the API end it would be undetectable. Running your own instance is the only fool proof method, otherwise you need to trust the instance operator.

To dump a simple postgresql database, you can do something like:

pg_dump postgresql://lemmy:mypassword@example.com/lemmy -f backup.sql

This should result in a file being made named backup.sql for your database.

As for upgrading, my small instance with a 1.5Gb database upgraded with no issues using the docker images on kubernetes.

I’d say setting registrations to closed and having the operator enable/configure which to use is the best default. CAPTCHAs can also be automated, so this won’t stop anyone that is ambitious enough. If someone sees value in automating account registrations, they might be willing to pay for the CAPTCHAs to be solved for fraction of a US cent each.

Upgraded my instance, switched the docker images to 0.18.0-rc.6 and it started right up. Appears to have no issues for me thus far, so hopefully a full release will be right around the corner.

Good to know, but if that meets the legal requirements I cannot say. Really a lawyer that practices GDPR/CCPA would need to chime in if that is enough for either.

To address each of your points:

Maintainability and Scalability: This is a big concern, especially with users being drawn to large instances. In the beginning there will be pains, even the “flagship” lemmy.ml had issues maintaining this as this wasn’t their primary concern until recently. It is up to each instance owner to maintain their instance, and if it grows to large for them to handle to direct users to another instance. If an instance owner decides to abandon their instance, this will currently result in that instance being lost. I do think some protocol of preserving content (with the mechanisms for users to control the content) is needed but will need to be worked on in future versions. This could be done by users getting a key for example, and making requests via another instance to transfer their public user data over and they can control their content again from the new instance. This is just a thought though, and I am unsure how well this would work in practice. This will most likely become a topic of discussion among developers working on lemmy, so I have faith a good solution will be reached.

Monetization: The usual for this kind of stuff, donations using whatever service they prefer. I think some ads are ok, as long as they don’t siphon data and use advance techniques. Something such as as “sponsors” could work, it’s an ad but it’s not trying to steal your data. I think most instances would be abandoned if they implemented standard “google” ads.

Legal/Privacy - I am not a lawyer and this isn’t legal advice. Each of these laws have pretty clear details of implementations, and iirc they also only cover corporations and institutions. Users running instances themselves do not apply, but overall GDPR and CCPA compliance would be required as users won’t want the liability of running large instances. In my opinion, all that can be done is to have a delete request that propagates as any other content does. It’s up to the instance operator to fulfill the request.

I just upgraded, was fairly painless overall. Solid code coming from the devs, another good sign.

That would explain it, and I see they pushed docker images for 0.18.0-rc6. I might have to give it a spin on my instance, if they are running it must be pretty safe to use.

Edit: As for pending status, if I go click the orange “Subscription pending” button then re-subscribe it joins instantly.

Edit2: larger communities take some time still but you can actively see the posts coming in.

Edit3: The larger communities require a second unsubscribe/subscribe, but all my lemmy.ml communities are now synced! Great news.

The posts just started pouring into my instance as well. I think they might of, which is wonderful news.

I fear a lot of this is bot accounts.