Allow SN users to edit special items forever

[ekzyis]

Description

This allows any user in SN_USER_IDS (removed kr from that list in #1203) to edit any item in ITEM_ALLOW_EDITS.

Checklist

Are your changes backwards compatible? Please answer below:

Yes

Did you QA this? Could we deploy this straight to production? Please answer below:

Yes

For frontend changes: Tested on mobile? Please answer below:

Did you introduce any new environment variables? If so, call them out explicitly here:

[ekzyis]

Ah, yes, it looks confusing since SN_USER_IDS includes ANON_USER_ID but mid is not set to ANON_USER_ID here yet. I'll try to make it more clear.

To me, SN_USER_IDS including ANON_USER_ID is the confusing part. I think that should only be for our personal accounts.

[huumn]

To me, SN_USER_IDS including ANON_USER_ID is the confusing part. I think that should only be for our personal accounts.

Ah, you're right. I wonder why I put that there.

[ekzyis]

I removed anon from SN_USER_IDS in 2c0f37ef but to not change any existing behavior, I left anon included in the places where SN_USER_IDS was used before.

However, I am not sure if anon should be part of the trust seeds?

Because of this line, anon votes are excluded in user_votes. This means that anon doesn't show up in user_votes and user_pair so if anon votes for something, that doesn't change anon's trust to whoever votes before. But more importantly, users don't start to trust anon if anon votes exist prior to their vote. This makes sense since anon isn't the same person and we thus want to exclude anon from the trust graph.

However, if I understand this line right, we cross join all users from user_pair with the seed users which receive max trust from every user in user_pair. Doesn't this mean that everyone trusts anon fully by default and this never changes? Is that intended?

But I ran following query on the prod database and saw that there is no arc from any user to anon or vice versa so clearly I am missing something:

SELECT * from "Arc" WHERE "toId" = 27 OR "fromId" = 27 ORDER BY "zapTrust" DESC LIMIT 21;

So I am confused if anon should be in SEED_USER_IDS or not.

I am also confused by the results of these queries:

-- who trusts me?
SELECT * from "Arc" WHERE "toId" = 6030 ORDER BY "zapTrust" DESC LIMIT 21;
-- who trusts k00b?
SELECT * from "Arc" WHERE "toId" = 616 ORDER BY "zapTrust" DESC LIMIT 21;

The first query seems to tell me that no one trusts me (id 6030) except @huumn (user id 616). I don't even trust myself. The second query seems to tell me that @huumn only trusts himself.

What am I missing?

[huumn]

anon shouldn't be given any special privileges or favor, so if they are, it's probably a mistake.

What am I missing?

You're missing that we only store significant deviations from the global consensus in Arc. The reason you or I don't have other people that trust us in Arc is because everyone trusts the seeds by default.

[ekzyis]

anon shouldn't be given any special privileges or favor, so if they are, it's probably a mistake.

mhh, so they shouldn't be included in SEED_USER_IDS

You're missing that we only store significant deviations from the global consensus in Arc. The reason you or I don't have other people that trust us in Arc is because everyone trusts the seeds by default.

Ahh, ok, makes sense

I noticed #1212 while finishing up this PR. But this and the anon issue are not really related to this PR since these issues already existed before.

As far as what this PR is concerned about, this PR is ready for review again. I also assume you're fine with less strict requirements on who can edit which special item? Before, it only gave the author infinite edits. Now, any user in SN_USER_IDS can edit any special item forever. So I'm basically giving myself more access here.