Nostr Php Laravel Package

Technical Evaluation

Architecture fit swentel/nostr-php is a framework-agnostic protocol helper library, not a Laravel package: no service provider, no config publishing, no facade, no Eloquent integration. That is the right shape for us — it keeps the dependency in the "vendor plumbing" layer rather than dictating application architecture — but it means the Laravel-facing surface is ours to build. What we get is the undifferentiated heavy lifting of the protocol: event construction and serialization, key handling, filter objects, relay message envelopes, and NIP helpers (NIP-19 bech32 encoding and NIP-05 identifier handling are the ones worth validating first). What we do not get: a connection pool, relay health management, subscription lifecycle, persistence, retries, or backpressure. Those are the actual product decisions, and they stay with us.

The central architectural tension is transport. Nostr is WebSocket-and-long-lived-subscription shaped; PHP-FPM is request-scoped and worker-blocking. The package's client will be usable outbound per-request (publish an event from a queued job), but inbound real-time ingestion requires a long-running process — Laravel Octane/Swoole, a supervised Artisan daemon, or a sidecar. A TPM should treat that as a platform decision, not a library decision, because it constrains hosting (rules out naive shared hosting and complicates Vapor/serverless).

Integration feasibility High for the outbound path, moderate for inbound. Publishing is a clean fit: Event → sign → EventMessage → dispatch across a relay set in a queued job, with per-relay success tracking. Inbound is where the design work lands: a listener daemon that opens subscriptions, verifies signatures, dedupes on event id, and pushes to the queue. Verification cost is the sleeper issue — Nostr requires BIP-340 Schnorr signatures, and pure-PHP Schnorr verification is expensive relative to a C extension. If the library depends on ext-secp256k1 with the schnorrsig module, that is a hard deployment prerequisite (container base image, CI, local dev). If it has a pure-PHP fallback, throughput becomes the constraint instead. Confirm which before committing.

Also verify: exact NIP coverage versus our roadmap (NIP-01 core, NIP-04/17 encrypted DMs, NIP-09 deletion, NIP-42 relay auth, NIP-50 search), whether the client supports multiple concurrent relay connections or one at a time, PHP version floor, and whether any transitive dependency is unmaintained (older PHP Nostr libraries leaned on simplito/elliptic-php, which is effectively abandoned).

Technical risk

• Key custody (highest). The library will happily sign with a raw private key. Production needs envelope encryption at rest, a KMS/HSM or Vault-backed signer, key rotation policy, and an audit trail on every signing operation. A leaked Nostr key is unrecoverable — no issuer to revoke with.
• Maintainer concentration. ~70 stars and a likely single maintainer is a bus-factor-1 dependency on a protocol still in motion. MIT license and small surface area mitigate this (fork-and-own is realistic; the library is a few thousand lines of value objects), but plan for it.
• Protocol drift. NIPs are informal and evolve; relay implementations diverge on limits, auth, and rate limiting. Behavior is not guaranteed by the library and must be proven per relay.
• Version skew / release cadence. The 2026-02-03 release suggests active maintenance, but there is no semver-backed support window or changelog SLA to rely on. Pin the version and read diffs.

Key questions for the engineering spike

1. Which signing backend is used, and what is the measured sign/verify throughput per core?
2. Does the client support N relays concurrently, or must we shard subscriptions across processes?
3. What NIPs are implemented today, and which of those are tested against a real relay in the repo's suite?
4. Is there any relay reconnect/backoff logic, or is that entirely ours?
5. Do we self-host relays (strfry, nostr-rs-relay) or depend on public ones — and what does that imply for availability and content moderation?

Integration Approach

Stack fit Wrap, don't scatter. Introduce a thin internal package — e.g. app/Domains/Nostr or a private Composer package — that owns the dependency and exposes a narrow, Laravel-idiomatic API: a NostrServiceProvider binding a RelayPool and Signer interface, a config/nostr.php for relay URLs, timeouts, retry policy, and key source, and domain events (NostrEventReceived, NostrPublishFailed) so application code never imports Nostr\* directly. That isolation is what makes the fork-and-own contingency cheap and what lets us swap in a sidecar later without touching feature code.

Migration path Greenfield integration — no legacy migration, so sequence by risk rather than by system:

Compatibility Laravel 10/11/12 and PHP 8.1+ are plausible but unverified — confirm the floor against our oldest supported app. The absence of framework coupling means no conflict risk with other packages, which is a genuine plus. Container image must carry ext-secp256k1 if required; add a startup assertion so a missing extension fails loudly at boot rather than at first signature.

Sequencing Do not let inbound ingestion onto the roadmap before the long-running-worker hosting decision is made and paid for. Phase 1 delivers user-visible value with none of that commitment and produces the relay-reliability data needed to justify Phase 2.

Operational Impact

Maintenance Ongoing cost is concentrated in our wrapper, not the library. Budget for: tracking NIP changes quarterly, maintaining a relay conformance test suite (relay behavior drifts silently), and owning the fork if upstream stalls. Estimate roughly 0.1–0.2 FTE steady state for a Phase 1–2 footprint; the library itself is small enough that a fork is a weekend, not a quarter.

Support Community-only: GitHub issues, no SLA, no commercial backing. Internal runbooks must cover relay outages, signature verification failures, key access problems, and worker wedges. Pin to an exact version and treat upgrades as reviewed changes with a conformance run, not composer update.

Scaling Outbound scales trivially — it is queue depth and relay rate limits. Watch the fan-out multiplier: N relays × M events means N×M outbound connections and N×M failure surfaces, so cap the relay set and track per-relay health as a first-class metric. Inbound scales with verification CPU, not I/O; on pure-PHP Schnorr, expect verification to be the ceiling and plan horizontal sharding by subscription. Long-running workers need memory ceilings, restart policy, and per-subscription backpressure — an unbounded subscription set is a memory leak with a schedule.

Failure modes to instrument

• Partial publish: relay A accepts, relay B rejects — surface per-relay status, never a single boolean.
• Relay timeout / silent close / rate-limit throttling — exponential backoff with jitter and a circuit breaker per relay.
• Duplicate and replayed events — idempotent writes keyed on event id.
• Malicious payloads — enforce size limits before parsing, never trust kind or content, verify every signature before persistence.
• Key compromise — detection is near-impossible post-hoc; the mitigation is custody design, plus a documented rotation and disclosure path.
• Worker wedge from a blocking socket call with no timeout — make timeouts mandatory config, not defaults.

Ramp-up A mid-level PHP developer is productive on the outbound path in 1–2 days; the library's value objects are self-explanatory. The protocol is the learning curve, not the code: relays, event kinds, NIPs, key handling, and the difference between "published" and "propagated" take 1–2 weeks to internalize. Budget a half-day knowledge transfer on key custody specifically — that is where a well-meaning implementation becomes an incident.

Verdict Adopt for outbound and identity helpers; treat inbound ingestion as a platform project with the library as one input. The 7.7 score and 0.8 opportunity signal read correctly: the gap it fills is real and the code is fit for purpose, but low adoption and single-maintainer concentration mean we isolate it behind our own interface, pin it, and keep the fork option warm.