adding more nip-86 apis. #39

New issue

Closed

opened 2025-01-30 07:27:21 +13:00 by kehiy · 3 comments

kehiy commented

2025-01-30 07:27:21 +13:00

(Migrated from github.com)

here is my suggestion:

liveconnections
uptime
totalevents
total | receives an input which is a filter.
delete | removes an event. (im not sure if the banevent command dose the same?)
updatenip11 | instead of passing keys one by one, inputs a whole json object and replace non-null ones with current document + add new ones. if it was present and set to null, it would remove it. this is the current model in immortal which reduces number of apis. (but nip-86 incompatible)
add/removeadmin | inputs a pubkey to grant premissons to them, a list of command names may be present to limit access level.

all would be supported in mangostr.

here is my suggestion: 1. `liveconnections` 2. `uptime` 3. `totalevents` 4. `total` | receives an input which is a filter. 5. `delete` | removes an event. (im not sure if the banevent command dose the same?) 6. `updatenip11` | instead of passing keys one by one, inputs a whole json object and replace non-null ones with current document + add new ones. if it was present and set to null, it would remove it. this is the current model in immortal which reduces number of apis. (but nip-86 incompatible) 7. `add/removeadmin` | inputs a pubkey to grant premissons to them, a list of command names may be present to limit access level. > all would be supported in mangostr.

mikedilger commented

2025-01-30 10:45:23 +13:00

(Migrated from github.com)

Ok I would maybe rename or tweak these a little. We already merged the first one but still I would change it.

banevent deletes an event and prevents it from reappearing which is essentially the same as any delete would do.

numconnections:
- params: []
- result: <number>
uptime:
- params: []
- result: <number-of-seconds>
bandwithstats:
- params: []
- result: ["bytes_received": <number>, "bytes_sent": <number>]
storagestats:
- params: []
- result: ["num_events": <number>, "event_bytes": <number>, "num_files": <number>, "file_bytes": <number>]
- Note fields may not be present if the data is not available
grantadmin:
- params: [<32-byte-hex-public-key>]
- result: true
revokeadmin:
- params: [<32-byte-hex-public-key>]
- result: true

You can add updatenip11 but chorus can't easily support it (the NIP-11 is hard coded)

Chorus really needs the allowevent and allowpubkey functionality. Events which don't pass a test have to go through an approval process to become publicly readable at which point either one of those can make it readable.

Ok I would maybe rename or tweak these a little. We already merged the first one but still I would change it. `banevent` deletes an event and prevents it from reappearing which is essentially the same as any delete would do. * `numconnections`: * params: `[]` * result: `<number>` * `uptime`: * params: `[]` * result: `<number-of-seconds>` * `bandwithstats`: * params: `[]` * result: `["bytes_received": <number>, "bytes_sent": <number>]` * `storagestats`: * params: `[]` * result: `["num_events": <number>, "event_bytes": <number>, "num_files": <number>, "file_bytes": <number>]` * Note fields may not be present if the data is not available * `grantadmin`: * params: `[<32-byte-hex-public-key>]` * result: `true` * `revokeadmin`: * params: `[<32-byte-hex-public-key>]` * result: `true` You can add `updatenip11` but chorus can't easily support it (the NIP-11 is hard coded) Chorus really needs the `allowevent` and `allowpubkey` functionality. Events which don't pass a test have to go through an approval process to become publicly readable at which point either one of those can make it readable.

👍 1

kehiy commented

2025-01-31 09:00:32 +13:00

(Migrated from github.com)

i agree with your changes. im going to implement them.
what about total event counts and stuff like this? i can call the relay publicly using COUNT as well, but not sure which is better.

about nip11 we can discuss in more details, maybe keeping both, idk really.

i agree with your changes. im going to implement them. what about total event counts and stuff like this? i can call the relay publicly using `COUNT` as well, but not sure which is better. about nip11 we can discuss in more details, maybe keeping both, idk really.

kehiy commented

2025-08-02 00:35:09 +12:00

(Migrated from github.com)

I think we need to discuss the final NIP-86 methods and details in NIPs repo first, then we can go for a full implementation here.