add restricted to standardized machine-readable prefixes

[ZigBalthazar]

The restricted prefix is useful in situations where an individual is not whitelisted to write on a relay or has been banned from it.

For example, Immortal (websocket/event_handler.go#L125) uses a restricted prefix to send a message when someone who is not whitelisted tries to write on the relay, provided that the whitelist feature is enabled in the configurations.

Additionally, if this event is sent on nostr.wine:

["EVENT", {"kind":1,"id":"ba5a810abf66864fcde9ea1d2ecb33c83bd62833923e428540a0d7bccf93be74","pubkey":"79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798","created_at":1736858900,"tags":[],"content":"hello from the nostr army knife","sig":"c36b46d141d2d37f39a02c7437415a9913b6f13d4a4078afc3037504023d69705dd75ed12483192dafed4ed861282dace2997d096b8b346dd8b0a7d7a50fa024"}
]

the response will be:

["OK","ba5a810abf66864fcde9ea1d2ecb33c83bd62833923e428540a0d7bccf93be74",false,"restricted: not an active paid member"]

[alexgleason]

I am currently using blocked for whitelist.

Are you actually parsing these machine readable prefixes and mapping them to certain behavior in a client? Is anyone?

Are you working on a project where having this solves a specific problem?

I agree with you on the meaning of the words. restricted has a more correct semantic meaning. But I wonder if and how people are actually using machine readable prefixes. We should seek to understand this before updating the list.

[mikedilger]

Chorus has been using "restricted" for a long time now. I think it is reasonable.

However, gossip doesn't parse or use the machine readable prefixes, it just prints the whole message out.

[ZigBalthazar]

I am currently using blocked for whitelist.

Are you actually parsing these machine readable prefixes and mapping them to certain behavior in a client? Is anyone?

Are you working on a project where having this solves a specific problem?

I agree with you on the meaning of the words. restricted has a more correct semantic meaning. But I wonder if and how people are actually using machine readable prefixes. We should seek to understand this before updating the list.

@alexgleason
The machine-readable prefixes are defined for use by clients and bots in any way they choose. They are not related to relays. According to the NIP, the relay is only responsible for returning errors related to the machine-readable prefixes, while clients and bots should decide how to take action based on that information.

Regarding the blocked prefix, if someone is on the blacklist, they are considered blocked. However, if a user is not on the blacklist and also not on the whitelist, it indicates that the user is restricted, not blocked.

In my opinion, machine-readable prefixes are more useful in the internal codes of clients or bots. Many services, like NIP-47 (NWC) and other platforms that interact with relays, can parse errors and utilize the prefix section to determine the appropriate internal actions. Meanwhile, the explanation part can be displayed to the end user in a human-readable format. If there isn’t an end user, such as in the case of scripts or bots, the prefixed part can be leveraged to make optimal decisions and take the best actions.

[Semisol]

In my opinion:

• Restricted -> Not allowed here, such as not on whitelist
• Blocked -> Explicit content moderation action (pubkey blocked, or content filtering)