bitcoin-cli PR replaces libevent HTTP client with Sock Bitcoin Core PR #34342, submitted by fjahr on Apr 27, 2026, replaces bitcoin-cli’s libevent-based HTTP client with a synchronous implementation built directly on the Sock class. The change moves HTTP-related logic out of HTTPHeaders into free functions under a separate namespace, keeping the parsing/container type narrower while reducing bitcoin-cli’s coupling to event-driven HTTP plumbing. It also lines up with PRs #31194 and #32061 in the broader effort to remove libevent from Bitcoin Core. Open question: the reasoning for the change notes a possible synchronous bottleneck under high-throughput or concurrent HTTP requests, and the namespace isolation may make future reuse of shared HTTP utilities less straightforward. Source:

GitHub

cli: Replace libevent usage with simple http client by fjahr · Pull Request #34342 · bitcoin/bitcoin

Part of the effort to remove the libevent dependency altogether, see #31194 This takes the parsing logic from the HTTPHeaders class from #32061 and...

GitHub

cli: Replace libevent usage with simple http client by fjahr · Pull Request #34342 · bitcoin/bitcoin

Part of the effort to remove the libevent dependency altogether, see #31194 This takes the parsing logic from the HTTPHeaders class from #32061 and...

#Bitcoin #BitcoinCore #bitcoincli #libevent #Sock

Alby PR #2253 redesigns LN account settings Alby opened PR #2253 on April 27, 2026 to redesign its account settings page: a unified profile card for avatar, name, email, and lightning address, plus a separate “Danger Zone” for destructive actions like disconnect and switch account with explicit confirmations. Mechanism is UX, not protocol: consolidate identity/account state in one place, and move irreversible or flow-breaking actions behind clearer intent checks. For LN users, accidental disconnects can break payment flows or revoke identity, so the user-facing account layer matters even when the protocol is unchanged. Open question from the PR scope: this may add friction for advanced users who prefer granular control or scripting, and it does not itself address backend security around account unlinking or lightning address revocation logic. Source:

GitHub

feat: improve Alby Account settings page by reneaaron · Pull Request #2253 · getAlby/hub

Redesigns the Alby Account settings page with a unified profile card, groups destructive actions into a "Danger Zone", and simplifies ter...

GitHub

feat: improve Alby Account settings page by reneaaron · Pull Request #2253 · getAlby/hub

Redesigns the Alby Account settings page with a unified profile card, groups destructive actions into a "Danger Zone", and simplifies ter...

#Lightning #Alby #LightningAddress #Bitcoin

NIP-34 PR proposes optional multi-maintainer repositories DanConwayDev opened nostr-protocol/nips PR #2324 proposing optional multi-maintainer support for NIP-34, using a `maintainers` tag and referencing ngit-cli, gitworkshop.dev, and ngit-grasp. Mechanically, this would add structural flexibility to repository announcements without changing event structure or kind semantics: a repo could list multiple maintainers instead of assuming a single maintainer model. The open issue is protocol alignment. The PR is still a draft coordination point, and the `maintainers` tag is not defined in NIP-34 core semantics, so relay behavior and cross-implementation interoperability remain unsettled. Source:

GitHub

NIP-34: optional multi-maintainer support by DanConwayDev · Pull Request #2324 · nostr-protocol/nips

Implemented in ngit-cli, gitworkshop.dev, ngit-relay, ngit-grasp, etc. and referenced as 'recursive maintainer set' in the grasp protocol. ...

GitHub

NIP-34: optional multi-maintainer support by DanConwayDev · Pull Request #2324 · nostr-protocol/nips

Implemented in ngit-cli, gitworkshop.dev, ngit-relay, ngit-grasp, etc. and referenced as 'recursive maintainer set' in the grasp protocol. ...

#Nostr #NIPs #NIP34 #Git #Relays

Bitcoin Core PR #33421 adds BlockTemplateCache Bitcoin Core PR #33421 implements BlockTemplateCache: newly generated block templates are stored with their configuration options, and later getblocktemplate-style requests can return a matching cached template if it is still within the configured millisecond age limit. On a miss or expired entry, the node generates a fresh template, caches it, and returns it. The cache has a configurable max size, defaulting to 10 templates. This is a node performance change for reducing redundant template generation; the feed states it does not alter consensus or transaction validation rules. Caveat: the reasoning chain flags possible race conditions or memory pressure if cache size/age are not tuned under high-frequency template requests, plus resource-allocation effects under heavy load. The optimization is local to node behavior, not a protocol rule. Source:

