nostr 0.5.0 → 0.7.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 168cbde3fb029345d4fa10043eead7c194a57fe3ee23c12b76bbaf79b1bdc71d
-  data.tar.gz: ff1a1837e897a8c0ad233a61ed4526fe3e4087c04474e54778a00a0d4313e361
+  metadata.gz: 707a302ca79f44bd669a84dc9086c5934bc6f753a78d90989f4d3619db5ed997
+  data.tar.gz: 81a83ff089c864ac5c77bc7d4b26a23755ff2573ee013f68137a79ed9351f140
 SHA512:
-  metadata.gz: e5549507ded84026a2295c3914324e8c74aff3c1ae80322db3cd449e7f65c3475186e9daaa76f7a22241e33b6759c2073da5a31a910a2082c8e49a99081dc5bf
-  data.tar.gz: 19f69ed10ae3ba42113992541912bb18a4aa3ad8239b582b996e7c7845c4624c4a9ee73d800f51fbd883d2bdd9ea603eeb807ade147bcfc22db7183c1db30ce6
+  metadata.gz: 69bf9a378add76760a6955967787602e1bf6e913f22c1194fa9b8d3dc661270b038f26010bb8181378b7d21586b6d5195fe12754007551baa78531b3e4663e16
+  data.tar.gz: a49b8eb1acc9978a1f95be74783253d44807078fc97af2255239067c77125a7a31661514e7196f27d18c76d57805c293c54d5cc0c9427cd792c1f0e65349a796

data/.adr-dir

@@ -0,0 +1 @@
+adr

data/.rubocop.yml

@@ -5,9 +5,11 @@ require:
   - rubocop-rspec
 
 AllCops:
-  TargetRubyVersion: 3.2
+  TargetRubyVersion: 3.3
   DisplayCopNames: true
   NewCops: enable
+  Exclude:
+    - docs/**/*
 
 # ----------------------- Gemspec -----------------------
 

data/.rubocop_todo.yml

@@ -9,7 +9,7 @@
 # Offense count: 2
 # Configuration parameters: AllowedMethods, AllowedPatterns, IgnoredMethods, CountRepeatedAttributes.
 Metrics/AbcSize:
-  Max: 23
+  Max: 24
 
 # Offense count: 2
 # Configuration parameters: CountComments, CountAsOne, ExcludedMethods, AllowedMethods, AllowedPatterns, IgnoredMethods.

data/.tool-versions

@@ -1,2 +1,2 @@
-ruby 3.2.2
-bun 1.0.11
+ruby 3.3.0
+bun 1.1.3

data/CHANGELOG.md

@@ -4,13 +4,73 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.1.1/)
 and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).
 
