Re: [nostr-protocol/nips] merge nips 12, 16, 20 and 33 into nip 01 (PR #703)

[William Casarin]

On Fri, Aug 11, 2023 at 04:39:47AM -0700, Viktor Vsk wrote:
>@viktorvsk commented on this pull request.
>-Relays MUST return `false` when the event was rejected and not saved.
>-
>-The `message` SHOULD provide additional information as to why the command succeeded or failed.
>-
>-The `message` SHOULD start with `blocked:` if the pubkey or network address has been blocked, banned, or is not on a whitelist.
>-
>-The `message` SHOULD start with `invalid:` if the event is invalid or doesn't meet some specific criteria (created_at is too far off, id is wrong, signature is wrong, etc)
>-
>-The `message` SHOULD start with `pow:` if the event doesn't meet some proof-of-work difficulty. The client MAY consult the relay metadata at this point to retrieve the required posting difficulty.
>-
>-The `message` SHOULD start with `rate-limited:` if the event was rejected due to rate limiting techniques.
>-
>-The `message` SHOULD start with `error:` if the event failed to save due to a server issue.
>-
>-Ephemeral events are not acknowledged with OK responses, unless there is a failure.
>
>I don't know but I would expect something like avoiding traffic generated by events like typing... indicator. Good if we remove this line

because ephemeral events aren't written. Command results were
originally conceived for determining if the command was written to the
database or not. I guess it might be useful to know if an ephemeral
event was relayed?