nip-86: implement updates. #42

Closed
kehiy wants to merge 2 commits from 86 into master
kehiy commented 2025-02-09 02:19:43 +13:00 (Migrated from github.com)

it currently doesn't support permissions and grants/revokes the access completely. i think for that purpose we need a hashmap.

another issue is that im not sure how much this code is correct, it needs a review.

- implements https://github.com/nostr-protocol/nips/pull/1734 it currently doesn't support permissions and grants/revokes the access completely. i think for that purpose we need a hashmap. another issue is that im not sure how much this code is correct, it needs a review.
kehiy commented 2025-02-09 02:19:54 +13:00 (Migrated from github.com)
cc @mikedilger
mikedilger commented 2025-02-09 11:39:50 +13:00 (Migrated from github.com)

I don't mind NIP-86 having commands about granting/revoking admin privilieges, but chorus will not implement them because chorus' policy is that the config.toml file is only read, never written, and the config.toml file is always right. This gives absolute power to the sys-admin and creates an administrative barrier such that bugs or hacks cannot change the configuration.

Not only are the grant/revoke admin/moderator functions not something I want, they also don't work because GLOBALS.config.write() does not write to the permanent config, it only writes to the in-memory config which, as soon as chorus restarts, will be reloaded from the config file. GLOBALS.config.write() is only used to load the memory config from the toml file in two places: at startup, and reloading on HUP.

I don't mind NIP-86 having commands about granting/revoking admin privilieges, but chorus will not implement them because chorus' policy is that the `config.toml` file is only read, never written, and the `config.toml` file is always right. This gives absolute power to the sys-admin and creates an administrative barrier such that bugs or hacks cannot change the configuration. Not only are the grant/revoke admin/moderator functions not something I want, they also don't work because `GLOBALS.config.write()` does not write to the permanent config, it only writes to the in-memory config which, as soon as chorus restarts, will be reloaded from the config file. `GLOBALS.config.write()` is only used to load the memory config from the toml file in two places: at startup, and reloading on HUP.
mikedilger commented 2025-02-09 11:45:10 +13:00 (Migrated from github.com)

Maybe user_hex_keys can become dynamic. In that case, these will move into database tables and out of the config file.

If we define a new admin role that is configured in chorus.toml then I would be okay with making moderators dynamic too. But moderators would not have the right to create new users or grant rights to anybody.

Maybe `user_hex_keys` can become dynamic. In that case, these will move into database tables and out of the config file. If we define a new `admin` role that is configured in `chorus.toml` then I would be okay with making moderators dynamic too. But moderators would not have the right to create new users or grant rights to anybody.
kehiy commented 2025-02-09 13:03:06 +13:00 (Migrated from github.com)

@mikedilger this is a part of current open pr on nip-86, not standard and merged to go-nostr for now.

i agree. we can still not support multiple admins as well. but if we want to support it, the best choice is to use the database instead of config. but config needs to contain the root admin who grants access to other ones.

what do you think? remove or replace with database?

@mikedilger this is a part of current open pr on nip-86, not standard and merged to go-nostr for now. i agree. we can still not support multiple admins as well. but if we want to support it, the best choice is to use the database instead of config. but config needs to contain the root admin who grants access to other ones. what do you think? remove or replace with database?
mikedilger commented 2025-02-11 07:50:00 +13:00 (Migrated from github.com)

Multiple admins are fine, but only via the config file. No granting/revoking admin privileges. Because that leads to coup de tat situations: The main owner grants admin to somebody he trusts, but then that somebody revokes admin from the main owner.

Multiple admins are fine, but only via the config file. No granting/revoking admin privileges. Because that leads to coup de tat situations: The main owner grants admin to somebody he trusts, but then that somebody revokes admin from the main owner.
kehiy commented 2025-02-11 09:45:42 +13:00 (Migrated from github.com)

@mikedilger the grant admin receives 2 parameters. first is pubkey. second is access level. a list of commands that this new admin have right to call... (i didn't implemented it on this pr since i was struggling with rust maps. but i can do it if we decided to keep these commands.)

but we are still able to keep it unsupported. and just merge the implementation of the rest of new commands like stats. 🫡

the good point about nip-86 is that we can only keep what we want and add custom commands even.

@mikedilger the grant admin receives 2 parameters. first is pubkey. second is access level. a list of commands that this new admin have right to call... (i didn't implemented it on this pr since i was struggling with rust maps. but i can do it if we decided to keep these commands.) but we are still able to keep it unsupported. and just merge the implementation of the rest of new commands like stats. 🫡 the good point about nip-86 is that we can only keep what we want and add custom commands even.
mikedilger commented 2025-02-11 10:54:26 +13:00 (Migrated from github.com)

Because of the complexity of moving things from the config file into a new database, I went ahead and made all the relevant changes this morning in 9 commits from 8ab043698f to da897b950e, so this PR is done.

Because of the complexity of moving things from the config file into a new database, I went ahead and made all the relevant changes this morning in 9 commits from 8ab043698fa8d835a4cee382796b058582f26699 to da897b950ecf2dfb2c553ca0d72a0ec955889226, so this PR is done.
kehiy commented 2025-02-11 10:55:13 +13:00 (Migrated from github.com)

🫡

:saluting_face:
mikedilger commented 2025-02-11 10:58:49 +13:00 (Migrated from github.com)

Do you have a management website/tool ? Is it on github?

Do you have a management website/tool ? Is it on github?
kehiy commented 2025-02-11 11:45:12 +13:00 (Migrated from github.com)

i have mangostr but its wip and not useable atm: https://github.com/dezh-tech/mangostr

i have mangostr but its wip and not useable atm: https://github.com/dezh-tech/mangostr

Pull request closed

Sign in to join this conversation.
No description provided.