nip-86: updating methods, adding new ones.

[kehiy]

read parsed version.

these changes are based on discussions on: mikedilger/chorus#39.

and methods needed by the mangostr client: https://github.com/dezh-tech/mangostr.

method names are used to use snake_case since they are much more readable.

[kehiy]

@mikedilger @fiatjaf fyi.

if you think this is ok, i will work on the chorus and khatru implementation myself.

[mikedilger]

I didn't spend time checking this, just noticed this one thing.

[mikedilger]

@fiatjaf notice names changed to snake_case so anything that is out there already will break, but Kehiy seems keen to code this in both our relays. Personally I prefer snake_case to mashedcase.

[kehiy]

I didn't spend time checking this, just noticed this one thing.

i think the one thing was missed when you submitted the review. am i right? 👀

[fiatjaf]

I don't know what methods are being added because you reformatted the entire thing. I prefer the old formatting.

[kehiy]

you can check the parsed version and then we can talk about protocol changes, later i will update the formatting to the old one. its a little time-consuming and im not able to update it atm.

@fiatjaf

[kehiy]

@mikedilger @fiatjaf ive updated the formatting.

[mikedilger]

I think the changes are like this (this took a while to figure out):

HIGH LEVEL THINGS
	* supportedmethods	RENAMED supported_methods
	* changerelayname  	REMOVED	
	* changerelaydescription REMOVED
	* changerelayicon 		REMOVED
	* ADDED: stats
	* ADDED: set_nip11
	* ADDED: grant_admin
	* ADDED: revoke_admin

PUBKEY-based
	* banpubkey 			RENAMED TO ban_pubkey
	* listbannedpubkeys 	RENAMED TO list_banned_pubkeys
	* allowpubkey 		RENAMED TO allow_pubkey
	* listallowedpubkeys 	RENAMED TO list_allowed_pubkeys

EVENT-based
	* listeventsneedingmoderation	RENAMED to list_events_needing_moderation
	* allowevent 			RENAMED TO allow_event
	* banevent 			RENAMED TO ban_event
	* listbannedevents 		RENAMED TO list_banned_events
	* ADDED list_allowed_events

KIND-based
	* allowkind 			RENAMED allow_kinds
	* disallowkind 			RENAMED disallow_kinds
	* listallowedkinds 		RENAMED list_allowed_kinds
	* ADDED list_disallow_kinds

IP-based
	* blockip 				RENAMED block_ip
	* unblockip 			RENAMED unblock_ip
	* listblockedips 		RENAMED list_blocked_ips

[mikedilger]

list_allowed_events seems like it would produce too much data, almost every event on the relay.

list_disallow_kinds should be renamed list_disallowed_kinds

[kehiy]

@mikedilger thank you for summarizing the changes! yes, they are correct.

and i agree that list allowed events is a little weird. my idea was when you have a relay where all events are disallowed by default. like the idea behind white listing. but it would have a very limited use-case, we can remove it as well.

[kehiy]

list_disallow_kinds is also renamed to list_disallowed_kinds.

[kehiy]

any updates guys?

[fiatjaf]

These renames are all completely unnecessary.

I'm fine with adding grantadmin and revokeadmin. stats I don't think we should have because each relay will have different sets of stats so it's better if each does its own thing outside of the scope of this NIP -- or at least we need more experience before we standardize it. setnip11 doesn't make any sense.

[kehiy]

@fiatjaf i believe snake_case is much more readable. why not use it?

the stat command is just a base definition here. relays can add/remove fields to respond based on their design. fields are not restricted.

the set_nip11 command helps us manage nip11 and configs easily. otherwise, we have to add a huge amount of dedicated commands for each nip11 field and then we don't support custom fields.

[fiatjaf]

@fiatjaf i believe snake_case is much more readable. why not use it?

Because it's a completely unnecessary breaking change. Also I don't believe it is much more readable.

the stat command is just a base definition here. relays can add/remove fields to respond based on their design. fields are not restricted.

There is no point in having a specification that doesn't specify anything.

the set_nip11 command helps us manage nip11 and configs easily. otherwise, we have to add a huge amount of dedicated commands for each nip11 field and then we don't support custom fields.

I said it doesn't make sense because relays have these fields mostly hardcoded, generated based on other properties or configured by config files or environment variables. It doesn't make sense to change these things from an RPC command. The relay would then have to save that information and then act on it? How? It would be a mess. I'm not saying it wouldn't be doable or perhaps even useful in some cases, but in practice this is a confusing hassle that no one will use and will just bloat the spec.

[mikedilger]

the stat command is just a base definition here. relays can add/remove fields to respond based on their design. fields are not restricted.

There is no point in having a specification that doesn't specify anything.

Kehiy started with a bunch of separate well defined stat commands. But I know what will happen in practice is that there will be a 5 second lag while clients request each stat one at a time until they get them all. It doesn't make sense to do lots of round trips for individual statistics. Basically the meaning of the stats fields probably don't carry much meaning for software to act upon, the whole blob can just be displayed to the end user.

[fiatjaf]

Basically the meaning of the stats fields probably don't carry much meaning for software to act upon, the whole blob can just be displayed to the end user.

In this case I like it.

[kehiy]

@mikedilger thanks a lot for explanation.

@fiatjaf i can turn back the name cases, but i still prefer snake case.

also, i believe nip11 setting is a better replacement for one command per field like setname. same as one command per stat field it would be annoying.

but i will remove setnip11 and update naming.

[kehiy]

@mikedilger @fiatjaf spec updated. nip11 command removed and naming is same as before.

[mikedilger]

I also like snake case, but I don't like breaking things, and I expected this outcome which is why I never tried to change the names.

I didn't scour it again, but it looks good to me.