Crate nostr_types

source
Expand description

This crate provides types for nostr protocol handling.

Structs§

  • The count results
  • Conditions of delegation
  • This is an encrypted private key (the string inside is the bech32 ncryptsec string)
  • Iterator over well known EventKinds
  • The main event type
  • The main event type
  • The main event type
  • Fee
  • NIP-92/94 File Metadata
  • Filter which specify what events a client is looking for
  • Filter which specify what events a client is looking for
  • HyperLogLog approximate counting mechanism
  • An event identifier, constructed as a SHA256 hash of the event fields according to NIP-01
  • An event identifier, constructed as a SHA256 hash of the event fields according to NIP-01, as a hex string
  • Signer with a local private key (and public key)
  • Metadata about a user
  • Metadata about a user
  • Bitcoin amount measured in millisatoshi
  • An ‘naddr’: data to address a possibly parameterized replaceable event (d-tag, kind, author, and relays)
  • An ‘nevent’: event id along with some relays in which that event may be found.
  • The content of a webserver’s /.well-known/nostr.json file used in NIP-05 and NIP-35 This allows lookup and verification of a nostr user via a user@domain style identifier.
  • A Nostr URL (starting with ‘nostr:’)
  • This is a response from a zapper lnurl
  • Data used to construct an event
  • Data used to construct an event
  • Data used to construct an event
  • This is a private key which is to be kept secret and is used to prove identity
  • A person’s profile on nostr which consists of the data needed in order to follow someone.
  • This is a public key, which identifies an actor (usually a person) and is shared.
  • This is a public key, which identifies an actor (usually a person) and is shared, as a hex string
  • Relay fees
  • Relay information document as described in NIP-11, supplied by a relay
  • Relay information document as described in NIP-11, supplied by a relay
  • Relay limitations
  • Relay limitations
  • A relay list, indicating usage for each relay, which can be used to represent the data found in a kind 10002 RelayListMetadata event.
  • A canonical URL representing just a relay’s origin (without path/query/fragment or username/password)
  • Relay retention
  • A Url validated as a nostr relay url in canonical form We don’t serialize/deserialize these directly, see UncheckedUrl for that
  • The ways that a user uses a Relay
  • A Rumor is an Event without a signature
  • A Rumor is an Event without a signature
  • A Rumor is an Event without a signature
  • A sequence of content segments
  • A Schnorr signature that signs an Event, taken on the Event Id field
  • A Schnorr signature that signs an Event, taken on the Event Id field, as a hex string
  • A list of relays with SimpleRelayUsage
  • When and how to use a Relay
  • This is like Range<usize>, except we impl offset() on it This is like linkify::Span, except we impl offset() on it and don’t need the as_str() or kind() functions.
  • A random client-chosen string used to refer to a subscription
  • A tag on an Event
  • A string that is supposed to represent a URL but which might be invalid
  • An integer count of the number of seconds from 1st January 1970. This does not count any of the leap seconds that have occurred, it simply presumes UTC never had leap seconds; yet it is well known and well understood.
  • A String representing a valid URL with an authority present including an Internet based host.
  • An x-only public key, used for verification of Taproot signatures and serialized according to BIP-340.
  • Data about a Zap
  • Data about a Zap

Enums§

  • A message from a client to a relay
  • Content Encryption Algorithm
  • A segment of content
  • Errors that can occur in the nostr-proto crate
  • Delegation information for an Event
  • A kind of Event
  • Either an EventKind or a range (a vector of length 2 with start and end)
  • A reference to another event, either by Id (often coming from an ‘e’ tag), or by NAddr (often coming from an ‘a’ tag).
  • All states that your identity can be in
  • This indicates the security of the key by keeping track of whether the secret key material was handled carefully. If the secret is exposed in any way, or leaked and the memory not zeroed, the key security drops to Weak.
  • A bech32 sequence representing a nostr object (or set of objects)
  • Relay Usage
  • A message from a relay to a client
  • A way that a user uses a Relay
  • A tag on an Event
  • A tag on an Event
  • The reason why a relay issued an OK or CLOSED message

Traits§

Functions§

Type Aliases§

  • The main event type
  • Fee
  • The main filter type
  • Metadata about a user
  • The content of a webserver’s /.well-known/nostr.json file used in NIP-05 and NIP-35 This allows lookup and verification of a nostr user via a user@domain style identifier.
  • Data used to construct an event
  • Relay fees
  • Relay information document as described in NIP-11, supplied by a relay
  • Relay limitations
  • Relay retention
  • A Rumor is an Event without a signature
  • A tag on an Event
  • Data about a Zap