Honor limit field of REQ filter if specified

[jimbojw]

NIP-01 describes filter objects which can be sent along with REQ messages to select which stored messages to return. One of the fields on a filter object is limit, which allows the client to specify a maximum number of stored events to return.

Currently, memorelay ignores the limit field and simply returns all events that match the filters' other criteria. Instead, only up to limit events should be returned, if specified.

There's a race condition which can occur, in that events which arrive during the sweep of historical events may never be sent to the REQ subscription. Consider the case where there are three events stored, called A, B and C. Now say a REQ request comes with a limit of 3. Then, while memorelay is fetching and sending A, B, and C, a new event D arrives. The limit will be reached before getting to event D, but the subscription won't begin until the sweep is finished. Event D is therefore never sent. It's unclear as yet how to resolve conditions such as this.

From NIP-01:

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.

To implement this, memorelay should search backwards from the latest known event to find the earliest known matching event before sweeping forward.

[github-actions]

🎉 This issue has been resolved in version 1.6.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