Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow SN users to edit special items forever #1204

Merged
merged 7 commits into from
Jun 3, 2024
Merged

Allow SN users to edit special items forever #1204

merged 7 commits into from
Jun 3, 2024

Conversation

ekzyis
Copy link
Member

@ekzyis ekzyis commented May 29, 2024

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:

Copy link
Member

@huumn huumn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ekzyis
Copy link
Member Author

ekzyis commented May 29, 2024

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
Copy link
Member

huumn commented May 30, 2024

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
Copy link
Member Author

ekzyis commented May 30, 2024

I removed anon from SN_USER_IDS in 2c0f37e 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
Copy link
Member

huumn commented May 31, 2024

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
Copy link
Member Author

ekzyis commented May 31, 2024

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.

@ekzyis ekzyis requested a review from huumn May 31, 2024 17:55
@huumn huumn merged commit 86b857b into master Jun 3, 2024
6 checks passed
@huumn huumn deleted the admin-edits branch June 3, 2024 16:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants