docs(tasks): scope the vtc-client / messaging-layer migration (blocked, not a drop-in) - #341
Merged
Merged
Conversation
…d, not a drop-in) The backlog framed "consume vtc-client and delete the hand-built join path" as an unblocked consumer change once VTI #1399 shipped. Verifying against vtc-client 0.6.7 / vta-sdk 0.42.1 source shows it is not a drop-in: vtc-client's session verbs open their own mediator socket per DID (displacing OpenVTC's per-identity listener and breaking inbound), and the REST verbs need a VTC REST base URL the join flow never discovers (regressing DIDComm/TSP-only VTC support). The real deliverable is migrating OpenVTC's whole messaging layer onto vta-sdk sessions. Add `tasks/vtc-client-migration-scoping.md` (mirrors `d4-scoping.md`): the two walls with source evidence, the coupled surface, the options (recommend keeping the hand-built path; do reply-proof verification as a separate conflict-free piece), a work breakdown if the full migration is scheduled, and the stale-REST comment correction to carry. Update `follow-ups.md` to point both affected items at the doc and record the blocker. Signed-off-by: Glenn Gore <glenn.g@affinidi.com>
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
1 participant
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.
Scoping doc (no implementation) for the last backlog follow-up, "consume
vtc-clientfor VTC interactions and delete the hand-built path."Why a scoping doc instead of a PR that does it
The backlog treated this as an unblocked consumer change once VTI #1399 shipped. Verifying against
vtc-client0.6.7 /vta-sdk0.42.1 source, it is not a drop-in — two independent walls:VtcClient::connect_didcomm/connect_tsp→vta_sdkconnect_didcomm→ a freshDIDCommSession("each client gets its own mediator websocket; one socket per DID"). OpenVTC already holds one listener per persona (and fix(vetting): guide to creating a persona in-panel, and bring a new persona online at runtime #337 installs one at runtime), so a second socket for the same DID displaces it and breaks inbound — thestored-mail-never-collected/listener-socket-leakfailure class.submit_join_asover HTTPS needs a VTC REST base URL, but the join flow addresses a VTC by DID over DIDComm/TSP and never discovers one. Many VTCs are DIDComm/TSP-only; REST-only submit drops them.Root cause is an architectural mismatch, not an upstream gap: vtc-client is built for a caller that owns its VTC sessions through vta-sdk; OpenVTC owns its transports through
affinidi-messaging-delivery(one per identity + durable outbox, #194). So the true deliverable is migrating OpenVTC's whole messaging layer onto vta-sdk sessions — its own initiative.What this PR adds
tasks/vtc-client-migration-scoping.md— mirrorsd4-scoping.md: the two walls with source evidence, the coupled surface (join verbs incl. the fix(join): fail loudly on an oversized join submit instead of a silent drop #339 guard and feat(relationships): honor a community's relationshipIdentifierDefault (#241) #335 profile-show, the transport, session tracking, inbound dispatch, the durable outbox), the options (recommend: keep the hand-built path; do reply-proof verification as a separate conflict-free piece; pursue the full migration only as a scheduled initiative), a C.0–C.5 work breakdown, and the stale-REST comment correction to carry.tasks/follow-ups.md— both affected items ("consume vtc-client", "verify reply proofs") now point at the doc and record the blocker; the companion-docs header lists both scoping docs.Docs only — no code, no behaviour change.