Repository navigation
0.5.237: contact requests, ignore, and the key re-ask for live chat (#819, #821 carried) - #820
Merged
Merged
Conversation
…your inbox (#818) A contact is consent each side authors: a live consent:replication:v1 grant covering chat:. GET /v1/contacts listed only the grants the owner signed, and nothing listed the grants other people signed naming the owner. So being added was invisible until you added the person yourself, and both people had to add each other blind (Eric x Francesco). - contacts_chat::incoming_contact_requests lists live grants that: - name the owner's fedID or this node's keys; - are signed by someone else, resolved to a PERSON through edge's contact resolver (never infrastructure, never the owner's devices); - cover chat:; - are not withdrawn or recanted by their signer, and not expired; - are unanswered (the person is not already a contact). It returns one entry per person, newest first, each carrying its `accept`: POST /v1/contacts {key_id}. The read is persist's bounded AttestationQuery::to(key).dimension(consent:replication:v1). - "Already a contact" is now one function, contacts_chat::contact_persons, extracted from GET /v1/contacts so the two lists cannot disagree. - GET /v1/contacts/requests (the owner; a delegate may read). - GET /v1/self/invites gains `contact_requests` beside the family, community, affiliation and pair-room `invites`, so there is one inbox. - FSD/MEMBERSHIP_INVITES.md section 8 specifies it, and names what is not yet done: declining, link-dependent delivery (CIRISEdge#888), requests addressed to another device, and the opener-only pair invite. Tests: - tests/contacts_chat.rs: a request until you add back, and a withdrawn request is not offered. Both filters are mutation-checked. - tests/community_crud.rs: on a two-node mesh, Alice's request reaches Bob's own inbox, hers shows nothing, and Bob adding back clears it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QriZxPx5aJvHXCGaTZmvKF
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QriZxPx5aJvHXCGaTZmvKF
Per CC's read (CC 5.3.2.4.1). The steward's ruling on the name is pending.
- POST /v1/contacts/requests/{grant_attestation_id}/ignore writes the owner's
local-tier `scores` row, dimension contact:request:ignored:v1, with
references_attestation_id pointing at the request grant, no subject and
cohort self. It goes through attestation_insert_local, unsigned, and is never
promoted, so the requester learns nothing. A request that is not pending is a
404 contacts.request_not_found.
- DELETE on the same path un-ignores: a local `withdraws` under the same
dimension citing the ignore. Un-ignoring something not ignored is a 404
contacts.request_not_ignored.
- A delegate may not answer: 403 contacts.delegate_may_not_answer.
- GET /v1/contacts/requests adds `ignored` (entries plus ignore_id). Each
request carries `ignore: {method, path}` beside `accept`. The /v1/self/invites
inbox lists pending only.
- Decline, where the requester learns, waits on persist's addressed placement
(CIRISPersist#1121, after v60). It is not shipped at a wider audience in the
meantime (FSD section 8.2).
Tests:
- ignoring hides the request privately: the row is local tier, not federation;
un-ignoring restores it, and the fold is mutation-checked;
- ignoring something that is not a request is refused.
The three new refusal ids are queued in KNOWN_UNLOCALIZED; MAX_UNCOVERED goes
from 30 to 33.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QriZxPx5aJvHXCGaTZmvKF
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
…d `mutual` on contacts (CSD-109 review) From the client's CSD-109 sign-off questions: - requester_label: a fedID key is <label>-<fingerprint>, and the label is the person's own choice at mint. It is stated (their claim, never verified) so no client parses key ids. It is null for keys not in that form. - A request lasts exactly as long as its grant. Besides withdrawal and row expiry, the grant's own valid_until policy window now ends it too (mutation-checked). - GET /v1/contacts rows gain `mutual`: whether that person has added the owner back. The requester sees false (pending) until the other side accepts, then true. It is read with the same inbound reader the requests use, so the two agree. - Refactor: inbound_chat_grants (every person who added the owner) feeds both the requests (minus contacts) and `mutual`. Tests: - a request lapses with its grant's window; - the two-node mesh test now asserts requester_label, and the requester's mutual going false then true. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QriZxPx5aJvHXCGaTZmvKF
…il the key lands The five-platform cross-chat stage (2026-10-25): the linux node pasted the Android owner's fedcode v3, got contacts.awaiting_key_body, and the key never arrived. The canonical held the stranger's key:record:v1 row at federation tier and both nodes held each other's trust-root acceptance, but every hop that could explain the stall logs at DEBUG (edge's "recovery round: asked this peer", the responder's "identifier lookup refused: no mutual trust root"), so neither node's log said anything. - The pending-contacts pass now re-queues the Key Pull every pass. Edge's recovery queue removes a name when its Pull is sent and nothing re-adds it if the reply is lost, so one dropped answer stranded the contact until the person pasted again. - After 60 s it WARNs "KEY FETCH STALLED" (again every 5 min) with what this node knows: wait time, asks, whether the runtime exists, edge's recovery queue depth, peers in no-route backoff, and the five places to look next. - COMPLETED now logs waited_secs and asked. The pending clock keeps the first paste, so waited_secs is the person's real wait. - tests/contact_key_pull_e2e.rs drives the production path in process (request_key_body, send_recovery_pull, the responder's subject_holdings, apply) and proves the canonical answers: Summary(1), Diff, Deliver, admitted 1. The fault is upstream of the round, on the asking node. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QriZxPx5aJvHXCGaTZmvKF
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QriZxPx5aJvHXCGaTZmvKF
emooreatx
changed the base branch from
feat/incoming-contact-requests
to
main
October 25, 2026 22:12
emooreatx
changed the title
This was referenced Oct 25, 2026
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QriZxPx5aJvHXCGaTZmvKF
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #819 (contact requests listed). This adds Ignore, following CC's read (CC 5.3.2.4.1). The steward's ruling on the name
contact:request:ignored:v1is pending; the name is one constant if it changes.Ignore: private and reversible
POST /v1/contacts/requests/{grant_attestation_id}/ignorewrites the owner's local-tierscoresrow withreferences_attestation_idpointing at the grant. It is never promoted, so the requester learns nothing.{state: "ignored", grant_attestation_id, ignore_id}.contacts.request_not_foundif it isn't a pending request.DELETEon the same path un-ignores, as a localwithdrawsciting the ignore.{state: "pending", withdrawal_id}.contacts.request_not_ignored.contacts.delegate_may_not_answer.GET /v1/contacts/requestsaddsignored: [...], and every entry carriesignore: {method, path}.Decline (the requester learns) waits on persist's addressed placement, CIRISPersist#1121, after v60. It is deliberately not shipped at a wider audience in the meantime (FSD §8.2).
Tests:
Locally green: lib, contacts_chat (40), community_crud (15), the gates, the localization guard against client 0.5.230, and clippy with
-D warnings.🤖 Generated with Claude Code
https://claude.ai/code/session_01QriZxPx5aJvHXCGaTZmvKF