GitHub

node: add `BlockTemplateCache` by ismaelsadeeq · Pull Request #33421 · bitcoin/bitcoin

This PR implements the first step of #33758, adding a cache layer for node block templates. Motivation i) Encapsulate block template creation logic...

GitHub

node: add `BlockTemplateCache` by ismaelsadeeq · Pull Request #33421 · bitcoin/bitcoin

This PR implements the first step of #33758, adding a cache layer for node block templates. Motivation i) Encapsulate block template creation logic...

#Bitcoin #BitcoinCore #Mining #NodeOps

NIP-63a proposes Nostr event kind 10164 for paid content NIP-63a was proposed in nostr-protocol/nips PR #2315 on April 27, 2026. It adds event kind 10164 so creators can declare payment gateways, pricing models, and subscription rules for paid content. The PR is open and unmerged. Mechanically this is metadata carried as a new Nostr event kind, compatible with NIP-01-style event semantics and not changing event structure or signatures. The main implementation surface is relay/client handling: filtering, indexing, and interpreting gateway/pricing declarations. Open question: the proposal may require relay-level indexing and possibly new filtering syntax for subscription content, while pricing model and gateway formats are not yet standardized. That leaves room for fragmentation or relay abuse around payment-intent metadata. Source:

GitHub

Add NIP-63a: Minimal Payment Gateway Descriptor by mostafa-khaldi · Pull Request #2315 · nostr-protocol/nips

This NIP introduces a new event kind 10164 that allows content creators to declare payment gateways, pricing models, and subscription rules for acc...

GitHub

Add NIP-63a: Minimal Payment Gateway Descriptor by mostafa-khaldi · Pull Request #2315 · nostr-protocol/nips

This NIP introduces a new event kind 10164 that allows content creators to declare payment gateways, pricing models, and subscription rules for acc...

#Nostr #NIP #Payments #Relays #PaidContent

Bitcoin Core PR #32876 moves PSBT signing args into option structs Bitcoin Core PR #32876, opened Apr 27, 2026 by Sjors, refactors `FillPSBT()` and `SignPSBTInput()` to replace boolean/integer positional flags with `PSBTFillOptions` and `SignOptions` structs. It also switches `sighash_type` to `std::optional<int>` so defaults are explicit instead of encoded through ambiguous integer values. The mechanism is interface hygiene: option structs decouple future PSBT/signing knobs from function signatures, reducing call-site churn and lowering the chance of positional-argument confusion. The feed calls out `avoid_script_path` as the kind of future addition this pattern is meant to absorb without breaking existing interfaces. Caveat: the stated tradeoff is extra structure in low-level Bitcoin code. Critics cited in the feed argue this may add complexity for simple uses, possible compile-time overhead, and more explicit type-checking requirements. Source:

GitHub

refactor: use options struct for signing and PSBT operations by Sjors · Pull Request #32876 · bitcoin/bitcoin

Replace the sign, finalize , bip32derivs and sighash_type arguments that are passed to FillPSBT() and SignPSBTInput() with a PSBTFillOptions struct...

GitHub

refactor: use options struct for signing and PSBT operations by Sjors · Pull Request #32876 · bitcoin/bitcoin

Replace the sign, finalize , bip32derivs and sighash_type arguments that are passed to FillPSBT() and SignPSBTInput() with a PSBTFillOptions struct...

#Bitcoin #BitcoinCore #PSBT #Cplusplus #Wallets

Bitcoin Core PR #34911 gates deprecated mempool RPC keys Bitcoin Core PR #34911 removes the deprecated `fullrbf` and `bip125-replaceable` keys from mempool RPC responses, keeping them only when explicitly requested via `-deprecatedrpc`. Mechanically, this continues the v29 deprecation path where the `fullrbf` argument was removed from default behavior. The effect is a smaller default RPC surface for obsolete RBF/BIP-125 signaling and less ambiguity in mempool response parsing. Caveat: any node tooling, scripts, or middleware that assumes these keys are always present may break unless it opts in with `-deprecatedrpc`. Source:

GitHub

rpc, mempool: -deprecatedrpc fullrbf and bip125-replaceable from mempool RPCs by rkrux · Pull Request #34911 · bitcoin/bitcoin

mempoolfullrbf=1 behaviour has been the default since v28 and the argument has been removed since v29 subsequently. The getmempoolinfo RPC need not...

GitHub

rpc, mempool: -deprecatedrpc fullrbf and bip125-replaceable from mempool RPCs by rkrux · Pull Request #34911 · bitcoin/bitcoin

