Commit Graph

3 Commits

Author SHA1 Message Date
Kgothatso Ngako
c8cbd936f1 docs: record where the sync's safety net is, and where it is not
Two updates after the test pass.

long-running-sync.md gains a section naming what each test file pins and, more
usefully, the three things they cannot reach: NostrSocketClientImpl's reconnect
loop and ordered inbound (exercised only through their extracted arithmetic —
covering them wants a fake WebSocketSession), everything downstream of
saveNostrEvent (Room-backed, and there is no sqlite driver on the JVM test
classpath), and the app on a device. The manual checks stay the manual checks.

It also records that the tests were verified by mutation rather than by passing,
so the next person knows the assertions were confirmed to bite.

dead-code.md's line references are refreshed — the testability seams shifted
most of them — and it now says which commit they were correct at and to confirm
with the grep rather than trusting them. One entry added: the
DefaultNostrSocketClientFactory overload taking an explicit HttpClient has no
caller now that everything goes through the interface method.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-05 23:32:53 +02:00
Kgothatso Ngako
385c58ba7e docs: rewrite the sync note as what exists rather than what to build
The design landed across the six commits before this one, so the note is now
describing code. Reorganised around that: the reasoning that made it worth
writing is unchanged, but "the shape to build" is now "how it holds together"
and points at the classes, and the numbered traps have become properties of the
thing rather than warnings about a thing that did not exist yet.

Three sections earn their place after the fact:

  - the two timestamp decisions, which are the ones most likely to be "cleaned
    up" by someone who has not read this: no `since` on kind 1059 because our
    own wraps are stamped up to two days in the past, and no watermark on 445
    even though it would be safe, because `limit` already bounds the burst.
  - the four ways a group id can appear, which is why the group filter is
    derived from the room list rather than wired at the join sites.
  - "Not done", which was previously implicit in a staging plan: connectivity
    changes, NIP-42 AUTH, the collector-per-socket router the design originally
    called for, and the fact that the DM relay set is one relay.

The "suggested order" section is gone; git log is a better record of it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-05 16:20:08 +02:00
Kgothatso Ngako
178ddd0181 docs: write down how a long-running chat sync would work
Every chat sync today is a pull: a screen queues a request row, a pump drains
it, the relay answers, the subscription is closed. Nothing arrives between
pulls, so a message sent one second after EOSE waits for the next time someone
opens a screen.

This note works out what it takes to hold the two chat subscriptions open for
as long as the app is active — kind 1059 p-tagged to us, and kind 445 h-tagged
with every group we belong to — and, more usefully, what in the current
pipeline quietly assumes a subscription is short:

  - completeOnSubscriptionEnd finishes the flow at EOSE, which is what releases
    the slot and sends the CLOSE,
  - SUBSCRIPTION_TIMEOUT hard-kills anything still open at 120s,
  - subscriptionSlots is a Semaphore(4) shared with the backfill queue, so a
    permanent subscription is a permanently-held permit,
  - both saveNostrEvent overloads need a request row to attach provenance to
    and to flip to "processed",
  - and nothing in the app reconnects a dropped socket at all. That is
    invisible today only because every subscription is short and the next
    queued request re-opens the socket on its way out.

The design keeps the queue and its three pumps exactly as they are: live
subscriptions replace polling, not reconciliation. Negentropy stays the tool
for first login, the catch-up after a background gap, and "load older".

The group filter is derived from chatRepository.observeChatRoomListByPublicKey
rather than wired at each join site, because a group id can appear four ways
and only one of them (creating a group) is somewhere anyone would think to call
a subscribe function — being added arrives as a Welcome processed deep inside
NostrDao.storeNostrEvent. Observing the room list also closes the loop: a
Welcome lands on the live gift wrap subscription, a ChatRoom row is written,
the Flow re-emits, and the group filter widens without anyone opening a chat.

Two findings fell out of checking the details against our own code:

  - `since = now` on kind 1059 would silently drop messages. Gift wraps are
    stamped with TimeUtils.randomWithTwoDays(), so a wrap published now can
    carry a created_at two days in the past. Kind 445 uses TimeUtils.now() and
    can take a watermark — opposite treatment for the two kinds we care about.
  - the "sent-messages" filter (kinds=[1059], authors=[me]) cannot match
    anything, because gift wraps are signed with a fresh throwaway KeyPair().
    It is also unnecessary: createNip17ChatRoom puts the user in their own
    participant list, so we wrap a copy to ourselves and the account-wide
    #p=[me] subscription already picks it up.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-05 16:01:47 +02:00