nip-86: implement updates. #42
No reviewers
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
nostr/chorus!42
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "86"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
cc @mikedilger
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.tomlfile is only read, never written, and theconfig.tomlfile 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.Maybe
user_hex_keyscan become dynamic. In that case, these will move into database tables and out of the config file.If we define a new
adminrole that is configured inchorus.tomlthen 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.@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?
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.
@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.
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
8ab043698ftoda897b950e, so this PR is done.🫡
Do you have a management website/tool ? Is it on github?
i have mangostr but its wip and not useable atm: https://github.com/dezh-tech/mangostr
Pull request closed