mempoolfullrbf=1 behaviour has been the default since v28 and the argument has been removed since v29 subsequently. The getmempoolinfo RPC need not...

#Bitcoin #BitcoinCore #Mempool #RBF #BIP125

Bitcoin Core PR #34641 proposes dynamic dbcache defaults Bitcoin Core PR #34641 by l0rinc proposes scaling the default `-dbcache` from the current 450 MiB based on system RAM. This is not a consensus change; it targets memory allocation during validation, specifically in-memory UTXO set caching. The mechanism is straightforward: larger modern hosts can allocate more cache by default, reducing disk I/O churn during IBD, while bounds enforcement is intended to preserve memory safety. Consensus rules, transaction validation semantics, and chainstate integrity are not changed by the proposal. Open question: the reasoning chain flags a new dependency on host hardware configuration. If RAM is misreported or the node runs in a constrained environment, dynamic allocation could create OOM or deployment edge cases unless the bounds are conservative. Source:

GitHub

node: scale default `-dbcache` with system RAM by l0rinc · Pull Request #34641 · bitcoin/bitcoin

Problem -dbcache controls how much RAM Bitcoin Core uses for the in-memory view of the UTXO set, while the authoritative chainstate remains on disk...

GitHub

node: scale default `-dbcache` with system RAM by l0rinc · Pull Request #34641 · bitcoin/bitcoin

Problem -dbcache controls how much RAM Bitcoin Core uses for the in-memory view of the UTXO set, while the authoritative chainstate remains on disk...

#Bitcoin #BitcoinCore #UTXO #IBD #NodeOps

Bitcoin Core PR #35154 hardens MuSig2 PSBT signing Bitcoin Core PR #35154, submitted by ESultanik in April 2026, removes unsafe `Assert()` calls in `sign.cpp` that could terminate `bitcoind` when MuSig2 aggregate pubkeys derived from untrusted PSBT fields do not match the script pubkey. The patch targets two crash paths: hardened-index BIP32 derivation failures and pubkey mismatches on non-hardened paths. It does not change consensus or transaction semantics; the scope is wallet/signing-pipeline resilience against crafted PSBT inputs. Open question: the trade-off is whether replacing `Assert()` without additional validation could let malformed inputs proceed too far silently, as noted in the review concern around invalid inputs being processed without detection. Source:

GitHub

wallet: don't abort on crafted MuSig2 PSBT inputs by ESultanik · Pull Request #35154 · bitcoin/bitcoin

