When submitting events to relays, clients currently have no way to know
if an event was successfully committed to the database. This NIP
introduces the concept of command results which are like NOTICE's except
provide more information about if an event was accepted or rejected.
A command result is a JSON object with the following structure that is
returned when an event is successfully saved to the database or
rejected:
["OK", <event_id>, <true|false>, <message>]
nip20: https://github.com/nostr-protocol/nips/pull/62
Add a ping interval setting that allows you to customize the websocket
ping interval. The default of 5 minutes may be too high for some proxy
servers that disconnect connections that are held open for too long.
This enables support for using the proxied IP from cloudflare. The damus
relay is behind cloudflare, so to get accurate remote ip logging we need
to look at the headers instead of the socket address.
Signed-off-by: William Casarin <jb55@jb55.com>
These are pretty spammy on busy relays. I've been using the info log to
monitor spam attacks, and these are the least useful info log.
Leave the "stopping connection" log because it at least provides useful
sent/received information.
Signed-off-by: William Casarin <jb55@jb55.com>
Implements core NIP-26 delegated event functionality. Events can
include a `delegation` tag that provides a signature and restrictions
on which events can be delegated.
Notable points on the implementation so far:
* Schema has been upgraded to include an index and new column.
* Basic rune parsing/evaluation to implement the example event in the
NIP, but no more.
* No special logic for deletion.
* No migration logic for determining delegated authors for
already-stored events.
Schema upgrades were buggy from 4->5 (the v5 would be skipped). This
change also refactors the logic slightly so that future additions can
be clearer (no need to have if and else-if combinations).
NIP-01 prefix search, and NIP-12 generic tags are no longer marked as
experimental.
NIP-11 relay info advertises NIP-09 event deletion and NIP-12 generic
tag search support.
The `reject_future_limits` option can now be disabled, and is by
default.
NIP-11 advertises support for created_at limits.
The message for future-dated events has been modified, to be closer to
the recommended example in the NIP.
Only lowercase and even-length tag values are stored as binary BLOBs.
Previously there was an error which search results from being returned
if the tag value was mixed-case and could be interpreted as hex.
A new database migration has been created to repair the `tag` table
for existing relays.
fixes: https://todo.sr.ht/~gheartsfield/nostr-rs-relay/37
The original implementation of subscription limit applied to the
entire query, instead of the specific filter. Now, each filter gets
its own query limit. When a limit is applied, the most recent N
events will be returned, otherwise the default is to return the
earliest events (in order), for all matching events.
This was quickly sneaked in by fiatjaf per my request[0], it makes many
queries more efficient and allows for paging when combined with until.
It is a bit weird to have multiple limits on each filter... for now we
just choose any or the last limit seen.
[0]: a4aea5337f
Signed-off-by: William Casarin <jb55@jb55.com>
This adds a new configurable feature to restrict event publishing to
only users with NIP-05 verified metadata. Domains can be whitelisted
or blacklisted. Verification expiration and schedules are
configurable.
This upgrades the database to add a table for tracking verification
records.
When a large number of subscriptions is created with identical names,
we do not send a signal over the abandon-read channel. This
eventually leads to resource exhaustion.
This is an experimental feature, outside of any NIP, that demonstrates
generic tag queries.
Instead of limiting subscription filters to just querying only "e" or
"p" tags (via `#e` or `#p` attributes), any tag can be queried.
As an example, consider an event which uses a tag "url". With this
modification, a subscription filter could add a top-level field
"#url", with an array of strings as the key. Exact matches would be
returned.
A NIP is forthcoming to formalize this.
* Add custom error variant
This can be useful to propagate errors not conforming to available
variants. Also to convert other errors in `crate::Error` without having
explicit conversion defined, with `error.to_string()`
* Implement `Tag` and define protocol serialization
A Tag structure have been implemented with dedicated field types. Then
custom serde serialization is derived to map the structure to current
protocol json array as per NIP01.
This adds compile and run time type checking to always ensure wrong
string data are never stored or processed. With strict typed fields and
custom serde derivation this checks can be done at time of serialization,
saving work for internal handling of the actual data.
tests for possible data violations are added, and gives good example of
kind of errors it will through for different cases.
* Use String for URL
Change descr to description. Add `id` for websocket URL. Use
integers for supported NIPs instead of strings. Top-level is object,
instead of the array before.
Switched to latest (git) release of secp256k1, which has more
efficient verification-only context for Schnorr. Switched to single
pre-instantiated instance of the verifier.
This adds Hyper, and a 200 response code. Prior to this, Firefox
would fail to connect. There is also a text document displayed at the
root URL to indicate this is a Nostr relay.
Fixes https://todo.sr.ht/~gheartsfield/nostr-rs-relay/15
This updates the database schema to support hiding events. In this
case, we are hiding older metadata updates when an author provides an
updated event.
Fixes https://todo.sr.ht/~gheartsfield/nostr-rs-relay/11
The `authors` field is sufficient to represent all queries that
`author` could have been used in. See
https://github.com/fiatjaf/nostr/issues/34 for the discussion leading
to this removal.
This fixes a race condition where a publisher might send an event, and
immediately after issue a subscription for the same event ID. Prior
to this change, that event would have been published on the broadcast
channel (and ignored by our publisher, because they had not yet issued
the subscription), but not yet committed to the database. Their
subscription would trigger a database query which would return zero
results. Therefore, they would never see the event they published.
The noscl tool is one client that would suffer from this.
Now, all events are broadcast only after they exist in the database,
so a late subscription will always return the event.
