Thanks for taking the time to look it over! As I’ve expressed, this is really a Lemmy wide initiative, and as you’ve suggested, something that warrants a community fundraising effort to provide proper legal oversight.

Seems pretty long and I know this is a template so I imagine smorks will aim for much less given that he even makes an attempt to anonymise nginx logs. I think we might want to keep the template lower too just to nudge people in the right direction?

Meant to make this a admin supplied variable and have now updated. You’ve caught onto the spirit of what I am doing here though; it is not just intended as a document to inform users but to help admins navigate their responsibilities. That is why I have given the example of disclosure in what I see is a huge potential issue with the PostgreSQL SSL support. This will hopefully make a potential inexperienced admin take pause when their server is being tach’d out and the decide to host the DB outside of the local host without a proper mitigating strategy (and I have seen this happen before with very experienced admins in a commercial setting).

I think this is a key point but the “although” calls the security of ip/email into question and seems to potentially lump it in with the other stuff. Maybe split them out somehow?

Agreed. I kind of see how in one hand I’m saying that component is secure while also saying it isn’t without making the distinction between the user submitted public data and the traceable data that is being protected. I’ll figure out a better way to partition that.

Which does cause me to wonder: how is voting federated, do other instances see which users up/downvoted a comment from lemmy.ca or does lemmy.ca just provide vote totals for the instance?

This is my big concern here and why despite telling myself to stay out of it I got involved. A lot of people, very experienced people, and some admins, do not have a full picture of how this works yet. Your votes are entirely public, there is just the UI choice in Lemmy to not display them. On other interoperable platforms this data becomes public. When this comes up there is a chorus of people chiming in, “don’t post anything you don’t want public on the internet”. There is a difference between potential scraped or captured copies and a copy that is distributed by design. There are two different goals: a monolith platform has a measure of control in how your engagement is made public while being completely open to being tracked. A federated system, by design, has limited control over how public your engagement is (and remains) but a high level of tracking protection. This maybe started out as a group of largely technical users that understands this distinction, but as adoption grows so does the risk of this distinction not being well understood.

I found your draft a bit long and a bit, I dunno, overfamiliar?

Yeah, I am going to work on a “lite” version eventually. It is not a simple task to educate in this domain where you have two distinct ideologies on the same subject.

On second though, I wonder if this could be even more general and just a really polished version explaining the overall gist of the platform that instances can link to at joinlemmy.org. Like a section 1b “Why federated?” after https://join-lemmy.org/docs/index.html#introduction

I am pushing this hardcore platform wide. I have confidence in our local admin and would like to see it protected here, but the scope of my goal has gone platform-wide.

Thanks again for taking the time to provide input!