Weave Code
Laravel Nostr Laravel Package
revolution/laravel-nostr
Laravel package for working with Nostr: generate and manage keypairs, create and sign events, publish to relays, verify signatures, and handle NIP-05 identifiers. Provides facades and configuration for adding decentralized social features to Laravel apps.
At a glance
Frequently asked questions about Laravel Nostr
- What is revolution/laravel-nostr used for?
- It is a Laravel package for working with Nostr primitives: generating and managing keypairs, creating and signing events, publishing events to relays, verifying signatures, and handling NIP-05 identifiers. It ships as a conventional Laravel package with a service provider, facade, and publishable configuration, so you can add decentralized social features without building the protocol plumbing from scratch. Treat it as a thin integration layer rather than a full relay client.
- How do I install revolution/laravel-nostr in a Laravel app?
- Install it with Composer using composer require revolution/laravel-nostr, then publish the package configuration and confirm the service provider and facade aliases are registered if they are not auto-discovered. Before deploying, review composer.json for PHP and Laravel version constraints and for any secp256k1 extension requirement, because signing can use a native extension or a pure-PHP fallback. Pin an exact version rather than a caret range given the package's maturity.
- Can laravel-nostr handle long-lived Nostr relay subscriptions in a standard Laravel FPM app?
- Not naturally. Nostr relies on persistent WebSocket relay subscriptions, while Laravel's default request/response lifecycle has no place to hold those connections. Use the package for stateless primitives such as keypair generation, event signing, one-shot publishing, and verification, and move long-lived REQ subscriptions into an Octane or Swoole worker or a dedicated daemon or queue-driven ingestion service. Design that listener as a separate deployable concern from day one.
- Which Laravel and PHP versions does revolution/laravel-nostr support?
- The technical evaluation positions it for Laravel 10+ applications, but you should verify the actual constraints in the package's composer.json before adoption. Check the required PHP version and whether secp256k1 signing needs a native extension or falls back to pure PHP, then confirm that combination against your base container image. Because the package is early-stage, pin an exact version instead of relying on a caret range.
- Is revolution/laravel-nostr safe for managing private keys in production?
- The package can generate and manage keypairs, but the evaluation notes it does not appear to prescribe key-storage guidance, so nsec custody remains your responsibility. A defect in key handling can cause irreversible identity compromise, and Nostr offers no practical key rotation for an established identity. Keep private keys in a dedicated secrets manager or HSM-backed flow, never in application config or version control, and wrap the package behind your own key-management boundary.
- Does laravel-nostr verify inbound event signatures by default?
- Signature verification is one of the package's advertised capabilities, but the evaluation explicitly flags whether it is applied by default or opt-in as a question to settle in source. Do not assume inbound events are verified just because the API exposes a verify method. Add a known-vector test for signing and verification and enforce verification at your adapter boundary before trusting any event.
- What is the relay connection model in revolution/laravel-nostr?
- The evaluation says the connection model must be confirmed in code: it may be blocking per call, pooled, or event-loop driven. For fire-and-forget publishing from web requests, a blocking call may be acceptable if wrapped in a queue job with timeouts. For subscriptions or high-throughput publishing, require a pooled or event-loop-driven path and test it under load before committing.
- Is revolution/laravel-nostr production-ready?
- Treat it as high technical risk. The evaluation cites three stars, zero dependents, a very low score, a single-maintainer bus factor, and a July 2025 release that will lag evolving NIPs. Code quality may be fine, but there is little peer review or production evidence. Mitigate with an anti-corruption layer, an exact version pin, and a plan to vendor or fork the source from the first commit.
- What are alternatives to revolution/laravel-nostr?
- The main fallbacks are raw nostr-php, a Node or nostr-tools sidecar, or your own internal fork of this package. The evaluation recommends defining an internal NostrClient interface and implementing it with a thin adapter over the chosen library so no facade calls or package types leak into domain code. That keeps a vendor swap to a few days instead of an existential rewrite.
- How should I test revolution/laravel-nostr signing and verification?
- Start with a timeboxed spike, then add known-vector tests for Schnorr signing and signature verification so you can detect protocol or dependency regressions. Test your adapter against a local or testnet relay, including failure cases such as malformed events, bad signatures, and relay timeouts. Also load-test the publish path in the same container image you plan to deploy, because secp256k1 performance differs between native and pure-PHP implementations.
Weaver
How can I help you explore Laravel packages today?