Mirror/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2025-01-18 20:21:35 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

add delete and report to recommended spider event kinds

Browse Source
This commit is contained in:
mleku 2024-12-24 11:48:02 -01:06
parent 91e7350738
commit d2a6cbe762
1 changed files with 14 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
79.md
View File

@ -61,23 +61,23 @@ then they can forward messages they have received from their client, wrapped as
event.
For efficiency of filtering, all encapsulated events inside a 23516 must have the npubs in a `p` tag that are found in
the stringified json inside, which should be copied from further 23516 events at any level of depth. Compliance with
the stringified json inside, which should be copied from further 23516 events at any level of depth. Compliance with
this should be verified by relays and failure to do this correctly should result in halting relaying of events from this
relay, messages should be simply dropped, and the sender will likely automatically drop the connection due to not
relay, messages should be simply dropped, and the sender will likely automatically drop the connection due to not
getting OK acks anymore.
The initiation of this process starts with this message kind with no content, and this causes the recipient to
add a subscription for forwarding events received by the relay of the 235xx kind wrapped in a 23516 to the sender of
The initiation of this process starts with this message kind with no content, and this causes the recipient to
add a subscription for forwarding events received by the relay of the 235xx kind wrapped in a 23516 to the sender of
this empty message. This will cease when the socket is disconnected. The wrapped events are sent as-is to all listeners
subscribed to the event kind, so long as the p tags validate against the p tags in the layers of forwarded messages.
When a relay has more than two other relays joined with it in a group, it will only send messages it receives to two of
the 3+ other relays, ensuring that the volume of messages is received at most 2-3 times by other members of the group. A
the 3+ other relays, ensuring that the volume of messages is received at most 2-3 times by other members of the group. A
buffer of recently broadcast IDs should be maintained along with their timestamp of being received, and after they are
more than 30 seconds old, they can be safely removed.
The messages will be propagated including the forwarding wrapper, so as a message group gets larger, the messages will
be 3 and more layers deep. There is no real need to have groups get much larger than maybe 16 so a depth of 5-7 is
The messages will be propagated including the forwarding wrapper, so as a message group gets larger, the messages will
be 3 and more layers deep. There is no real need to have groups get much larger than maybe 16 so a depth of 5-7 is
likely the maximum practical, and a relay can refuse to forward messages that are more than some specified depth.
For protection against spam, multiple measures can be applied:
@ -87,7 +87,7 @@ For protection against spam, multiple measures can be applied:
- Relays won't send events to clients if the npub of the sender is on their mute list, thus users can mute group member
propagated messages, as well as separately filtering out relays and users npubs contained within
With all these measures in place, open membership based groups across multiple relays can function without central
With all these measures in place, open membership based groups across multiple relays can function without central
coordination.
## Chatrooms via Hashtags
@ -96,7 +96,7 @@ The simple use of `t` tags and a hashtag MUST be recognised as meaning a message
this specific chatroom. `#general` will be a default in clients for the initial room that is rendered in an not yet
configured client, clients should receive all events in the background and populate a hashtag list to enable favourites.
The hashtag of a message should also appear in all 23516 group forwarded messages tags as well to facilitate easier
The hashtag of a message should also appear in all 23516 group forwarded messages tags as well to facilitate easier
processing, in addition to all npubs appearing in encapsulated messages. Messages can only have one hashtag.
Messages with hashtags should be whitelist propagated to users who have the hashtag in their follow list, AND NOT in the
@ -124,9 +124,11 @@ additionally permitted in order to facilitate easy access, this can be informal,
Further, to facilitate necessary user interface features, all following kinds of users permitted to use the relay should
be sought and cached:
- ProfileMetadata 0
- FollowList 3
- MuteList 10000
- 0 ProfileMetadata
- 3 FollowList
- 10000 MuteList
- 5 Event Deletion
- 1984 Reporting
The relay lists can be used to acquire a set of sources to interrogate, and from there these event kinds are needed in
order to implement the features of this NIP.