sentinel (in progress)

discussion and eventual implementation of a rebroadcasting client

What is Rebroadcasting?

As specified by NIP-01 a nostr event sent to a relay consists of a message in the format ["EVENT", <event JSON>] where the event JSON is a nostr event with a valid signature based upon the event content (public key, time stamp, content, tags, etc). The message sent to the relay doesn’t make any requirement about who sends a message or when (though some relays do not except events older than a certain threshold). This means that anyone can set up a client that reads events from one relay and publishes those events back to another relay - I will refer to this as rebroadcasting.

Motivation for Rebroadcasting

Below are a few basic reasons why a user might want to establish a rebroadcasting relay - clients used by the user are not consistently reading and writing to all relays - user wants to increase the relay overlap of his followed content even if a followed contact is not broadcasting to many similar relays - user is creating events from a device that has low-bandwidth and can only publish to a smaller set of relays - (if/when pay per relay broadcast is implemented) the user may want to publish right away to a small subset of relays and broadcast to additional relays when demand is low > Note: because rebroadcasting is not limited to a users own data there may be some ethical questions about the extent to which some find rebroadcasting acceptable. While I see some challenges that rebroadcasting could pose, the fact that it can happen is a reality of the specifications of the nostr protocol and the current client/relay landscape. These topics need to be explored to find the positive benefits and also to explore any potential downsides caused by rebroadcasting.

Potential Negative Implications of Rebroadcasting

rebroadcasting could have significant impacts on relay usage - because a rebroadcasting client does not have to remain fast and snappy like a client with a user interface it can broadcast more user data across more relays. Since anyone can broadcast data from any public key to any relay this could result in significantly more data duplication that harms less popular nodes.

TODO

Implement a simple client class for rebroadcasting data called Sentinel

from nbdev.showdoc import *

from nostrfastr import client

class Sentinel(client.Client):
    pass