nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-14 09:13:39 +00:00
Code Issues Packages Projects Releases Wiki Activity

merge NIP-15 into NIP-01.

Browse Source
This commit is contained in:
fiatjaf 2023-04-09 08:50:24 -03:00
parent dee546ed9e
commit fb5b7c739f
3 changed files with 4 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
01.md
View File

@ -4,7 +4,7 @@ NIP-01
Basic protocol flow description
-------------------------------
`draft` `mandatory` `author:fiatjaf` `author:distbit` `author:scsibug` `author:kukks` `author:jb55`
`draft` `mandatory` `author:fiatjaf` `author:distbit` `author:scsibug` `author:kukks` `author:jb55` `author:semisol`
This NIP defines the basic protocol that should be implemented by everybody. New NIPs may add new optional (or mandatory) fields and messages and features to the structures and flows described here.
@ -89,7 +89,8 @@ The `limit` property of a filter is only valid for the initial query and can be
Relays can send 2 types of messages, which must also be JSON arrays, according to the following patterns:
* `["EVENT", <subscription_id>, <event JSON as defined above>]`, used to send events requested by clients.
* `["NOTICE", <message>]`, used to send human-readable error messages or other things to clients.
* `["EOSE", <subscription_id>]`, used to indicate the _end of stored events_ and the beginning of events newly received in real-time.
* `["NOTICE", <message>]`, used to send human-readable error messages or other things to clients.
This NIP defines no rules for how `NOTICE` messages should be sent or treated.

21
15.md
View File

@ -1,21 +0,0 @@
NIP-15
======
End of Stored Events Notice
---------------------------
`final` `optional` `author:Semisol`
Relays may support notifying clients when all stored events have been sent.
If a relay supports this NIP, the relay SHOULD send the client a `EOSE` message in the format `["EOSE", <subscription_id>]` after it has sent all the events it has persisted and it indicates all the events that come after this message are newly published.
Client Behavior
---------------
Clients SHOULD use the `supported_nips` field to learn if a relay supports end of stored events notices.
Motivation
----------
The motivation for this proposal is to reduce uncertainty when all events have been sent by a relay to make client code possibly less complex.

3
README.md
View File

@ -16,7 +16,6 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
- [NIP-12: Generic Tag Queries](12.md)
- [NIP-13: Proof of Work](13.md)
- [NIP-14: Subject tag in text events.](14.md)
- [NIP-15: End of Stored Events Notice](15.md)
- [NIP-16: Event Treatment](16.md)
- [NIP-18: Reposts](18.md)
- [NIP-19: bech32-encoded entities](19.md)
@ -96,7 +95,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
|--------|---------------------------------------------------------|-------------|
| EVENT | used to send events requested to clients | [1](01.md) |
| NOTICE | used to send human-readable messages to clients | [1](01.md) |
| EOSE | used to notify clients all stored events have been sent | [15](15.md) |
| EOSE | used to notify clients all stored events have been sent | [1](01.md) |
| OK | used to notify clients if an EVENT was successful | [20](20.md) |
| AUTH | used to send authentication challenges | [42](42.md) |
| COUNT | used to send requested event counts to clients | [45](45.md) |