From 145caaf42b4f7cf963414768436f063cb146fc2d Mon Sep 17 00:00:00 2001 From: spaced4ndy <8711996+spaced4ndy@users.noreply.github.com> Date: Tue, 21 Oct 2025 18:52:29 +0400 Subject: [PATCH] more docs --- docs/rfcs/2025-10-20-chat-relays.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/rfcs/2025-10-20-chat-relays.md b/docs/rfcs/2025-10-20-chat-relays.md index f080171692..9f54a39a2f 100644 --- a/docs/rfcs/2025-10-20-chat-relays.md +++ b/docs/rfcs/2025-10-20-chat-relays.md @@ -68,6 +68,13 @@ Notes: Overall it just seems a natural and convenient way to store group link for all members, rather than having it separately. +- On updating group link data with one relay link at a time vs waiting for all links. + + - Overhead is minimal - one request to owner's SMP server per relay. + - Waiting for a relay to send relay link can take indefinitely long. + - In proposed protocol owner doesn't have to wait for links from all relays for simplicity and to minimize wait time - it allows owner to conclude group creation potentially earlier, in case some relays are stuck or offline (owner can add their links later, once they successfully send it). + - Alternatively owner could collect all relay links first and make a single update of group link data, then notify all relays at once. + - Owner should reject contact requests to their group link. - Chat relay should reject contact requests to its relay link until chat relay confirms it is attached to the group link data. Can be based on `GroupRelayOwnStatus`, see below. @@ -79,6 +86,7 @@ Notes: - Recovery. - For owner: + - Owner should be able to continue creating group from any step. - Step 1. Create new group - initial. - Step 2. Create short link - first real step, can be synchronous, if it fails can restart (requires user action). @@ -185,6 +193,7 @@ M ->> M: 8. Deduplicate message Notes: - New relay doesn't have group history. + - We can prohibit to remove last relay without adding new one. - Relays can synchronize history. - Can be considered after MVP.