deploy: 937c79bc3c

docs/protocol/channels-overview.html

@@ -1007,7 +1007,7 @@ window.addEventListener('click',(e)=>{
 <p>Subscribers hold their own received copies. Signed messages are independently verifiable without consulting the relay or owner. Unsigned content depends on cross-relay consistency or future transcript integrity mechanisms.</p>
 <h3 id="identity-and-ownership" tabindex="-1">Identity and ownership</h3>
 <p>A channel's identity is the SHA-256 hash of the genesis root public key, computed at creation time and never changed - even if relays are added, removed, or the channel link is rotated. It is self-authenticating: derived from a key pair that only the channel creator held. It is embedded in the channel's link, distributed in the profile to all members, and used as a binding prefix in all signed messages.</p>
-<p>Subscribers validate that the identity in the link matches the identity in the profile, preventing link substitution. Profile updates that attempt to change the identity are rejected. Full validation that the identity equals the hash of the root key is deferred: if current clients enforced this check, they would reject future rotated links as invalid. The identity is correctly managed today; validation will be enforced with the key rotation protocol. See the <a href="https%3A//github.com/simplex-chat/simplex-chat/blob/stable/simplex-chat/docs/rfcs/2026-03-28-group-identity-binding.md">group identity binding RFC</a>.</p>
+<p>Subscribers validate that the identity in the link matches the identity in the profile, preventing link substitution. Profile updates that attempt to change the identity are rejected. Full validation that the identity equals the hash of the root key is deferred: if current clients enforced this check, they would reject future rotated links as invalid. The identity is correctly managed today; validation will be enforced with the key rotation protocol. See the <a href="https://github.com/simplex-chat/simplex-chat/blob/stable/docs/rfcs/2026-03-28-group-identity-binding.md">group identity binding RFC</a>.</p>
 <p>The root key does not sign messages directly. Instead, it authorizes owner keys through a signed chain. At creation, the owner generates a root key pair and a separate member key pair for signing. The member key is published as an authorization entry signed by the root key. New owners can be added by any previously authorized owner signing a new entry. Anyone retrieving the channel link can verify this chain without network access.</p>
 <p>The root key is a bootstrap key - it certifies owners, then need not be used again. All owners are cryptographically indistinguishable to subscribers (they all have equally valid authorization chains), which - provided multiple owners were signed by the root key - conceals the creator's identity.</p>
 <p>The channel link is the out-of-band trust anchor - relays and SMP routers cannot modify link content. All members announce their signing keys on joining. Owner keys are verifiable against the link. Role changes (promoting members to admin, moderator) are signed by owners at the protocol level.</p>
@@ -1127,7 +1127,7 @@ window.addEventListener('click',(e)=>{
 <h3 id="current-gaps" tabindex="-1">Current gaps</h3>
 <ol>
 <li><strong>Cross-relay consistency detection.</strong> Duplicate messages are silently deduplicated without hash comparison. Designed but not implemented.</li>
-<li><strong>Link entity ID validation.</strong> Deferred to a future version with key rotation. See <a href="https%3A//github.com/simplex-chat/simplex-chat/blob/stable/simplex-chat/docs/rfcs/2026-03-28-group-identity-binding.md">group identity binding RFC</a>.</li>
+<li><strong>Link entity ID validation.</strong> Deferred to a future version with key rotation. See <a href="https://github.com/simplex-chat/simplex-chat/blob/stable/docs/rfcs/2026-03-28-group-identity-binding.md">group identity binding RFC</a>.</li>
 <li><strong>Multi-relay UX.</strong> Protocol supports multiple relays per subscriber; no UX for monitoring relay-level delivery health. It will be added in v6.5.x.</li>
 </ol>
 <h2 id="future-work" tabindex="-1">Future work</h2>

docs/protocol/channels-protocol.html

@@ -1092,7 +1092,7 @@ brokerTs       = 8*8 OCTET                    ; UTC system time
 <li>If a duplicate is found, the message is silently dropped (in channels with relays).</li>
 <li>In non-relay groups, duplicate detection triggers a <code>x.grp.mem.con</code> notification to the forwarding member.</li>
 </ul>
-<p>This is essentially cache coherence verification - comparing what was received from one cache node against another. TODO: Currently, deduplication only detects the presence of duplicates. The protocol design includes provisions for detecting differences between relay-delivered copies of the same message (hash comparison, UI indicators for discrepancies). This is described in the <a href="https%3A//github.com/simplex-chat/simplex-chat/blob/stable/simplex-chat/docs/rfcs/2025-08-11-channels-forwarding.md">channels forwarding RFC</a> and is not yet implemented.</p>
+<p>This is essentially cache coherence verification - comparing what was received from one cache node against another. TODO: Currently, deduplication only detects the presence of duplicates. The protocol design includes provisions for detecting differences between relay-delivered copies of the same message (hash comparison, UI indicators for discrepancies). This is described in the <a href="https://github.com/simplex-chat/simplex-chat/blob/stable/docs/rfcs/2025-08-11-channels-forwarding.md">channels forwarding RFC</a> and is not yet implemented.</p>
 <h3 id="channel-as-sender-messages" tabindex="-1">Channel-as-sender messages</h3>
 <p>Owners can send messages attributed to the channel rather than to themselves. When <code>asGroup = True</code> is set in the message container, the relay forwards the message with a channel-as-sender tag instead of attributing it to a specific member. On the subscriber side, such messages are displayed as coming from the channel (using the channel's profile image and name) rather than from a specific owner.</p>
 <p>This will be useful for channels with multiple owners (not yet implemented at application level) where the identity of the specific sender should not be visible to subscribers. The relay must respect this directive; ignoring it and revealing the sending owner's identity is a threat vector (detectable out-of-band by members communicating with the owner).</p>