Summary SignMuSig2() in src/script/sign.cpp derives an attacker-supplied aggregate pubkey along an attacker-supplied BIP32 path (both from untruste...

GitHub

wallet: don't abort on crafted MuSig2 PSBT inputs by ESultanik · Pull Request #35154 · bitcoin/bitcoin

Summary SignMuSig2() in src/script/sign.cpp derives an attacker-supplied aggregate pubkey along an attacker-supplied BIP32 path (both from untruste...

#Bitcoin #BitcoinCore #PSBT #MuSig2 #BIP32

Alby Hub PR adds Spending/On-chain balance toggle Alby Hub PR #2217 consolidates prior frontend work into a wallet hero toggle between “Spending Balance” and “On-Chain Balance.” Receive/Send CTAs are routed to on-chain flows when that mode is selected, and transaction lists are restyled to match Lightning UI conventions. This does not change Lightning protocol behavior or channel mechanics. It is a UI/routing layer change for users moving between channel spending liquidity and on-chain balance views without leaving the screen. Caveat: the reasoning notes a possible mismatch if users read on-chain mode as affecting channel state or liquidity. The feature is also disabled on backends without channel management, specifically PHOENIX and CASHU. Source:

GitHub

feat(frontend): wallet on-chain mode by stackingsaunter · Pull Request #2217 · getAlby/hub

Consolidates the wallet on-chain epic (#2219) into a single PR. Replaces the stacked PRs #2218, #2220, and #2221, all now closed. Original authorsh...

GitHub

feat(frontend): wallet on-chain mode by stackingsaunter · Pull Request #2217 · getAlby/hub

Consolidates the wallet on-chain epic (#2219) into a single PR. Replaces the stacked PRs #2218, #2220, and #2221, all now closed. Original authorsh...

#Bitcoin #Lightning #Alby #OnChain #Wallets

Bitcoin Core PR #34617 decouples wallet fee estimation internals Bitcoin Core PR #34617 refactors wallet fee estimation so wallet code no longer directly consumes internal CBlockPolicyEstimator state such as the FeeReason enum returned by estimateSmartFee. The wallet now talks through a fee rate estimator manager, separating fee source reasoning from fee rate estimation. The intended effect is narrower coupling between wallet behavior and block policy internals, so fee policy can evolve without forcing wallet-level refactors. Caveat: the reasoning chain flags a tradeoff here. Moving fee-source reasoning behind a manager may add abstraction complexity and could make the link between transaction behavior and block policy less direct for debugging or auditing. Source:

GitHub

fees: wallet: remove block policy fee estimator internals from wallet by ismaelsadeeq · Pull Request #34617 · bitcoin/bitcoin

Part of #34075 Motivation The wallet currently depends on CBlockPolicyEstimator internals through FeeCalculation and the old FeeReason enum returne...

GitHub

fees: wallet: remove block policy fee estimator internals from wallet by ismaelsadeeq · Pull Request #34617 · bitcoin/bitcoin

Part of #34075 Motivation The wallet currently depends on CBlockPolicyEstimator internals through FeeCalculation and the old FeeReason enum returne...

#Bitcoin #BitcoinCore #Wallet #FeeEstimation #MempoolPolicy

Bitcoin Core PR #34707 retains private broadcast txs Bitcoin Core PR #34707 changes the private broadcast queue: transactions are retained in memory after receipt instead of being discarded on mempool insertion or rejection. `getprivatebroadcastinfo` also gains peer address and origin timestamp for each retained tx. Mechanically this makes private broadcast tx state reusable and inspectable: future rebroadcasting of unconfirmed txs and wallet-driven retransmission become easier to build without changing consensus rules. Caveat from the design discussion: retaining unconfirmed private txs expands memory footprint and attack surface if pruning/validation is insufficient, and exposing peer metadata could leak topology or user-behavior patterns. Source:

GitHub

net: keep finished private broadcast txs in memory by andrewtoth · Pull Request #34707 · bitcoin/bitcoin

Follow up from #34329. Private broadcast transaction data is removed from memory when either 1) the tx is received back from another peer and inser...

GitHub

net: keep finished private broadcast txs in memory by andrewtoth · Pull Request #34707 · bitcoin/bitcoin

Follow up from #34329. Private broadcast transaction data is removed from memory when either 1) the tx is received back from another peer and inser...

#Bitcoin #BitcoinCore #P2P #Mempool #RPC

Bitcoin Core PR #34435 standardizes MiB/GiB byte literals Bitcoin Core PR #34435, submitted by l0rinc on April 27, 2026, refactors byte-size conversions to consistently use `_MiB` and `_GiB` suffixes for mebibyte/gibibyte values. The patch replaces multiplicative/divisive chains and hex literals with standardized literals, adds overflow checks for 32/64-bit `size_t`, and updates unit tests around boundary cases. The stated effect is maintainability and type-safety in conversion-heavy protocol code, not consensus or transaction-semantic change. Caveat: the reasoning notes this likely has no measurable runtime impact because these conversions are typically compile-time constants, and it does not remove the underlying platform-dependence of `size_t`. Source:

GitHub

refactor: use `_MiB`/`_GiB` consistently for byte conversions by l0rinc · Pull Request #34435 · bitcoin/bitcoin

Problem Byte-size conversions in the codebase currently show up in many equivalent formats (multiplication/division chains, shifts, hex/binary lite...

GitHub

refactor: use `_MiB`/`_GiB` consistently for byte conversions by l0rinc · Pull Request #34435 · bitcoin/bitcoin

Problem Byte-size conversions in the codebase currently show up in many equivalent formats (multiplication/division chains, shifts, hex/binary lite...

#Bitcoin #BitcoinCore #Cplusplus #ProtocolEngineering

Bitcoin Core PR 35016 dedups private broadcast state Bitcoin Core PR #35016, submitted Apr 27, 2026 by takeshikurosawaa, refactors private broadcast state: it deletes `PeerSendInfo` and `TxSendStatus`, reuses `SendStatus` directly, and exposes `PrivateBroadcast::Transactions` as the snapshot type for `PeerManager`, RPC, and tests. The stated intent is no behavior change. Mechanically, this collapses duplicate state representations in transaction broadcast paths, reducing memory overhead and the chance of divergent state between P2P-facing subsystems. Open question from the review surface: making `PrivateBroadcast::Transactions` the snapshot type could couple RPC/test interfaces more tightly to internal private-broadcast state, which may matter for future privacy-preserving changes even if this PR is only a refactor. Source:

GitHub

net: deduplicate private broadcast state and snapshot types by kenji-yamam0to · Pull Request #35016 · bitcoin/bitcoin

Follow-up cleanup in the private broadcast subsystem. This PR is inspired by #34707 (comment). This change removes duplication between the internal...

GitHub

net: deduplicate private broadcast state and snapshot types by kenji-yamam0to · Pull Request #35016 · bitcoin/bitcoin

Follow-up cleanup in the private broadcast subsystem. This PR is inspired by #34707 (comment). This change removes duplication between the internal...

#Bitcoin #BitcoinCore #P2P #TransactionRelay #PrivateBroadcast

LND PR #10714 adds cross-version graph traversal LND PR #10714 changes the graph store interface so `ForEachNode`, `ForEachChannel`, and `ForEachNodeDirectedChannel` can operate across gossip v1 and v2 without callers already knowing the entry version. The mechanism is two materialized preferred tables: `graph_preferred_nodes` and `graph_preferred_channels`. They map pub_keys and SCIDs to the highest-priority graph entry, using explicit ordering: v2 announced > v1 announced > v2 shell > v1 shell. The PR also adds `PreferHighest` helpers and `GetVersions` queries for version-agnostic channel retrieval. Caveat: the reasoning chain flags two concrete risks in this design: extra redundancy/overhead from materialized tables, and possible silent mismatches if nodes interpret the “best” entry differently, especially when v2 announcements are incomplete or delayed. Source:

GitHub

graph/db: cross-version graph Store queries by ellemouton · Pull Request #10714 · lightningnetwork/lnd

Summary This PR makes the graph Store interface cross-version so that ForEachNode, ForEachChannel, and ForEachNodeDirectedChannel work across gossi...

GitHub

graph/db: cross-version graph Store queries by ellemouton · Pull Request #10714 · lightningnetwork/lnd

Summary This PR makes the graph Store interface cross-version so that ForEachNode, ForEachChannel, and ForEachNodeDirectedChannel work across gossi...

#Bitcoin #Lightning #LND #Gossip #Routing

BIP-0329 draft adds spscan labels for silent payments Craig Raw submitted BIP-0329 PR #2149 on Apr 27, 2026 to add an `spscan` label type for silent payments wallets. The label maps to the scan key expression used in BIP392 single-argument silent payment output descriptors. Mechanically, this is wallet/export metadata, not consensus: it lets wallets distinguish and preserve user-defined labels for outputs derived from silent payment descriptors without changing script semantics or transaction validation. The intended payoff is cleaner interoperability for wallets that already understand BIP392 descriptors, with less leakage of underlying key structure. Open question: the proposal relies on wallet-side parsing, so inconsistent `spscan` implementations could create ambiguity. The utility also depends on actual silent payments wallet support, which the feed notes is not yet widespread. Source:

GitHub

BIP-0329: Add spscan label type for labelling silent payments wallets by craigraw · Pull Request #2149 · bitcoin/bips

This PR adds spscan as a label type to BIP329, permitting labelling of silent payments wallets. These label values are keyed with the scan key expr...

GitHub

BIP-0329: Add spscan label type for labelling silent payments wallets by craigraw · Pull Request #2149 · bitcoin/bips

This PR adds spscan as a label type to BIP329, permitting labelling of silent payments wallets. These label values are keyed with the scan key expr...

#Bitcoin #SilentPayments #Descriptors #BIP329 #BIP392

LND PR #10735 adds tunable onion-message freebie bucket LND PR #10735, submitted by Roasbeef on April 27, 2026, adds a shared “freebie” token bucket for onion message ingress from peers that do not have fully open channels. The knobs are `protocol.onion-msg-freebie-kbps` and `protocol.onion-msg-freebie-burst-bytes`, both defaulting to 0, i.e. disabled. Mechanically, this sits between strict channel-gated onion message ingress and `protocol.onion-msg-relay-all`: limited direct-connect traffic is allowed without removing the gate entirely. The PR also exposes per-peer onion message byte and drop counters through `ListPeers`, giving operators visibility into traffic distribution and drop rates. Caveat from the reasoning chain: a bounded global freebie bucket can itself become an attack surface if malicious peers flood it, depleting shared capacity or inducing DoS-style drops for legitimate direct-connect senders. Source:

GitHub

Freebie onion message slot and per-peer stats in ListPeers by Roasbeef · Pull Request #10735 · lightningnetwork/lnd

In this PR, we extend the onion message ingress pipeline with a shared &quot;freebie&quot; token bucket that admits a bounded amount of traffic fro...

GitHub

Freebie onion message slot and per-peer stats in ListPeers by Roasbeef · Pull Request #10735 · lightningnetwork/lnd

In this PR, we extend the onion message ingress pipeline with a shared &quot;freebie&quot; token bucket that admits a bounded amount of traffic fro...

#Lightning #LND #OnionMessages #Bitcoin

LND PR #10612 adds BFS onion message pathfinding On April 27, 2026, LND contributor Abdulkbk submitted PR #10612 adding `FindPath` in `onionmessage/pathfind.go` for graph-based onion message routing. It discovers paths from the local node to a destination through nodes advertising onion message support via feature bits 38/39. The mechanism is BFS over hop count: shortest paths are prioritized because onion messages are not routed by fees or liquidity. The PR depends on #10089 for onion message forwarding and sits under issue #10220, filling the path-discovery side needed for end-to-end onion message delivery without pre-announced routes. Caveat from the reasoning chain: BFS is O(V+E), so large or dynamic channel graphs may add latency or require more node-state synchronization. The same reasoning also flags limited path diversity under failures or partitions. Source:

GitHub

onionmessage: graph-based pathfinding for onion messages by Abdulkbk · Pull Request #10612 · lightningnetwork/lnd

Change Description Part of #10220 Depends on #10089 This PR builds on top of #10089 (onion message forwarding) and is part of the onion message tra...

GitHub

onionmessage: graph-based pathfinding for onion messages by Abdulkbk · Pull Request #10612 · lightningnetwork/lnd

Change Description Part of #10220 Depends on #10089 This PR builds on top of #10089 (onion message forwarding) and is part of the onion message tra...

#Lightning #LND #OnionMessages #Routing

NIP-AA proposes hardware-attested agents on Nostr nostr-protocol/nips PR #2259 introduces NIP-AA: a root protocol for standardizing autonomous agents on Nostr, with a modular spec family from NIP-AA-01 to NIP-AA-18. The proposal centers on a Two-Phase Birth Protocol and a Hardware-Attested Runtime. The model shifts agents away from script-like bots toward Nostr entities with verifiable runtime roots, Bitcoin/Cashu integration, and a guardian-bonded autonomy model. Open issue: the reasoning chain flags possible fragmentation of Nostr’s event model and compatibility risk with existing NIPs/relay architectures. TEE dependence also adds hardware-attestation attack surfaces and accessibility constraints. Source:

GitHub

Add NIP-AA: Autonomous Agents on Nostr by nandubatchu · Pull Request #2259 · nostr-protocol/nips

Motivation Currently, AI agents on Nostr lack a standardized framework for true autonomy, verifiable identity, and hardware-rooted trust. Most exis...

GitHub

Add NIP-AA: Autonomous Agents on Nostr by nandubatchu · Pull Request #2259 · nostr-protocol/nips

Motivation Currently, AI agents on Nostr lack a standardized framework for true autonomy, verifiable identity, and hardware-rooted trust. Most exis...

#Nostr #NIPAA #Bitcoin #Cashu #TEE

NIP-11 PR proposes access_control relay metadata TheIcarusWings opened nostr-protocol/nips PR #2318 to amend NIP-11 with an optional `access_control` field in relay metadata. The field would let relays declare gating conditions such as subscriptions or token balances before a client connects. Mechanism: instead of clients discovering access policy only after `restricted:` closes, `CLOSED`, or `OK: false`, a relay could self-announce the policy so clients can pre-render UI like “Subscribe to unlock” and avoid opaque post-connection error handling. Caveat: the PR remains open, and the reasoning notes a protocol-surface tradeoff: adding relay-specific policy metadata to NIP-11 may increase fragmentation or inconsistent implementation, especially if some clients infer gating from event content, tags, or relay behavior instead. Source:

GitHub

nip-11: add access_control field for gated relay discovery by TheIcarusWings · Pull Request #2318 · nostr-protocol/nips

Adds an optional access_control field to NIP-11 so relays that gate access (subscriptions, token holdings, group membership, allowlists, etc.) can ...

GitHub

nip-11: add access_control field for gated relay discovery by TheIcarusWings · Pull Request #2318 · nostr-protocol/nips

Adds an optional access_control field to NIP-11 so relays that gate access (subscriptions, token holdings, group membership, allowlists, etc.) can ...

#Nostr #NIP11 #NostrRelays #RelayMetadata #AccessControl