Skip to content

v2.0.8

Latest

Choose a tag to compare

@github-actions github-actions released this 22 Aug 20:46
· 2 commits to main since this release

Fixed

  • Relay payloads are now delivered only to the listener whose subscription they name. NostrRelayClient.dispatchMessage() broadcast every inbound frame to every listener on the connection, and nothing downstream read the subscription id the frame carried — so on a connection with two concurrent REQs, one subscription's EOSE fired the other's EOSE handler and ended its query early with whatever had arrived so far. Observed in the field as a gift-wrap query returning 0, 2 or 6 events at random from a relay holding exactly 5. EVENT, EOSE and CLOSED are now routed by subscription id for listeners registered through subscribe(ReqMessage, …); connection-scoped frames (NOTICE, OK, AUTH) and listeners registered with raw JSON still see everything, so no existing caller loses a frame it receives today.
  • NIP-44 no longer depends on a JCE provider being registered. EncryptedPayloads asked for Cipher.getInstance("ChaCha20") with an IvParameterSpec, which only BouncyCastle's provider accepts — SunJCE requires a ChaCha20ParameterSpec and throws. The provider happened to be registered as a side effect of Schnorr.generatePrivateKey(), so encryption worked for callers who generated a key and failed for callers who loaded one, and could not work on Android at all (adding a provider named "BC" is a no-op there; the platform owns the name). Both cipher call sites now use BouncyCastle's lightweight ChaCha7539Engine, which needs no provider lookup. Closes #537.

Changed

  • Schnorr.generatePrivateKey() no longer calls Security.addProvider(new BouncyCastleProvider()). It uses BouncyCastle's lightweight ECKeyPairGenerator instead, so generating a key no longer mutates process-wide JCE state. Callers that relied on nostr-java registering the provider for them must now register it themselves.

Added

  • NIP-44 v2 is verified against the specification's own test vectors (nip44.vectors.json from the reference implementation), and the whole suite runs with the BouncyCastle provider de-registered so the defect above cannot come back unnoticed.

Published to Maven Central and to the internal Maven repo (maven.398ja.xyz/releases).