highperfocused/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2025-03-25 17:21:52 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge 85ea8ab1245aa89cb612e47ab7511fe3d8bb041c into 0619f370bca3485bb9c5870bc2defa03c7c3d10e

Browse Source
This commit is contained in:
fiatjaf_ 2025-03-18 13:07:25 -03:00 committed by GitHub
commit 012a103fe4
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 11 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
01.md
View File

@ -113,7 +113,7 @@ Relays expose a websocket endpoint to which clients can connect. Clients SHOULD
Clients can send 3 types of messages, which must be JSON arrays, according to the following patterns:
* `["EVENT", <event JSON as defined above>]`, used to publish events.
* `["REQ", <subscription_id>, <filters1>, <filters2>, ...]`, used to request events and subscribe to new updates.
* `["REQ", <subscription_id>, <filter>]`, used to request events and subscribe to new updates.
* `["CLOSE", <subscription_id>]`, used to stop previous subscriptions.
`<subscription_id>` is an arbitrary, non-empty string of max length 64 chars. It represents a subscription per connection. Relays MUST manage `<subscription_id>`s independently for each WebSocket connection. `<subscription_id>`s are not guaranteed to be globally unique.
@ -142,8 +142,6 @@ The `since` and `until` properties can be used to specify the time range of even
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.
The `limit` property of a filter is only valid for the initial query and MUST be ignored afterwards. When `limit: n` is present it is assumed that the events returned in the initial query will be the last `n` events ordered by the `created_at`. Newer events should appear first, and in the case of ties the event with the lowest id (first in lexical order) should be first. 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

20
50.md
View File

@ -8,11 +8,11 @@ Search Capability
## Abstract
Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids.
Specifics of the search algorithms will differ between event kinds, this NIP only describes a general
Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids.
Specifics of the search algorithms will differ between event kinds, this NIP only describes a general
extensible framework for performing such queries.
## `search` filter field
## `search` filter field
A new `search` field is introduced for `REQ` messages from clients:
```jsonc
@ -21,23 +21,23 @@ A new `search` field is introduced for `REQ` messages from clients:
"search": <string>
}
```
`search` field is a string describing a query in a human-readable form, i.e. "best nostr apps".
Relays SHOULD interpret the query to the best of their ability and return events that match it.
`search` field is a string describing a query in a human-readable form, i.e. "best nostr apps".
Relays SHOULD interpret the query to the best of their ability and return events that match it.
Relays SHOULD perform matching against `content` event field, and MAY perform
matching against other fields if that makes sense in the context of a specific kind.
matching against other fields if that makes sense in the context of a specific kind.
Results SHOULD be returned in descending order by quality of search result (as defined by the implementation),
not by the usual `.created_at`. The `limit` filter SHOULD be applied after sorting by matching score.
A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore
A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore
extensions they don't support.
Clients may specify several search filters, i.e. `["REQ", "", { "search": "orange" }, { "kinds": [1, 2], "search": "purple" }]`. Clients may
Clients may specify several search filters, i.e. `["REQ", "_", {"kinds": [1], "search": "purple"}]`. Clients may
include `kinds`, `ids` and other filter field to restrict the search results to particular event kinds.
Clients SHOULD use the supported_nips field to learn if a relay supports `search` filter. Clients MAY send `search`
Clients SHOULD use the supported_nips field to learn if a relay supports `search` filter. Clients MAY send `search`
filter queries to any relay, if they are prepared to filter out extraneous responses from relays that do not support this NIP.
Clients SHOULD query several relays supporting this NIP to compensate for potentially different
Clients SHOULD query several relays supporting this NIP to compensate for potentially different
implementation details between relays.
Clients MAY verify that events returned by a relay match the specified query in a way that suits the