From cee42f806e4a2ff8408f47189801fcc9c25348be Mon Sep 17 00:00:00 2001 From: sgmoore Date: Wed, 14 Dec 2022 07:56:06 -0800 Subject: [PATCH] Minor grammar fixes Minor grammar fix at line 13, 83, 85. and 111. --- 01.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/01.md b/01.md index dd4d80b..d040666 100644 --- a/01.md +++ b/01.md @@ -10,7 +10,7 @@ This NIP defines the basic protocol that should be implemented by everybody. New ## Events and signatures -Each user has a keypair. Signatures, public key and encodings are done according to the [Schnorr signatures standard for the curve `secp256k1`](https://bips.xyz/340). +Each user has a keypair. Signatures, public key, and encodings are done according to the [Schnorr signatures standard for the curve `secp256k1`](https://bips.xyz/340). The only object type that exists is the `event`, which has the following format on the wire: @@ -80,9 +80,9 @@ The `ids` and `authors` lists contain lowercase hexadecimal strings, which may e All conditions of a filter that are specified must match for an event for it to pass the filter, i.e., multiple conditions are interpreted as `&&` conditions. -A `REQ` message may contain multiple filters. In this case events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as `||` conditions. +A `REQ` message may contain multiple filters. In this case, events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as `||` conditions. -The `limit` property of a filter is only valid for the initial query and can be ignored afterwards. When `limit: n` is present it is assumed that the the events returned in the initial query will be the latest `n` events. It is safe to return less events than `limit` specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data. +The `limit` property of a filter is only valid for the initial query and can be ignored afterward. When `limit: n` is present it is assumed that the events returned in the initial query will be the latest `n` events. It is safe to return less events than `limit` specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data. ### From relay to client: sending events and notices @@ -106,5 +106,5 @@ A relay may choose to treat different message kinds differently, and it may or m ## Other Notes: - Clients should not open more than one websocket to each relay. One channel can support an unlimited number of subscriptions, so clients should do that. -- The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterwards (always as strings). This NIP defines `"p"` — meaning "pubkey", which points to a pubkey of someone that is referred to in the event —, and `"e"` — meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow. +- The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterward (always as strings). This NIP defines `"p"` — meaning "pubkey", which points to a pubkey of someone that is referred to in the event —, and `"e"` — meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow. - The `` item present on the `"e"` and `"p"` tags is an optional (could be set to `""`) URL of a relay the client could attempt to connect to fetch the tagged event or other events from a tagged profile. It MAY be ignored, but it exists to increase censorship resistance and make the spread of relay addresses more seamless across clients.