+## [0.7.0] 2024-04-13
+
+### Added
+
+- Added the `Nostr::Client::Logger` class to log connection events, messages sent and received, errors, and connection
+closures.
+- Added the `Nostr::Client::ColorLogger` class to log events in color using ANSI escape codes.
+- Added the `Nostr::Client::PlainLogger` class to log events without color coding.
+- Added Architecture Decision Records (ADRs) to document the decision process for logging functionality.
+- Added a new common use case document for logging and debugging.
+
+### Changed
+
+- Updated the `Nostr::Client` class to use the `ColorLogger` by default for logging client interactions with relays.
+- Updated the `Nostr::Client#connect` method to emit a `:send` event when sending a message.
+- Updated the `Nostr::Client#on` method to pass the `relay` parameter to the `:connect` event handler.
+- Updated bun to version `1.1.3` (was `1.0.30`).
+- Updated the gem `json` to version `2.7` (was `2.6`).
+- Updated the gem `mermaid` to version `10.9` (was `10.6`).
+- Updated the gem `rubocop-rspec` to version `2.29` (was `2.27`).
+- Updated the gem `steep` to version `1.7.dev3` (was `1.6`).
+- Updated the gem `vitepress` to version `1.1` (was `1.0.0-rc.25`).
+- Updated the gem `vitepress-plugin-mermaid` to version `2.0.16` (was `2.0.15`).
+- Updated the error message in `Nostr::InvalidSignatureTypeError` to provide more detail.
+
+### Fixed
+
+Fixed a type-checking issue in `Nostr::Event#verify_signature` by removing a workaround after the steep gem author,
+[@soutaro](https://github.com/soutaro) resolved [the problem I reported](https://github.com/soutaro/steep/issues/1079).
+
+## [0.6.0] 2024-03-15
+
+### Added
+
+- Added Architecture Decision Records (ADRs) to document architectural decisions
+- Added the `Signature` class to fix the primitive obsession with signatures and to make it easier to work with them
+- Added `valid_sig?` and `check_sig!` to the `Crypto` class to verify whether an event's signature is valid
+- Added `sign_message` to the `Crypto` class to sign a message
+- Added `verify_signature?` to the `Event` class to verify whether an event's signature is valid
+- Added `#to_ary` to the `KeyPair` class to enable keypair destructuring
+- Added RBS types for `schnorr`
+
+### Changed
+
+- Updated the required Ruby version to `3.3.0` (was `3.2.0`)
+- Updated the gem `dotenv` to version `3.1` (was `2.8`)
+- Updated the gem `bip-schnorr` to version `0.7` (was `0.6`)
+- Updated the gem `overcommit` to version `0.63` (was `0.59`)
+- Updated the gem `rbs` to version `3.4` (was `3.3`)
+- Updated the gem `rspec` to version `3.13` (was `3.12`)
+- Updated the gem `rspec-rubocop` to version `2.27` (was `2.25`)
+- Updated the gem `rubocop` to version `1.62` (was `1.57`)
+
+### Fixed
+
+- Fixed a typo in the README (`generate_keypair` -> `generate_key_pair`)
+- Fixed a typo in the YARD documentation of `Nostr::Key#initialize` (`ValidationError` -> `KeyValidationError`)
+- Fixed YARD example rendering issues in `InvalidKeyFormatError#initialize`, `InvalidKeyLengthError#initialize`,
+`InvalidKeyTypeError#initialize`, `Event#initialize`, `EncryptedDirectMessage#initialize` and `Filter#to_h`
+
 ## [0.5.0] 2023-11-20
 
 ### Added
 
 - Added relay message type enums `Nostr::RelayMessageType`
 - Compliance with [NIP-19](https://github.com/nostr-protocol/nips/blob/master/19.md) - bech32-formatted strings
-- `Nostr::PrivateKey` and `Nostr::PublicKey` to represent private and public keys, respectively
+- Added `Nostr::PrivateKey` and `Nostr::PublicKey` to represent private and public keys, respectively
 - Added a validation of private and public keys
 - Added an ability to convert keys to and from Bech32 format
 - Added RBS types for `faye-websocket` and `bech32`
@@ -82,6 +142,8 @@ principles of immutability and was a major source of internal complexity as I ne
 
 - Initial release
 
+[0.7.0]: https://github.com/wilsonsilva/nostr/compare/v0.6.0...v0.7.0
+[0.6.0]: https://github.com/wilsonsilva/nostr/compare/v0.5.0...v0.6.0
 [0.5.0]: https://github.com/wilsonsilva/nostr/compare/v0.4.0...v0.5.0
 [0.4.0]: https://github.com/wilsonsilva/nostr/compare/v0.3.0...v0.4.0
 [0.3.0]: https://github.com/wilsonsilva/nostr/compare/v0.2.0...v0.3.0

data/README.md

@@ -1,6 +1,7 @@
 # Nostr
 
 [![Gem Version](https://badge.fury.io/rb/nostr.svg)](https://badge.fury.io/rb/nostr)
+![Build](https://github.com/wilsonsilva/nostr/actions/workflows/main.yml/badge.svg)
 [![Maintainability](https://api.codeclimate.com/v1/badges/c7633eb2c89eb95ee7f2/maintainability)](https://codeclimate.com/github/wilsonsilva/nostr/maintainability)
 [![Test Coverage](https://api.codeclimate.com/v1/badges/c7633eb2c89eb95ee7f2/test_coverage)](https://codeclimate.com/github/wilsonsilva/nostr/test_coverage)
 
@@ -63,7 +64,7 @@ keypair = keygen.get_key_pair_from_private_key(
 
 # c) Or create a new keypair
 keygen = Nostr::Keygen.new
-keypair = keygen.generate_keypair
+keypair = keygen.generate_key_pair
 
 # Create a user with the keypair
 user = Nostr::User.new(keypair: keypair)
@@ -79,7 +80,7 @@ relay = Nostr::Relay.new(url: 'wss://nostr.wine', name: 'Wine')
 client.connect(relay)
 
 # Listen asynchronously for the connect event
-client.on :connect do
+client.on :connect do |relay|
   # Send the event to the Relay
   client.publish(text_note_event)
 
@@ -117,6 +118,9 @@ end
 client.on :close do |code, reason|
   # You may attempt to reconnect to the relay here
 end
+
+# This line keeps the background client from exiting immediately.
+gets
 ```
 
 ## 📚 Documentation

data/adr/0001-record-architecture-decisions.md

@@ -0,0 +1,19 @@
+# 1. Record architecture decisions
+
+Date: 2024-03-13
+
+## Status
+
+Accepted
+
+## Context
+
+We need to record the architectural decisions made on this project.
+
+## Decision
+
+We will use Architecture Decision Records, as [described by Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).
+
+## Consequences
+
+See Michael Nygard's article, linked above. For a lightweight ADR toolset, see Nat Pryce's [adr-tools](https://github.com/npryce/adr-tools).

data/adr/0002-introduction-of-signature-class.md

@@ -0,0 +1,27 @@
+# 2. introduction-of-signature-class
+
+Date: 2024-03-14
+
+## Status
+
+Accepted
+
+## Context
+
+I noticed significant overuse of primitive strings for signatures, which led to widespread and repetitive validation logic, increasing the potential for errors and making the system harder to manage and maintain.
+
+## Decision
+
+I introduced the Nostr::Signature class, choosing to subclass String to leverage string-like behavior while embedding specific validation rules for signatures. This move was aimed at streamlining validation, ensuring consistency, and maintaining the usability of strings.
+
+## Consequences
+
+### Positive
+
+- This design choice has made the codebase cleaner and more robust, reducing the chances of errors related to signature handling. It ensures that all signature instances are valid at creation, leveraging the familiarity and flexibility of string operations without sacrificing the integrity of the data. Moreover, it sets a strong foundation for extending signature-related functionality in the future.
+
+### Negative
+
+- __Performance Concerns:__ Subclassing String might introduce slight performance overheads due to the additional validation logic executed upon instantiation of a Signature object.
+- __Integration Challenges:__ Integrating this class into existing systems where strings were used indiscriminately for signatures requires careful refactoring to ensure compatibility. There's also the potential for issues when passing Nostr::Signature objects to libraries or APIs expecting plain strings without the additional constraints.
+- __Learning Curve:__ For new team members or contributors, understanding the necessity and functionality of the Nostr::Signature class adds to the learning curve, potentially slowing down initial development efforts as they familiarize themselves with the custom implementation.

data/adr/0003-logging-methods-vs-logger-class.md

@@ -0,0 +1,122 @@
+# 3. Logging methods vs logger class
+
+Date: 2024-03-19
+
+## Status
+
+Accepted
+
+## Context
+
+I'm deciding between integrating logging directly into the main class or creating a dedicated logger class.
+
+### Option 1: Logging methods
+
+The first approach weaves logging actions into the operational code, resulting in a tight coupling of functionality and
+logging. Classes should be open for extension but closed for modification, and this strategy violates that principle.
+
+```ruby
+class Client
+  def connect(relay)
+    execute_within_an_em_thread do
+      client = build_websocket_client(relay.url)
+      parent_to_child_channel.subscribe do |msg|
+        client.send(msg)
+        emit(:send, msg)
+        log_send(msg) # <------ new code
+      end
+
+      client.on :open do
+        child_to_parent_channel.push(type: :open, relay:)
+        log_connection_opened(relay) # <------ new code
+      end
+
+      client.on :message do |event|
+        child_to_parent_channel.push(type: :message, data: event.data)
+        log_message_received(event.data) # <------ new code
+      end
+
+      client.on :error do |event|
+        child_to_parent_channel.push(type: :error, message: event.message)
+        log_error(event.message) # <------ new code
+      end
+
+      client.on :close do |event|
+        child_to_parent_channel.push(type: :close, code: event.code, reason: event.reason)
+        log_connection_closed(event.code, event.reason) # <------ new code
+      end
+    end
+
+    # ------ new code below ------
+
+    def log_send(msg)
+      logger.info("Message sent: #{msg}")
+    end
+
+    def log_connection_opened(relay)
+      logger.info("Connection opened to #{relay.url}")
+    end
+
+    def log_message_received(data)
+      logger.info("Message received: #{data}")
+    end
+
+    def log_error(message)
+      logger.error("Error: #{message}")
+    end
+
+    def log_connection_closed(code, reason)
+      logger.info("Connection closed with code: #{code}, reason: #{reason}")
+    end
+  end
+end
+```
+
+### Option 2: Logger class
+
+The second strategy separates logging into its own class, promoting cleaner code and adherence to the Single
+Responsibility Principle. Client already exposes events that can be tapped into, so the logger class can listen to these
+events and log accordingly.
+
+```ruby
+class ClientLogger
+  def attach_to(client)
+    logger_instance = self
+
+    client.on(:connect) { |relay| logger_instance.on_connect(relay) }
+    client.on(:message) { |message| logger_instance.on_message(message) }
+    client.on(:send) { |message| logger_instance.on_send(message) }
+    client.on(:error) { |message| logger_instance.on_error(message) }
+    client.on(:close) { |code, reason| logger_instance.on_close(code, reason) }
+  end
+
+  def on_connect(relay); end
+  def on_message(message); end
+  def on_send(message); end
+  def on_error(message); end
+  def on_close(code, reason); end
+end
+
+client = Nostr::Client.new
+logger = Nostr::ClientLogger.new
+logger.attach_to(client)
+```
+
+This approach decouples logging from the main class, making it easier to maintain and extend the logging system without
+affecting the core logic.
+
+## Decision
+
+I've chosen the dedicated logger class route. This choice is driven by a desire for extensibility in the logging system.
+With a separate logger, I can easily modify logging behavior—like changing formats, adjusting verbosity levels,
+switching colors, or altering output destinations (files, networks, etc.) — without needing to rewrite any of the main
+operational code.
+
+## Consequences
+
+Adopting a dedicated logger class offers greater flexibility and simplifies maintenance, making it straightforward to
+adjust how and what I log independently of the core logic. This separation of concerns means that any future changes
+to logging preferences or requirements can be implemented quickly and without risk to the main class's functionality.
+However, it's important to manage the integration carefully to avoid introducing complexity, such as handling
+dependencies and ensuring seamless communication between the main operations and the logging system.
+

data/adr/0004-default-logging-activation.md

@@ -0,0 +1,66 @@
+# 3. Default Logging Activation
+
+Date: 2024-03-19
+
+## Status
+
+Accepted
+
+## Context
+
+Logging provides visibility into the gem's behavior and helps to diagnose issues. The decision centered on whether
+to enable logging by default or require manual activation.
+
+### Option 1: On-demand Logging
+
+```ruby
+client = Nostr::Client.new
+logger = Nostr::ClientLogger.new
+logger.attach_to(client)
+```
+
+#### Advantages:
+
+- Offers users flexibility and control over logging.
+- Conserves resources by logging only when needed.
+
+#### Disadvantages:
+
+- Potential to miss critical logs if not enabled.
+- Requires users to read and understand documentation to enable logging.
+- Requires users to manually activate and configure logging.
+
+### Option 2: Automatic Logging
+
+```ruby
+class Client
+  def initialize(logger: ClientLogger.new)
+    @logger = logger
+    logger&.attach_to(self)
+  end
+end
+
+client = Nostr::Client.new
+```
+
+#### Advantages:
+
+- Ensures comprehensive logging without user intervention.
+- Simplifies debugging and monitoring.
+- Balances logging detail with performance impact.
+
+#### Disadvantages:
+
+- Needs additional steps to disable logging.
+
+## Decision
+
+Logging will be enabled by default. Users can disable logging by passing a `nil` logger to the client:
+
+```ruby
+client = Nostr::Client.new(logger: nil)
+```
+
+## Consequences
+
+Enabling logging by default favors ease of use and simplifies the developer's experience.

data/adr/0005-logger-types.md

@@ -0,0 +1,32 @@
+# 3. Logger Types
+
+Date: 2024-04-01
+
+## Status
+
+Accepted
+
+## Context
+
+In developing the `Nostr::Client` logging mechanism, I identified a need to cater to multiple development environments
+and developer preferences. The consideration was whether to implement a singular logger type or to introduce
+multiple, specialized loggers. The alternatives were:
+
+- A single `ClientLogger` providing a one-size-fits-all solution.
+- Multiple logger types:
+  - `Nostr::Client::Logger`: The base class for logging, providing core functionalities.
+  - `Nostr::Client::ColorLogger`: An extension of the base logger, introducing color-coded outputs for enhanced readability in environments that support ANSI colors.
+  - `Nostr::Client::PlainLogger`: A variation that produces logs without color coding, suitable for environments lacking color support or for users preferring plain text.
+
+## Decision
+
+I decided to implement the latter option: three specific kinds of loggers (`Nostr::Client::Logger`,
+`Nostr::Client::ColorLogger`, and `Nostr::Client::PlainLogger`). This approach is intended to offer flexibility and
+cater to the varied preferences and requirements of our users, recognizing the diverse environments in which our
+library might be used.
+
+## Consequences
+
+- `Developer Choice`: Developers gain the ability to select the one that best matches their needs and environmental constraints, thereby enhancing the library's usability.
+- `Code Complexity`: While introducing multiple logger types increases the library's code complexity, this is offset by the significant gain in flexibility and user satisfaction.
+- `Broad Compatibility`: This decision ensures that the logging mechanism is adaptable to a wide range of operational environments, enhancing the library's overall robustness and accessibility.

data/docs/.vitepress/config.mjs

@@ -78,7 +78,10 @@ export default defineConfig(withMermaid({
         text: 'Common use cases',
         collapsed: false,
         items: [
+          { text: 'Logging and debugging', link: '/common-use-cases/logging-and-debugging' },
           { text: 'Bech32 enc/decoding (NIP-19)', link: '/common-use-cases/bech32-encoding-and-decoding-(NIP-19)' },
+          { text: 'Signing/verifying messages', link: '/common-use-cases/signing-and-verifying-messages' },
+          { text: 'Signing/verifying events', link: '/common-use-cases/signing-and-verifying-events' },
         ]
       },
       {

data/docs/common-use-cases/logging-and-debugging.md

@@ -0,0 +1,60 @@
+# Logging and debugging
+
+The `Nostr::Client` class provides built-in logging functionality to help you debug and monitor client interactions with
+relays. By default, the client uses the `ColorLogger`, which logs events in color. However, you can customize the
+logging behavior or disable it entirely.
+
+## Disabling logging
+
+To instantiate a client without any logging, simply pass `logger: nil` when creating the client instance:
+
+```ruby
+client = Nostr::Client.new(logger: nil)
+```
+
+This will disable all logging for the client.
+
+## Formatting the logging
+
+The `Nostr::Client::Logger` class is the base class for logging functionality. It defines the following methods for
+logging different events:
+
+- `on_connect(relay)`: Logs when the client connects to a relay.
+- `on_message(message)`: Logs a message received from the relay.
+- `on_send(message)`: Logs a message sent to the relay.
+- `on_error(message)`: Logs an error message.
+- `on_close(code, reason)`: Logs when the connection with a relay is closed.
+
+You can create your own logger by subclassing `Nostr::Client::Logger` and overriding these methods to customize the
+logging format.
+
+The `Nostr::Client::ColorLogger` is a built-in logger that logs events in color. It uses ANSI escape codes to add color
+to the log output. Here's an example of how the ColorLogger formats the log messages:
+
+- Connection: `"\u001b[32m\u001b[1mConnected to the relay\u001b[22m #{relay.name} (#{relay.url})\u001b[0m"`
+- Message received: `"\u001b[32m\u001b[1m◄-\u001b[0m #{message}"`
+- Message sent: `"\u001b[32m\u001b[1m-►\u001b[0m #{message}"`
+- Error: `"\u001b[31m\u001b[1mError: \u001b[22m#{message}\u001b[0m"`
+- Connection closed: `"\u001b[31m\u001b[1mConnection closed: \u001b[22m#{reason} (##{code})\u001b[0m"`
+
+## Plain text logging
+
+If you prefer plain text logging without colors, you can use the `Nostr::Client::PlainLogger`. This logger formats the
+log messages in a simple, readable format without any ANSI escape codes.
+
+To use the `PlainLogger`, pass it as the `logger` option when creating the client instance:
+
+```ruby
+client = Nostr::Client.new(logger: Nostr::Client::PlainLogger.new)
+```
+
+The `PlainLogger` formats the log messages as follows:
+
+- Connection: `"Connected to the relay #{relay.name} (#{relay.url})"`
+- Message received: `"◄- #{message}"`
+- Message sent: `"-► #{message}"`
+- Error: `"Error: #{message}"`
+- Connection closed: `"Connection closed: #{reason} (##{code})"`
+
+By using the appropriate logger or creating your own custom logger, you can effectively debug and monitor your Nostr
+client's interactions with relays.

data/docs/common-use-cases/signing-and-verifying-events.md

@@ -0,0 +1,50 @@
+# Signing and verifying events
+
+Signing an event in Nostr proves it was sent by the owner of a specific private key.
+
+## Signing an event
+
+To sign an event, use the private key associated with the event's creator. Here's how to sign a message using a
+predefined keypair:
+
+```ruby{14}
+require 'nostr'
+
+private_key = Nostr::PrivateKey.new('67dea2ed018072d675f5415ecfaed7d2597555e202d85b3d65ea4e58d2d92ffa'),
+public_key = Nostr::PublicKey.new('7e7e9c42a91bfef19fa929e5fda1b72e0ebc1a4c1141673e2794234d86addf4e'),
+
+event = Nostr::Event.new(
+  pubkey: public_key.to_s,
+  kind: Nostr::EventKind::TEXT_NOTE,
+  content: 'We did it with security, now we’re going to do it with the economy.',
+  created_at: Time.now.to_i,
+)
+
+# Sign the event with the private key
+event.sign(private_key)
+
+puts "Event ID: #{event.id}"
+puts "Event Signature: #{event.sig}"
+```
+
+## Verifying an event's signature
+
+To verify an event, you must ensure the event's signature is valid. This indicates the event was created by the owner
+of the corresponding public key.
+
+When the event was signed with the private key corresponding to the public key, the `verify_signature` method will
+return `true`.
+
+```ruby
+event.verify_signature # => true
+```
+
+And when the event was not signed with the private key corresponding to the public key, the `verify_signature` method
+will return `false`.
+
+An event without an `id`, `pubkey`, `sig` is considered invalid and will return `false` when calling `verify_signature`.
+
+```ruby
+other_public_key = Nostr::PublicKey.new('10be96d345ed58d923a734560680f1adfd2b1006c28ac93b8e1b032a9a32c6e9')
+event.verify_signature # => false
+```

data/docs/common-use-cases/signing-and-verifying-messages.md

@@ -0,0 +1,43 @@
+# Signing and verifying messages
+
+Signing a message in Nostr proves it was sent by the owner of a specific private key.
+
+## Signing a message
+
+To sign a message, you'll need a private key. Here's how to sign a message using a predefined keypair:
+
+```ruby{9}
+require 'nostr'
+
+private_key = Nostr::PrivateKey.new('67dea2ed018072d675f5415ecfaed7d2597555e202d85b3d65ea4e58d2d92ffa'),
+public_key = Nostr::PublicKey.new('7e7e9c42a91bfef19fa929e5fda1b72e0ebc1a4c1141673e2794234d86addf4e'),
+
+message = 'We did it with security, now we’re going to do it with the economy.' # The message you want to sign
+
+crypto = Nostr::Crypto.new
+signature = crypto.sign_message(message, private_key)
+signature # => "d7a0aac1fadcddf1aa2949bedfcdf25ce0c1604e648e55d31431fdacbff8e8256f7c2166d98292f80bc5f79105a0b6e8a89236a47d97cf5d0e7cc1ebf34dea5c"
+```
+
+## Verifying a signature
+
+To verify a signature, you need the original message, the public key of the signer, and the signature.
+
+```ruby
+crypto.valid_sig?(message, public_key, signature) # => true
+crypto.check_sig!(message, public_key, signature) # => true
+```
+
+When the message was not signed with the private key corresponding to the public key, the `valid_sig?` method will return `false`.
+
+```ruby
+other_public_key = Nostr::PublicKey.new('10be96d345ed58d923a734560680f1adfd2b1006c28ac93b8e1b032a9a32c6e9')
+crypto.valid_sig?(message, public_key, signature) # => false
+```
+
+And when the message was not signed with the private key corresponding to the public key, the `check_sig!` method will raise an error.
+
+```ruby
+other_public_key = Nostr::PublicKey.new('10be96d345ed58d923a734560680f1adfd2b1006c28ac93b8e1b032a9a32c6e9')
+crypto.check_sig!(message, other_public_key, signature) # => Schnorr::InvalidSignatureError: signature verification failed
+```

data/docs/core/client.md

@@ -28,7 +28,7 @@ The `:connect` event is fired when a connection with a WebSocket is opened. You
 client = Nostr::Client.new
 relay = Nostr::Relay.new(url: 'wss://relay.damus.io', name: 'Damus')
 
-client.on :connect do
+client.on :connect do |relay|
   # When this block executes, you're connected to the relay
 end
 

data/docs/getting-started/overview.md

@@ -35,6 +35,7 @@ classDiagram
         serialize()
         to_h()
         sign(private_key)
+        verify_signature()
     }
     class Subscription {
         id
@@ -110,7 +111,7 @@ keypair = keygen.get_key_pair_from_private_key(
 
 # c) Or create a new keypair
 keygen = Nostr::Keygen.new
-keypair = keygen.generate_keypair
+keypair = keygen.generate_key_pair
 
 # Create a user with the keypair
 user = Nostr::User.new(keypair: keypair)
@@ -164,6 +165,9 @@ end
 client.on :close do |code, reason|
   # You may attempt to reconnect to the relay here
 end
+
+# This line keeps the background client from exiting immediately.
+gets
 ```
 
 Beyond what's covered here, the Nostr protocol and this gem boast a wealth of additional functionalities. For an

data/docs/index.md

@@ -39,6 +39,4 @@ features:
   - title: Fully typed
     details: All code is typed with <a href="https://rubygems.org/gems/rbs" target="_blank">RBS</a> with the help of <a href="https://rubygems.org/gems/typeprof" target="_blank">TypeProf</a>. Type correctness is enforced by <a href="https://rubygems.org/gems/steep" target="_blank">Steep</a>.
     icon: ✅
-
 ---
-

data/docs/package.json

@@ -5,8 +5,8 @@
     "docs:preview": "vitepress preview"
   },
   "devDependencies": {
-    "mermaid": "^10.6.1",
-    "vitepress": "^1.0.0-rc.25",
-    "vitepress-plugin-mermaid": "^2.0.15"
+    "mermaid": "^10.9.0",
+    "vitepress": "^1.1.0",
+    "vitepress-plugin-mermaid": "^2.0.16"
   }
 }