Rebase onto the next upstream release (nostr-sdk relay layer, lnbits/nostrclient#70) #4

New issue

Open

opened 2026-09-12 12:43:02 +00:00 by padreug · 0 comments

padreug commented

2026-09-12 12:43:02 +00:00

Owner

Why

Upstream lnbits/nostrclient replaced the websocket-client relay layer with nostr-sdk in ae674ef (2026-07-13, PR #70, "fix: use nostr-sdk more without breaking changes — is much more stable"). Our fork point is the commit right before it (801ce44, upstream v1.2.0), so we still run the old WebSocketApp + thread-per-relay implementation plus our own reconnect patches on top of it.

The old layer is the plausible home of lnbits/nwcprovider#53 (wallets time out after a transient upstream handshake failure until LNbits is restarted; closed there as not-planned because the defect is on the nostrclient side). We have not hit it on four84 yet, but the journal already shows the relay layer taking a minute-plus to recover from boot-time DNS failures.

Decision

Wait for an upstream release/tag that includes ae674ef, then rebase onto that tag — not onto the bare commit. Rationale: the SDK rewrite touched relay_manager.py (+403), relay.py, key.py, event.py, helpers.py, tasks.py, views_api.py; picking an untagged mid-branch state gives us no stable base to name in v<upstream>-aio.N, and upstream may still adjust it before tagging.

Fork commits to reconcile at rebase time

Run git log v1.2.0..main for the authoritative list; the ones that interact with #70:

Reconnect patches (ea9fc18 "reconnect on on_close", 49f206e "exponential delay for reconnect") — these patch the old Relay/RelayManager. Expect to drop them: the SDK layer owns reconnection. Verify the SDK's behaviour on relay drop before deleting.
OK reply to client-published events (PR #3, v1.2.0-aio.2) — message_pool.py gained CommandResultMessage; client.py a callback_command_results_func; tasks.py the pump; router.py the PendingPublish tracking. Upstream #70 did not touch message_pool.py or router.py, but it rewrote relay_manager.py, which is what feeds the pool. Check that relay OK messages still reach MessagePool.add_message under the SDK layer, otherwise clients get OK false on timeout for every publish. tests/test_router_ok.py covers the router half; add a pool-feed test if the SDK path differs.
Anything else in git log v1.2.0..main that is not a version/catalog bump.

Checklist

Upstream tag containing ae674ef exists: ______
git fetch upstream && git rebase <tag> on a branch; resolve the three areas above
Upstream review per workspace rule: gh pr list -R lnbits/nostrclient --state all for anything else that overlaps
Run tests/ (see workspace CLAUDE.md for the bohm venv workaround)
Smoke on dev LNbits: public endpoint handshake, REQ/EOSE, EVENT → OK, NWC round-trip with nwcprovider (nwcsim3.py-style: provider subscribed to its own kind-23195 replies)
Tag v<upstream>-aio.1, add catalog entry (keep 1.2.0-aio.2)
Update docs/upstream-candidates.md if the OK-reply work is worth proposing upstream

aiolabs/nostrclient#3 — OK reply (merged, v1.2.0-aio.2)
aiolabs/nostrrelay#6 — deliver events to every matching subscription (merged, v1.1.0-aio.3); the actual cause of the Amethyst NWC timeouts, unrelated to #70 but found in the same investigation
lnbits/nwcprovider#53

🤖 Generated with Claude Code

https://claude.ai/code/session_013Tbyw6FwjhEJg3gHfPHxWt

## Why Upstream `lnbits/nostrclient` replaced the websocket-client relay layer with **nostr-sdk** in `ae674ef` (2026-07-13, PR #70, "fix: use nostr-sdk more without breaking changes — is much more stable"). Our fork point is the commit right before it (`801ce44`, upstream v1.2.0), so we still run the old `WebSocketApp` + thread-per-relay implementation plus our own reconnect patches on top of it. The old layer is the plausible home of [lnbits/nwcprovider#53](https://github.com/lnbits/nwcprovider/issues/53) (wallets time out after a transient upstream handshake failure until LNbits is restarted; closed there as not-planned because the defect is on the nostrclient side). We have not hit it on four84 yet, but the journal already shows the relay layer taking a minute-plus to recover from boot-time DNS failures. ## Decision **Wait for an upstream release/tag that includes `ae674ef`, then rebase onto that tag** — not onto the bare commit. Rationale: the SDK rewrite touched `relay_manager.py` (+403), `relay.py`, `key.py`, `event.py`, `helpers.py`, `tasks.py`, `views_api.py`; picking an untagged mid-branch state gives us no stable base to name in `v<upstream>-aio.N`, and upstream may still adjust it before tagging. ## Fork commits to reconcile at rebase time Run `git log v1.2.0..main` for the authoritative list; the ones that interact with #70: - **Reconnect patches** (`ea9fc18` "reconnect on on_close", `49f206e` "exponential delay for reconnect") — these patch the old `Relay`/`RelayManager`. Expect to **drop** them: the SDK layer owns reconnection. Verify the SDK's behaviour on relay drop before deleting. - **OK reply to client-published events** (PR #3, `v1.2.0-aio.2`) — `message_pool.py` gained `CommandResultMessage`; `client.py` a `callback_command_results_func`; `tasks.py` the pump; `router.py` the `PendingPublish` tracking. Upstream #70 did **not** touch `message_pool.py` or `router.py`, but it rewrote `relay_manager.py`, which is what feeds the pool. Check that relay `OK` messages still reach `MessagePool.add_message` under the SDK layer, otherwise clients get `OK false` on timeout for every publish. `tests/test_router_ok.py` covers the router half; add a pool-feed test if the SDK path differs. - Anything else in `git log v1.2.0..main` that is not a version/catalog bump. ## Checklist - [ ] Upstream tag containing `ae674ef` exists: ______ - [ ] `git fetch upstream && git rebase <tag>` on a branch; resolve the three areas above - [ ] Upstream review per workspace rule: `gh pr list -R lnbits/nostrclient --state all` for anything else that overlaps - [ ] Run `tests/` (see workspace CLAUDE.md for the bohm venv workaround) - [ ] Smoke on dev LNbits: public endpoint handshake, REQ/EOSE, EVENT → OK, NWC round-trip with nwcprovider (`nwcsim3.py`-style: provider subscribed to its own kind-23195 replies) - [ ] Tag `v<upstream>-aio.1`, add catalog entry (keep `1.2.0-aio.2`) - [ ] Update `docs/upstream-candidates.md` if the OK-reply work is worth proposing upstream ## Related - aiolabs/nostrclient#3 — OK reply (merged, `v1.2.0-aio.2`) - aiolabs/nostrrelay#6 — deliver events to every matching subscription (merged, `v1.1.0-aio.3`); the actual cause of the Amethyst NWC timeouts, unrelated to #70 but found in the same investigation - lnbits/nwcprovider#53 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_013Tbyw6FwjhEJg3gHfPHxWt

padreug referenced this issue

2026-09-13 14:07:52 +00:00

feat: answer REQ with CLOSED when no relay is configured #5

padreug referenced this issue

2026-10-09 17:11:54 +00:00

NostrRouter buffers are ClassVars: unbounded growth and isolation-by-luck between connections #8

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

aiolabs/nostrclient#4

No description provided.

Rows
Columns