+
+
+Invest in SimpleX Chat. [Learn more on Wefunder](https://wefunder.com/simplexchat).
# SimpleX - the first messaging platform that has no user identifiers of any kind - 100% private by design!
@@ -218,12 +220,14 @@ You can use SimpleX with your own servers and still communicate with people usin
Recent and important updates:
-[Jul 29, 2025 SimpleX Chat v6.4.1: welcome your contacts, review members to protect groups, and more.](./blog/20250729-simplex-chat-v6-4-1-welcome-contacts-protect-groups-app-security.md)
+[Jul 22, 2026. SimpleX Public Names — a Name Nobody Can Take From You](./blog/20260722-simplex-public-names.md)
+
+[Apr 30, 2026. SimpleX Channels, SimpleX Network Consortium and Community Crowdfunding - to Preserve Freedom of Speech](./blog/20260430-simplex-channels-v6-5-consortium-crowdfunding-freedom-of-speech.md)
+
+[Jul 29, 2025. SimpleX Chat v6.4.1: welcome your contacts, review members to protect groups, and more.](./blog/20250729-simplex-chat-v6-4-1-welcome-contacts-protect-groups-app-security.md)
[Jul 3, 2025 SimpleX network: new experience of connecting with people — available in SimpleX Chat v6.4-beta.4](./blog/20250703-simplex-network-protocol-extension-for-securely-connecting-people.md)
-[Mar 8, 2025. SimpleX Chat v6.3: new user experience and safety in public groups](./blog/20250308-simplex-chat-v6-3-new-user-experience-safety-in-public-groups.md)
-
[Jan 14, 2025. SimpleX network: large groups and privacy-preserving content moderation](./blog/20250114-simplex-network-large-groups-privacy-preserving-content-moderation.md)
[Dec 10, 2024. SimpleX network: preset servers operated by Flux, business chats and more with v6.2 of the apps](./20241210-simplex-network-v6-2-servers-by-flux-business-chats.md)
@@ -240,10 +244,6 @@ Recent and important updates:
[Apr 22, 2023. SimpleX Chat: vision and funding, v5.0 released with videos and files up to 1gb](./blog/20230422-simplex-chat-vision-funding-v5-videos-files-passcode.md).
-[Mar 1, 2023. SimpleX File Transfer Protocol – send large files efficiently, privately and securely, soon to be integrated into SimpleX Chat apps.](./blog/20230301-simplex-file-transfer-protocol.md).
-
-[Nov 8, 2022. Security audit by Trail of Bits, the new website and v4.2 released](./blog/20221108-simplex-chat-v4.2-security-audit-new-website.md).
-
[All updates](./blog)
## :zap: Quick installation of a terminal app
diff --git a/apps/ios/Shared/ContentView.swift b/apps/ios/Shared/ContentView.swift
index ba49c767da..22d0da3829 100644
--- a/apps/ios/Shared/ContentView.swift
+++ b/apps/ios/Shared/ContentView.swift
@@ -257,26 +257,33 @@ struct ContentView: View {
ChatListView(activeUserPickerSheet: $chatListUserPickerSheet)
.redacted(reason: appSheetState.redactionReasons(protectScreen))
.onAppear {
- requestNtfAuthorization()
- // Local Authentication notice is to be shown on next start after onboarding is complete
- if (!prefLANoticeShown && prefShowLANotice && chatModel.chats.count > 2) {
- prefLANoticeShown = true
- alertManager.showAlert(laNoticeAlert())
- } else if !chatModel.showCallView && CallController.shared.activeCallInvitation == nil {
- DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
- if !noticesShown {
- let showWhatsNew = shouldShowWhatsNew()
- let showUpdatedConditions = chatModel.conditions.conditionsAction?.showNotice ?? false
- noticesShown = showWhatsNew || showUpdatedConditions
- if showWhatsNew || showUpdatedConditions {
- noticesSheetItem = .whatsNew(updatedConditions: showUpdatedConditions)
+ // Connect only after the notifications prompt is resolved: the system prompt suspends
+ // the app (scene .inactive), which kills an in-flight connect and makes
+ // getTopViewController() nil. Deferring keeps the URL until the app is active again.
+ let openingViaLink = pendingConnectUrl != nil
+ requestNtfAuthorization(showDeniedAlert: !openingViaLink) {
+ connectViaUrl()
+ }
+ if !openingViaLink {
+ // Local Authentication notice is to be shown on next start after onboarding is complete
+ if (!prefLANoticeShown && prefShowLANotice && chatModel.chats.count > 2) {
+ prefLANoticeShown = true
+ alertManager.showAlert(laNoticeAlert())
+ } else if !chatModel.showCallView && CallController.shared.activeCallInvitation == nil {
+ DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
+ if !noticesShown {
+ let showWhatsNew = shouldShowWhatsNew()
+ let showUpdatedConditions = chatModel.conditions.conditionsAction?.showNotice ?? false
+ noticesShown = showWhatsNew || showUpdatedConditions
+ if showWhatsNew || showUpdatedConditions {
+ noticesSheetItem = .whatsNew(updatedConditions: showUpdatedConditions)
+ }
}
}
}
+ showReRegisterTokenAlert()
}
prefShowLANotice = true
- connectViaUrl()
- showReRegisterTokenAlert()
}
.onChange(of: chatModel.appOpenUrl) { _ in connectViaUrl() }
.onChange(of: chatModel.reRegisterTknStatus) { _ in showReRegisterTokenAlert() }
@@ -383,15 +390,16 @@ struct ContentView: View {
}
}
- func requestNtfAuthorization() {
+ func requestNtfAuthorization(showDeniedAlert: Bool = true, whenDone: (() -> Void)? = nil) {
NtfManager.shared.requestAuthorization(
onDeny: {
- if (!notificationAlertShown) {
+ if showDeniedAlert, !notificationAlertShown {
notificationAlertShown = true
alertManager.showAlert(notificationAlert())
}
},
- onAuthorized: { notificationAlertShown = false }
+ onAuthorized: { notificationAlertShown = false },
+ whenDone: { if let whenDone { DispatchQueue.main.async(execute: whenDone) } }
)
}
@@ -436,16 +444,20 @@ struct ContentView: View {
}
// Spec: spec/client/navigation.md#connectViaUrl
+ // a URL opened via link that is ready to be connected now (appOpenUrl immediately, or
+ // appOpenUrlLater once the app is active — see .onChange(of: scenePhase) in SimpleXApp)
+ private var pendingConnectUrl: URL? {
+ let m = ChatModel.shared
+ if let url = m.appOpenUrl { return url }
+ if let url = m.appOpenUrlLater, AppChatState.shared.value == .active, scenePhase == .active { return url }
+ return nil
+ }
+
func connectViaUrl() {
let m = ChatModel.shared
- if let url = m.appOpenUrl {
- m.appOpenUrl = nil
- connectViaUrl_(url)
- } else if let url = m.appOpenUrlLater, AppChatState.shared.value == .active, scenePhase == .active {
- // correcting branch in case .onChange(of: scenePhase) in SimpleXApp doesn't trigger and transfer appOpenUrlLater into appOpenUrl
- m.appOpenUrlLater = nil
- connectViaUrl_(url)
- }
+ guard let url = pendingConnectUrl else { return }
+ if m.appOpenUrl != nil { m.appOpenUrl = nil } else { m.appOpenUrlLater = nil }
+ connectViaUrl_(url)
}
func connectViaUrl_(_ url: URL) {
diff --git a/apps/ios/Shared/Model/AppAPITypes.swift b/apps/ios/Shared/Model/AppAPITypes.swift
index a5a56174b1..40b88ec338 100644
--- a/apps/ios/Shared/Model/AppAPITypes.swift
+++ b/apps/ios/Shared/Model/AppAPITypes.swift
@@ -45,7 +45,7 @@ enum ChatCommand: ChatCmdProtocol {
case apiGetChat(chatId: ChatId, scope: GroupChatScope?, contentTag: MsgContentTag?, pagination: ChatPagination, search: String)
case apiGetChatContentTypes(chatId: ChatId, scope: GroupChatScope?)
case apiGetChatItemInfo(type: ChatType, id: Int64, scope: GroupChatScope?, itemId: Int64)
- case apiSendMessages(type: ChatType, id: Int64, scope: GroupChatScope?, sendAsGroup: Bool, live: Bool, ttl: Int?, composedMessages: [ComposedMessage])
+ case apiSendMessages(type: ChatType, id: Int64, scope: GroupChatScope?, sendAsGroup: Bool, live: Bool, ttl: Int?, sign: Bool, composedMessages: [ComposedMessage])
case apiCreateChatTag(tag: ChatTagData)
case apiSetChatTags(type: ChatType, id: Int64, tagIds: [Int64])
case apiDeleteChatTag(tagId: Int64)
@@ -63,6 +63,7 @@ enum ChatCommand: ChatCmdProtocol {
case apiPlanForwardChatItems(fromChatType: ChatType, fromChatId: Int64, fromScope: GroupChatScope?, itemIds: [Int64])
case apiForwardChatItems(toChatType: ChatType, toChatId: Int64, toScope: GroupChatScope?, sendAsGroup: Bool, fromChatType: ChatType, fromChatId: Int64, fromScope: GroupChatScope?, itemIds: [Int64], ttl: Int?)
case apiShareChatMsgContent(shareChatType: ChatType, shareChatId: Int64, toChatType: ChatType, toChatId: Int64, toScope: GroupChatScope?, sendAsGroup: Bool)
+ case apiShareMyAddress(toChatType: ChatType, toChatId: Int64, toScope: GroupChatScope?, sendAsGroup: Bool)
case apiGetNtfToken
case apiRegisterToken(token: DeviceToken, notificationMode: NotificationsMode)
case apiVerifyToken(token: DeviceToken, nonce: String, code: String)
@@ -84,6 +85,7 @@ enum ChatCommand: ChatCmdProtocol {
case apiLeaveGroup(groupId: Int64)
case apiListMembers(groupId: Int64)
case apiUpdateGroupProfile(groupId: Int64, groupProfile: GroupProfile)
+ case apiSetPublicGroupAccess(groupId: Int64, access: PublicGroupAccess)
case apiCreateGroupLink(groupId: Int64, memberRole: GroupMemberRole)
case apiGroupLinkMemberRole(groupId: Int64, memberRole: GroupMemberRole)
case apiDeleteGroupLink(groupId: Int64)
@@ -130,9 +132,9 @@ enum ChatCommand: ChatCmdProtocol {
case apiAddContact(userId: Int64, incognito: Bool)
case apiSetConnectionIncognito(connId: Int64, incognito: Bool)
case apiChangeConnectionUser(connId: Int64, userId: Int64)
- case apiConnectPlan(userId: Int64, connLink: String, linkOwnerSig: LinkOwnerSig?)
- case apiPrepareContact(userId: Int64, connLink: CreatedConnLink, contactShortLinkData: ContactShortLinkData)
- case apiPrepareGroup(userId: Int64, connLink: CreatedConnLink, directLink: Bool, groupShortLinkData: GroupShortLinkData)
+ case apiConnectPlan(userId: Int64, connLink: String, resolveMode: PlanResolveMode, linkOwnerSig: LinkOwnerSig?)
+ case apiPrepareContact(userId: Int64, connLink: CreatedConnLink, contactShortLinkData: ContactShortLinkData, verifiedDomain: SimplexDomain?)
+ case apiPrepareGroup(userId: Int64, connLink: CreatedConnLink, directLink: Bool, groupShortLinkData: GroupShortLinkData, verifiedDomain: SimplexDomain?)
case apiChangePreparedContactUser(contactId: Int64, newUserId: Int64)
case apiChangePreparedGroupUser(groupId: Int64, newUserId: Int64)
case apiConnectPreparedContact(contactId: Int64, incognito: Bool, msg: MsgContent?)
@@ -155,6 +157,9 @@ enum ChatCommand: ChatCmdProtocol {
case apiAddMyAddressShortLink(userId: Int64)
case apiSetProfileAddress(userId: Int64, on: Bool)
case apiSetAddressSettings(userId: Int64, addressSettings: AddressSettings)
+ case apiSetUserDomain(userId: Int64, simplexDomain: String?)
+ case apiVerifyContactDomain(contactId: Int64)
+ case apiVerifyGroupDomain(groupId: Int64)
case apiAcceptContact(incognito: Bool, contactReqId: Int64)
case apiRejectContact(contactReqId: Int64)
// WebRTC calls
@@ -236,11 +241,11 @@ enum ChatCommand: ChatCmdProtocol {
return "/_get chat \(chatId)\(scopeRef(scope))\(tag) \(pagination.cmdString)" + (search == "" ? "" : " search=\(search)")
case let .apiGetChatContentTypes(chatId, scope): return "/_get content types \(chatId)\(scopeRef(scope))"
case let .apiGetChatItemInfo(type, id, scope, itemId): return "/_get item info \(ref(type, id, scope: scope)) \(itemId)"
- case let .apiSendMessages(type, id, scope, sendAsGroup, live, ttl, composedMessages):
+ case let .apiSendMessages(type, id, scope, sendAsGroup, live, ttl, sign, composedMessages):
let msgs = encodeJSON(composedMessages)
let ttlStr = ttl != nil ? "\(ttl!)" : "default"
let asGroup = sendAsGroup ? "(as_group=on)" : ""
- return "/_send \(ref(type, id, scope: scope))\(asGroup) live=\(onOff(live)) ttl=\(ttlStr) json \(msgs)"
+ return "/_send \(ref(type, id, scope: scope))\(asGroup) live=\(onOff(live)) ttl=\(ttlStr) sign=\(onOff(sign)) json \(msgs)"
case let .apiCreateChatTag(tag): return "/_create tag \(encodeJSON(tag))"
case let .apiSetChatTags(type, id, tagIds): return "/_tags \(ref(type, id, scope: nil)) \(tagIds.map({ "\($0)" }).joined(separator: ","))"
case let .apiDeleteChatTag(tagId): return "/_delete tag \(tagId)"
@@ -266,6 +271,9 @@ enum ChatCommand: ChatCmdProtocol {
case let .apiShareChatMsgContent(shareChatType, shareChatId, toChatType, toChatId, toScope, sendAsGroup):
let asGroup = sendAsGroup ? "(as_group=on)" : ""
return "/_share chat content \(ref(shareChatType, shareChatId, scope: nil)) \(ref(toChatType, toChatId, scope: toScope))\(asGroup)"
+ case let .apiShareMyAddress(toChatType, toChatId, toScope, sendAsGroup):
+ let asGroup = sendAsGroup ? "(as_group=on)" : ""
+ return "/_share address \(ref(toChatType, toChatId, scope: toScope))\(asGroup)"
case .apiGetNtfToken: return "/_ntf get "
case let .apiRegisterToken(token, notificationMode): return "/_ntf register \(token.cmdString) \(notificationMode.rawValue)"
case let .apiVerifyToken(token, nonce, code): return "/_ntf verify \(token.cmdString) \(nonce) \(code)"
@@ -343,11 +351,12 @@ enum ChatCommand: ChatCmdProtocol {
case let .apiAddContact(userId, incognito): return "/_connect \(userId) incognito=\(onOff(incognito))"
case let .apiSetConnectionIncognito(connId, incognito): return "/_set incognito :\(connId) \(onOff(incognito))"
case let .apiChangeConnectionUser(connId, userId): return "/_set conn user :\(connId) \(userId)"
- case let .apiConnectPlan(userId, connLink, linkOwnerSig):
+ case let .apiConnectPlan(userId, connLink, resolveMode, linkOwnerSig):
+ let resolveStr = resolveMode == .unknown ? "" : " resolve=\(resolveMode.rawValue)"
let sigStr = if let linkOwnerSig { " sig=\(encodeJSON(linkOwnerSig))" } else { "" }
- return "/_connect plan \(userId) \(connLink)\(sigStr)"
- case let .apiPrepareContact(userId, connLink, contactShortLinkData): return "/_prepare contact \(userId) \(connLink.connFullLink) \(connLink.connShortLink ?? "") \(encodeJSON(contactShortLinkData))"
- case let .apiPrepareGroup(userId, connLink, directLink, groupShortLinkData): return "/_prepare group \(userId) \(connLink.connFullLink) \(connLink.connShortLink ?? "") direct=\(onOff(directLink)) \(encodeJSON(groupShortLinkData))"
+ return "/_connect plan \(userId) \(connLink)\(resolveStr)\(sigStr)"
+ case let .apiPrepareContact(userId, connLink, contactShortLinkData, verifiedDomain): return "/_prepare contact \(userId) \(connLink.cmdString)\(verifiedDomain.map{ " \($0.cmdString)" } ?? "") \(encodeJSON(contactShortLinkData))"
+ case let .apiPrepareGroup(userId, connLink, directLink, groupShortLinkData, verifiedDomain): return "/_prepare group \(userId) \(connLink.cmdString) direct=\(onOff(directLink))\(verifiedDomain.map{ " \($0.cmdString)" } ?? "") \(encodeJSON(groupShortLinkData))"
case let .apiChangePreparedContactUser(contactId, newUserId): return "/_set contact user @\(contactId) \(newUserId)"
case let .apiChangePreparedGroupUser(groupId, newUserId): return "/_set group user #\(groupId) \(newUserId)"
case let .apiConnectPreparedContact(contactId, incognito, mc): return "/_connect contact @\(contactId) incognito=\(onOff(incognito))\(maybeContent(mc))"
@@ -370,6 +379,10 @@ enum ChatCommand: ChatCmdProtocol {
case let .apiAddMyAddressShortLink(userId): return "/_short_link_address \(userId)"
case let .apiSetProfileAddress(userId, on): return "/_profile_address \(userId) \(onOff(on))"
case let .apiSetAddressSettings(userId, addressSettings): return "/_address_settings \(userId) \(encodeJSON(addressSettings))"
+ case let .apiSetUserDomain(userId, simplexDomain): return "/_set domain \(userId)" + (simplexDomain.map { " " + $0 } ?? "")
+ case let .apiSetPublicGroupAccess(groupId, access): return "/_public group access #\(groupId) \(encodeJSON(access))"
+ case let .apiVerifyContactDomain(contactId): return "/_verify domain @\(contactId)"
+ case let .apiVerifyGroupDomain(groupId): return "/_verify domain #\(groupId)"
case let .apiAcceptContact(incognito, contactReqId): return "/_accept incognito=\(onOff(incognito)) \(contactReqId)"
case let .apiRejectContact(contactReqId): return "/_reject \(contactReqId)"
case let .apiSendCallInvitation(contact, callType): return "/_call invite @\(contact.apiId) \(encodeJSON(callType))"
@@ -460,6 +473,7 @@ enum ChatCommand: ChatCmdProtocol {
case .apiPlanForwardChatItems: return "apiPlanForwardChatItems"
case .apiForwardChatItems: return "apiForwardChatItems"
case .apiShareChatMsgContent: return "apiShareChatMsgContent"
+ case .apiShareMyAddress: return "apiShareMyAddress"
case .apiGetNtfToken: return "apiGetNtfToken"
case .apiRegisterToken: return "apiRegisterToken"
case .apiVerifyToken: return "apiVerifyToken"
@@ -481,6 +495,7 @@ enum ChatCommand: ChatCmdProtocol {
case .apiLeaveGroup: return "apiLeaveGroup"
case .apiListMembers: return "apiListMembers"
case .apiUpdateGroupProfile: return "apiUpdateGroupProfile"
+ case .apiSetPublicGroupAccess: return "apiSetPublicGroupAccess"
case .apiCreateGroupLink: return "apiCreateGroupLink"
case .apiGroupLinkMemberRole: return "apiGroupLinkMemberRole"
case .apiDeleteGroupLink: return "apiDeleteGroupLink"
@@ -551,6 +566,9 @@ enum ChatCommand: ChatCmdProtocol {
case .apiAddMyAddressShortLink: return "apiAddMyAddressShortLink"
case .apiSetProfileAddress: return "apiSetProfileAddress"
case .apiSetAddressSettings: return "apiSetAddressSettings"
+ case .apiSetUserDomain: return "apiSetUserDomain"
+ case .apiVerifyContactDomain: return "apiVerifyContactDomain"
+ case .apiVerifyGroupDomain: return "apiVerifyGroupDomain"
case .apiAcceptContact: return "apiAcceptContact"
case .apiRejectContact: return "apiRejectContact"
case .apiSendCallInvitation: return "apiSendCallInvitation"
@@ -802,7 +820,7 @@ enum ChatResponse1: Decodable, ChatAPIResult {
case invitation(user: UserRef, connLinkInvitation: CreatedConnLink, connection: PendingContactConnection)
case connectionIncognitoUpdated(user: UserRef, toConnection: PendingContactConnection)
case connectionUserChanged(user: UserRef, fromConnection: PendingContactConnection, toConnection: PendingContactConnection, newUser: UserRef)
- case connectionPlan(user: UserRef, connLink: CreatedConnLink, connectionPlan: ConnectionPlan)
+ case connectionPlan(user: UserRef, connLink: CreatedConnLink, planSimplexName: SimplexNameInfo?, otherSimplexName: SimplexNameInfo?, connectionPlan: ConnectionPlan)
case newPreparedChat(user: UserRef, chat: ChatData)
case contactUserChanged(user: UserRef, fromContact: Contact, newUser: UserRef, toContact: Contact)
case groupUserChanged(user: UserRef, fromGroup: GroupInfo, newUser: UserRef, toGroup: GroupInfo)
@@ -926,7 +944,7 @@ enum ChatResponse1: Decodable, ChatAPIResult {
case let .invitation(u, connLinkInvitation, connection): return withUser(u, "connLinkInvitation: \(connLinkInvitation)\nconnection: \(connection)")
case let .connectionIncognitoUpdated(u, toConnection): return withUser(u, String(describing: toConnection))
case let .connectionUserChanged(u, fromConnection, toConnection, newUser): return withUser(u, "fromConnection: \(String(describing: fromConnection))\ntoConnection: \(String(describing: toConnection))\nnewUserId: \(String(describing: newUser.userId))")
- case let .connectionPlan(u, connLink, connectionPlan): return withUser(u, "connLink: \(String(describing: connLink))\nconnectionPlan: \(String(describing: connectionPlan))")
+ case let .connectionPlan(u, connLink, _, _, connectionPlan): return withUser(u, "connLink: \(String(describing: connLink))\nconnectionPlan: \(String(describing: connectionPlan))")
case let .newPreparedChat(u, chat): return withUser(u, String(describing: chat))
case let .contactUserChanged(u, fromContact, newUser, toContact): return withUser(u, "fromContact: \(String(describing: fromContact))\nnewUserId: \(String(describing: newUser.userId))\ntoContact: \(String(describing: toContact))")
case let .groupUserChanged(u, fromGroup, newUser, toGroup): return withUser(u, "fromGroup: \(String(describing: fromGroup))\nnewUserId: \(String(describing: newUser.userId))\ntoGroup: \(String(describing: toGroup))")
@@ -960,6 +978,8 @@ enum ChatResponse2: Decodable, ChatAPIResult {
case membersRoleUser(user: UserRef, groupInfo: GroupInfo, members: [GroupMember], toRole: GroupMemberRole)
case membersBlockedForAllUser(user: UserRef, groupInfo: GroupInfo, members: [GroupMember], blocked: Bool)
case groupUpdated(user: UserRef, toGroup: GroupInfo)
+ case contactDomainVerified(user: UserRef, contact: Contact, verificationFailure: String?)
+ case groupDomainVerified(user: UserRef, groupInfo: GroupInfo, verificationFailure: String?)
case groupLinkCreated(user: UserRef, groupInfo: GroupInfo, groupLink: GroupLink)
case groupLink(user: UserRef, groupInfo: GroupInfo, groupLink: GroupLink)
case groupLinkDeleted(user: UserRef, groupInfo: GroupInfo)
@@ -1015,6 +1035,8 @@ enum ChatResponse2: Decodable, ChatAPIResult {
case .membersRoleUser: "membersRoleUser"
case .membersBlockedForAllUser: "membersBlockedForAllUser"
case .groupUpdated: "groupUpdated"
+ case .contactDomainVerified: "contactDomainVerified"
+ case .groupDomainVerified: "groupDomainVerified"
case .groupLinkCreated: "groupLinkCreated"
case .groupLink: "groupLink"
case .groupLinkDeleted: "groupLinkDeleted"
@@ -1066,6 +1088,8 @@ enum ChatResponse2: Decodable, ChatAPIResult {
case let .membersRoleUser(u, groupInfo, members, toRole): return withUser(u, "groupInfo: \(groupInfo)\nmembers: \(members)\ntoRole: \(toRole)")
case let .membersBlockedForAllUser(u, groupInfo, members, blocked): return withUser(u, "groupInfo: \(groupInfo)\nmember: \(members)\nblocked: \(blocked)")
case let .groupUpdated(u, toGroup): return withUser(u, String(describing: toGroup))
+ case let .contactDomainVerified(u, contact, verificationFailure): return withUser(u, "contact: \(contact)\nverificationFailure: \(verificationFailure ?? "ok")")
+ case let .groupDomainVerified(u, groupInfo, verificationFailure): return withUser(u, "groupInfo: \(groupInfo)\nverificationFailure: \(verificationFailure ?? "ok")")
case let .groupLinkCreated(u, groupInfo, groupLink): return withUser(u, "groupInfo: \(groupInfo)\ngroupLink: \(groupLink)")
case let .groupLink(u, groupInfo, groupLink): return withUser(u, "groupInfo: \(groupInfo)\ngroupLink: \(groupLink)")
case let .groupLinkDeleted(u, groupInfo): return withUser(u, String(describing: groupInfo))
@@ -1368,6 +1392,20 @@ enum OwnerVerification: Decodable, Hashable {
case failed(reason: String)
}
+struct ConnectionPlanResult {
+ var connLink: CreatedConnLink
+ var planSimplexName: SimplexNameInfo?
+ var otherSimplexName: SimplexNameInfo?
+ var connectionPlan: ConnectionPlan
+}
+
+// APIConnectPlan resolution scope; .never is local-store-only (no network), used for per-keystroke name search
+enum PlanResolveMode: String {
+ case allGroups
+ case unknown
+ case never
+}
+
enum ConnectionPlan: Decodable, Hashable {
case invitationLink(invitationLinkPlan: InvitationLinkPlan)
case contactAddress(contactAddressPlan: ContactAddressPlan)
@@ -1766,14 +1804,24 @@ struct ServerOperator: Identifiable, Equatable, Codable {
serverDomains: ["simplex.im"],
conditionsAcceptance: .accepted(acceptedAt: nil, autoAccepted: false),
enabled: true,
- smpRoles: ServerRoles(storage: true, proxy: true),
- xftpRoles: ServerRoles(storage: true, proxy: true)
+ smpRoles: ServerRoles(storage: true, proxy: true, names: true),
+ xftpRoles: ServerRoles(storage: true, proxy: true, names: false)
)
}
struct ServerRoles: Equatable, Codable {
var storage: Bool
var proxy: Bool
+ var names: Bool
+
+ // roles applied when a server matches no operator, mirrors core resolveServerRoles (Operators.hs)
+ static let noOperatorDefault = ServerRoles(storage: true, proxy: true, names: false)
+}
+
+struct ServerRolesOverride: Equatable, Codable, Hashable {
+ var storage: Bool?
+ var proxy: Bool?
+ var names: Bool?
}
struct UserOperatorServers: Identifiable, Equatable, Codable {
@@ -1800,8 +1848,8 @@ struct UserOperatorServers: Identifiable, Equatable, Codable {
serverDomains: [],
conditionsAcceptance: .accepted(acceptedAt: nil, autoAccepted: false),
enabled: false,
- smpRoles: ServerRoles(storage: true, proxy: true),
- xftpRoles: ServerRoles(storage: true, proxy: true)
+ smpRoles: ServerRoles.noOperatorDefault,
+ xftpRoles: ServerRoles.noOperatorDefault
)
}
set { `operator` = newValue }
@@ -1824,6 +1872,7 @@ struct UserOperatorServers: Identifiable, Equatable, Codable {
public enum UserServersWarning: Decodable {
case noChatRelays(user: UserRef?)
+ case noNamesServers(user: UserRef?)
}
enum UserServersError: Decodable {
@@ -1922,11 +1971,12 @@ struct UserServer: Identifiable, Equatable, Codable, Hashable {
var tested: Bool?
var enabled: Bool
var deleted: Bool
+ var roles: ServerRolesOverride = ServerRolesOverride()
var createdAt = Date()
static func == (l: UserServer, r: UserServer) -> Bool {
l.serverId == r.serverId && l.server == r.server && l.preset == r.preset && l.tested == r.tested &&
- l.enabled == r.enabled && l.deleted == r.deleted
+ l.enabled == r.enabled && l.deleted == r.deleted && l.roles == r.roles
}
var id: String { "\(server) \(createdAt)" }
@@ -1986,6 +2036,7 @@ struct UserServer: Identifiable, Equatable, Codable, Hashable {
case tested
case enabled
case deleted
+ case roles
}
}
diff --git a/apps/ios/Shared/Model/ChatModel.swift b/apps/ios/Shared/Model/ChatModel.swift
index a1d28b8e22..e3a6ae30b9 100644
--- a/apps/ios/Shared/Model/ChatModel.swift
+++ b/apps/ios/Shared/Model/ChatModel.swift
@@ -429,6 +429,7 @@ final class ChatModel: ObservableObject {
// audio recording and playback
@Published var stopPreviousRecPlay: URL? = nil // coordinates currently playing source
@Published var draft: ComposeState?
+ // chat id with chat scope, see draftChatId() - group chat and its support chats have the same chat id
@Published var draftChatId: String?
@Published var networkInfo = UserNetworkInfo(networkType: .other, online: true)
// usage conditions
@@ -812,32 +813,63 @@ final class ChatModel: ObservableObject {
}
func removeMemberItems(_ removedMember: GroupMember, byMember: GroupMember, _ groupInfo: GroupInfo) {
+ // Mirrors backend groupFeatureMemberAllowed: fullDelete may be role-gated in business groups.
+ let fullDeletePref = groupInfo.fullGroupPreferences.fullDelete
+ let fullDelete = fullDeletePref.on
+ && byMember.memberRole >= (fullDeletePref.role ?? .observer)
if chatId == groupInfo.id {
- for i in 0..
+
+
+
+
+
+
diff --git a/apps/simplex-directory-service/web/directory.js b/apps/simplex-directory-service/web/directory.js
new file mode 120000
index 0000000000..197f1d6e66
--- /dev/null
+++ b/apps/simplex-directory-service/web/directory.js
@@ -0,0 +1 @@
+../../../website/src/js/directory.js
\ No newline at end of file
diff --git a/apps/simplex-support-bot/bot.test.ts b/apps/simplex-support-bot/bot.test.ts
index a1afd7a660..37521e49dc 100644
--- a/apps/simplex-support-bot/bot.test.ts
+++ b/apps/simplex-support-bot/bot.test.ts
@@ -1068,24 +1068,26 @@ describe("Team Member Lifecycle", () => {
expect(chat.roleChanges.some(r => r.groupId === CUSTOMER_GROUP_ID && r.memberIds.includes(5000 + TEAM_MEMBER_1_ID) && r.role === GroupMemberRole.Owner)).toBe(true)
})
- test("/team invites team member → apiSetMembersRole(Owner) called at invite time", async () => {
+ test("/team invites team member → added directly as Owner, single invitation", async () => {
await bot.onNewChatItems(customerMessage("/team"))
- expectMemberAdded(CUSTOMER_GROUP_ID, TEAM_MEMBER_1_ID)
- expect(chat.roleChanges.some(r =>
- r.groupId === CUSTOMER_GROUP_ID
- && r.memberIds.includes(5000 + TEAM_MEMBER_1_ID)
- && r.role === GroupMemberRole.Owner
+ expect(chat.added.some(a =>
+ a.groupId === CUSTOMER_GROUP_ID
+ && a.contactId === TEAM_MEMBER_1_ID
+ && a.role === GroupMemberRole.Owner
)).toBe(true)
+ // No role change — that would send a second invitation.
+ expect(chat.roleChanges.length).toBe(0)
})
- test("/join invites team member → apiSetMembersRole(Owner) called at invite time", async () => {
+ test("/join invites team member → added directly as Owner, single invitation", async () => {
await bot.onNewChatItems(teamGroupMessage(`/join ${CUSTOMER_GROUP_ID}`))
- expectMemberAdded(CUSTOMER_GROUP_ID, TEAM_MEMBER_1_ID)
- expect(chat.roleChanges.some(r =>
- r.groupId === CUSTOMER_GROUP_ID
- && r.memberIds.includes(5000 + TEAM_MEMBER_1_ID)
- && r.role === GroupMemberRole.Owner
+ expect(chat.added.some(a =>
+ a.groupId === CUSTOMER_GROUP_ID
+ && a.contactId === TEAM_MEMBER_1_ID
+ && a.role === GroupMemberRole.Owner
)).toBe(true)
+ // No role change — that would send a second invitation.
+ expect(chat.roleChanges.length).toBe(0)
})
test("/team when team member already in group (any non-terminal status) → apiSetMembersRole NOT re-called", async () => {
diff --git a/apps/simplex-support-bot/src/bot.ts b/apps/simplex-support-bot/src/bot.ts
index 9b534381de..28b2080793 100644
--- a/apps/simplex-support-bot/src/bot.ts
+++ b/apps/simplex-support-bot/src/bot.ts
@@ -853,17 +853,12 @@ export class SupportBot {
const members = await this.withMainProfile(() => this.chat.apiListMembers(groupId))
const existing = members.find(m => m.memberContactId === teamContactId && isInGroup(m))
if (existing) return existing
- const member = await this.withMainProfile(() =>
- this.chat.apiAddMember(groupId, teamContactId, T.GroupMemberRole.Member)
+ // Invite directly as Owner in one call. Adding as Member then promoting
+ // sent a second invitation, since the API re-sends it when a pending
+ // (GSMemInvited) member's role changes. onMemberConnected re-asserts Owner.
+ return this.withMainProfile(() =>
+ this.chat.apiAddMember(groupId, teamContactId, T.GroupMemberRole.Owner)
)
- try {
- await this.withMainProfile(() =>
- this.chat.apiSetMembersRole(groupId, [member.groupMemberId], T.GroupMemberRole.Owner)
- )
- } catch {
- // Not yet connected — will be promoted in onMemberConnected
- }
- return member
}
async sendToGroup(groupId: number, text: string): PromiseSimpleX Directory
+Communities you can join via SimpleX Chat.
+Also available as a SimpleX chat bot.
+
+
+
+
+
+
+
+
+
+
+ 
+
+
+Before names, the only way to bring people to your channel or business on SimpleX Network was a link — but you cannot use a link in a podcast or a poster: nobody would remember it.
+
+Every place where you could get a name so far belongs to someone else: Telegram can revoke your username, a registrar can suspend your domain.
+
+So we designed SimpleX names for no one to own the registry — on the Ethereum blockchain. If you register `example.simplex`, people type `#example` to join your channel, or `@example.simplex` to message you. If a server operator deletes your link, you can point the name to a new one. Only you control the name with the key in your wallet[^ens].
+
+And we did not add user identifiers to do it. Names are only for those who want to be found — channels, businesses, communities — and servers still cannot see who joined your channel or wrote to you.
+
+We plan to launch `.simplex` names later this year, and to provide the first names to [crowdfunding investors](#community-crowdfunding) as perks.
+
+## How to register a name
+
+
+
+Before names, the only way to bring people to your channel or business on SimpleX Network was a link — but you cannot use a link in a podcast or a poster: nobody would remember it.
+
+Every place where you could get a name so far belongs to someone else: Telegram can revoke your username, a registrar can suspend your domain.
+
+So we designed SimpleX names for no one to own the registry — on the Ethereum blockchain. If you register `example.simplex`, people type `#example` to join your channel, or `@example.simplex` to message you. If a server operator deletes your link, you can point the name to a new one. Only you control the name with the key in your wallet[^ens].
+
+And we did not add user identifiers to do it. Names are only for those who want to be found — channels, businesses, communities — and servers still cannot see who joined your channel or wrote to you.
+
+We plan to launch `.simplex` names later this year, and to provide the first names to [crowdfunding investors](#community-crowdfunding) as perks.
+
+## How to register a name
+
+
+
+To register a test name you need an Ethereum wallet, such as MetaMask, and your SimpleX address or channel link from the app.
+
+Setting up a name takes two steps. On the SimpleX Name Service [test webpage](https://testing-names.simplex.chat), search for the name you want — currently 6 characters or more — paste your address or channel link into the page, and complete the registration.
+
+In the app, you need to claim the name for your channel or contact address — it prevents connecting to your channel or address via any other name. Open your SimpleX address or channel page, tap **Get SimpleX name**, enter the name, and tap Save.
+
+See [this guide](../docs/guide/register-simplex-name.md) for more details.
+
+## How to connect via names
+
+
+
+Type the name into the search bar — `#example.testing` to join the channel, `@example.testing` to send direct messages. You can also send names in messages — they work as links.
+
+Connecting via a name is private. Unlike most applications accessing the chain through a centralized RPC service, SimpleX Chat app resolves names via two independent servers of SimpleX Network, so that no server can see both the name and the user's IP address.
+
+Read more about names in the [whitepaper](https://github.com/simplex-chat/simplex-chat/blob/master/docs/protocol/names-overview.md): their purpose, architecture, security model and planned future work.
+
+## Community Crowdfunding
+
+To ensure the long term success of SimpleX Network we established [SimpleX Network Consortium](https://simplexnetwork.org/consortium.html) — an agreement between a non-profit foundation created for protocol licensing and governance and SimpleX Chat, Inc.
+
+The commercial model for the network that we are building aims to make both our and other businesses on the network profitable. We recently [presented the technology design](https://www.youtube.com/watch?v=UhW8AuoRgxg) for this commercial model at Web3 Summit.
+
+The planned crowdfunding will fund this development. You can [register your interest](https://simplexchat.typeform.com/crowdfunding), and join the [SimpleX Crowdfunding News channel](https://smp10.simplex.im/c#q09nMBmWFGz1m2TvgfZFaEOG5D2a7Ma9mSkl6pHXEsg) for updates.
+
+_Disclaimer: SimpleX Chat, Inc. is testing the waters for a possible Reg CF offering. We’re not asking for or accepting any money right now, and we won’t accept any if sent. We can’t accept any offers to buy securities or take any payments until the official filing is done and it’s live through a regulated platform. Our testing the waters and your possible indications of interest doesn’t create any obligation or commitment of any kind._
+
+
+[^testing]: Test names are free to register; you only need to pay the blockchain fee. The `.testing` namespace is temporary — test names will stop working in the app one month after `.simplex` name sales launch.
+
+[^ens]: SimpleX Name Service (SNS) is a fork of Ethereum Name Service (ENS), but without its centralized dependencies. ENS depends on an off-chain indexer and a hosted metadata service. SNS is fully decentralized — names are indexed and hosted on the blockchain. See [Differences from ENS](https://github.com/simplex-chat/simplex-chat/blob/master/docs/protocol/names-overview.md#differences-from-ens).
diff --git a/blog/README.md b/blog/README.md
index 4544dc0f45..6122eb3c39 100644
--- a/blog/README.md
+++ b/blog/README.md
@@ -1,5 +1,19 @@
# Blog
+Jul 22, 2026 [SimpleX Public Names — a Name Nobody Can Take From You](./20260722-simplex-public-names.md)
+
+You can now give your channel or business a test SimpleX name that people can remember and nobody can take from you. Test names are free in v7-beta.
+
+---
+
+Apr 30, 2026 [SimpleX Channels, SimpleX Network Consortium and Community Crowdfunding - to Preserve Freedom of Speech](./20260430-simplex-channels-v6-5-consortium-crowdfunding-freedom-of-speech.md)
+
+Freedom of speech needs infrastructure that protects it by design - protocols, governance and funding.
+
+v6.5 release brings SimpleX Channels: a new model for online publishing built for participation privacy.
+
+---
+
Jul 29, 2025 [SimpleX Chat v6.4.1: welcome your contacts, review members to protect groups, and more.](./20250729-simplex-chat-v6-4-1-welcome-contacts-protect-groups-app-security.md)
What's new in v6.4.1:
diff --git a/blog/images/20260722-connect-name.png b/blog/images/20260722-connect-name.png
new file mode 100644
index 0000000000..7e835073ff
Binary files /dev/null and b/blog/images/20260722-connect-name.png differ
diff --git a/blog/images/20260722-phone-name-light.webp b/blog/images/20260722-phone-name-light.webp
new file mode 100644
index 0000000000..aa9f81918f
Binary files /dev/null and b/blog/images/20260722-phone-name-light.webp differ
diff --git a/blog/images/20260722-phone-name.webp b/blog/images/20260722-phone-name.webp
new file mode 100644
index 0000000000..df812bead6
Binary files /dev/null and b/blog/images/20260722-phone-name.webp differ
diff --git a/blog/images/20260722-register-name.png b/blog/images/20260722-register-name.png
new file mode 100644
index 0000000000..d64bb21507
Binary files /dev/null and b/blog/images/20260722-register-name.png differ
diff --git a/bots/api/COMMANDS.md b/bots/api/COMMANDS.md
index d14435cabd..463dd4088b 100644
--- a/bots/api/COMMANDS.md
+++ b/bots/api/COMMANDS.md
@@ -283,20 +283,21 @@ Send messages.
- sendRef: [ChatRef](./TYPES.md#chatref)
- liveMessage: bool
- ttl: int?
+- signMessages: bool
- composedMessages: [[ComposedMessage](./TYPES.md#composedmessage)]
**Syntax**:
```
-/_send `. Because embedding is still open, it loads no matter which address you test from, so you can adjust the page until it looks right.
+
+## Step 5. Set the webpage URL and lock it down
+
+Once the page works, go back to **Channel webpage** in the app:
+
+- Under **Enter webpage URL**, type the address where the page is published, for example `https://example.com/my-channel`.
+- Turn **Allow anyone to embed** off if you don't want other sites to be able to show your channel preview. Leave it on if you're happy for anyone to embed it.
+- Tap **Save**.
+
+The URL now appears as a link in your channel info that every subscriber can see. If you turned embedding off, the relay also restricts the preview to your own domain.
+
+## Customizing the preview
+
+You can add optional `data-*` attributes to the `
` to change how it looks. Only `data-channel-id` and `data-relay-domains` are required, and both are already in the generated code.
+
+| Attribute | Values | Default | What it does |
+| --- | --- | --- | --- |
+| `data-channel-id` | channel ID (from the app) | none | Required. Identifies the channel to load. |
+| `data-relay-domains` | comma-separated domains | none | Required. Relay domains that serve the preview, tried in order. |
+| `data-channel-link` | channel link | none | Enables the "Join" button and QR code. Recommended. |
+| `data-app-download-buttons` | `on`, `off` | `on` | Shows or hides the app download buttons. |
+| `data-color-scheme` | `light`, `dark`, `site` | `light` | Color theme. `site` follows your page's theme (it uses dark styling when a parent element has the `dark` CSS class). |
+| `data-light-background` | CSS color | `#ffffff` | Background color in light mode. |
+| `data-dark-background` | CSS color | `#000832` | Background color in dark mode. |
+| `data-relay-scheme` | `https`, `http` | `https` | Protocol used to load the preview from the relays. Leave it as `https`. |
+
+For example, here's a dark theme with a custom background and the download buttons hidden:
+
+```html
+
+
+```
+
+## Good to know
+
+The preview updates on its own. The relays republish channel content periodically, so the page picks up new messages without any change on your side. It's a read-only snapshot, so visitors can't post to it.
+
+Only what the channel already shows publicly is included: recent messages, member display names and avatars, reactions, and the subscriber count. Deleted and disappearing messages are never published.
+
+If your channel is served by more than one relay, all of them are listed in `data-relay-domains`. The script tries them in order, so the preview still loads when one relay is unavailable.
+
+## If something doesn't work
+
+If the preview area stays empty, check that the page is hosted on the same domain as the URL you set in Step 5, or turn **Allow anyone to embed** back on while you sort it out. The relay only lets that domain load the preview.
+
+If the app says "Used chat relays do not support webpages.", the relays hosting your channel don't support this feature yet, so no code can be generated.
+
+If there's no **Channel webpage** button, remember that it only appears for channel owners on channels hosted on relays.
diff --git a/docs/guide/diagrams/simplex-name-steps.mmd b/docs/guide/diagrams/simplex-name-steps.mmd
new file mode 100644
index 0000000000..ca19d3c6f3
--- /dev/null
+++ b/docs/guide/diagrams/simplex-name-steps.mmd
@@ -0,0 +1,19 @@
+flowchart TD
+ S([Start]) --> A["Step 1: Create a wallet
save your recovery phrase"] + A --> B["Step 2: Register the name
connect wallet, search, choose years"] + B --> C["On Create your profile, paste your link into
SimpleX contact (@name) or SimpleX channel (#name)"] + C --> H["Confirm: two transactions,
60 seconds apart"] + H --> I["Step 3: search or type your name
shows 'Unconfirmed name'"] + I --> D{"A contact or a channel?"} + D -->|"@name (contact)"| J1["Step 4: set Your SimpleX name
in your SimpleX address"] + D -->|"#name (channel)"| J2["Step 4: set SimpleX name
in the channel"] + J1 --> K["Step 5: from another device,
search or type the name"] + J2 --> K + K --> Z([Connected. Name verified.]) + + classDef start fill:#f4ecf7,stroke:#8e44ad,color:#4a235a; + classDef step fill:#eaf2fb,stroke:#2e86de,color:#1b3a5b; + classDef ok fill:#d5f5e3,stroke:#27ae60,color:#145a32; + class S start; + class Z ok; + class A,B,C,H,I,J1,J2,K step; diff --git a/docs/guide/diagrams/simplex-name-steps.svg b/docs/guide/diagrams/simplex-name-steps.svg new file mode 100644 index 0000000000..4d062ec1c2 --- /dev/null +++ b/docs/guide/diagrams/simplex-name-steps.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/guide/images/before-we-start.png b/docs/guide/images/before-we-start.png new file mode 100644 index 0000000000..eb853fcd96 Binary files /dev/null and b/docs/guide/images/before-we-start.png differ diff --git a/docs/guide/images/create-your-profile.png b/docs/guide/images/create-your-profile.png new file mode 100644 index 0000000000..2d5e96d9ee Binary files /dev/null and b/docs/guide/images/create-your-profile.png differ diff --git a/docs/guide/images/register-name.png b/docs/guide/images/register-name.png new file mode 100644 index 0000000000..94584f54df Binary files /dev/null and b/docs/guide/images/register-name.png differ diff --git a/docs/guide/register-simplex-name.md b/docs/guide/register-simplex-name.md new file mode 100644 index 0000000000..366661b7e5 --- /dev/null +++ b/docs/guide/register-simplex-name.md @@ -0,0 +1,123 @@ +--- +title: Registering a SimpleX name +--- + +# Registering a SimpleX name + +A SimpleX name lets people reach you by typing a short `@name` instead of pasting +a long link. You register the name on a website and add your SimpleX link to it, +then claim the name in the app, to connect it with your SimpleX address or +channel name. + +> Names currently run on a testing network. The registration page is +> [testing-names.simplex.chat](https://testing-names.simplex.chat) and names end +> in `.testing`. The steps stay the same when the main names launch. + +## What you need + +- A crypto wallet such as MetaMask. +- The SimpleX app. +- A link for the name to open: your **contact address** (for one-to-one chats), + your **channel link** (to join a channel), or both. + +## How it works + +Setting up a name takes two parts. On the website you register the name and add +your link, so people can find your link by name. In the app you set the same name +on your profile - to prevent any other names from opening your profile or channel. + + + +## Step 1. Create a wallet + +Install MetaMask (browser extension or mobile app) and create a wallet. Write +down your recovery phrase somewhere safe and offline, as anyone with that phrase +controls your names. + +On the testing network you need a small amount of test ETH to pay network fees. + +## Step 2. Register the name and add your link + +Open the registration page and tap **Connect** to link your wallet. Type the +name you want in **Search for a name** and open it. Choose how many years to +register for, then tap **Next**. Names are currently 6 characters or more, and +some names are reserved. + + + +On **Create your profile**, paste your SimpleX link into the matching field: + + + +- **SimpleX contact** for one-to-one chats. Copy your address from the app + (**Create SimpleX address**) and paste it here. People reach it with `@name`. +- **SimpleX channel** for a channel. Copy your **Channel link** and paste it here. + People join it with `#name`. +- **Advanced usage:** fill both to use one name for your chat (`@name`) and your + channel (`#name`). + +Then tap **Next**. + +Finally, tap **Begin** and complete the three steps the site shows: + +> Before we start. Registering your name takes three steps: +> 1. Complete a transaction to begin the timer. +> 2. Wait 60 seconds for the timer to complete. +> 3. Complete a second transaction to secure your name. + +These two transactions protect the name you are registering. The first records +only a secret code for the name, not the name itself, so nobody watching the +blockchain can see which name you want. The wait lets that first transaction +settle, and the second transaction then reveals and claims the name. Without this +two-step process, someone could see your registration in progress and grab the +name before you. + + + +## Step 3. Check what the app sees + +Copy your `#name.testing` (or `@name.testing`). Paste the name into the search bar, or simply type it. + +The app reports that the name is registered but not yet added to your profile: + +> Unconfirmed name. The SimpleX name is registered, but not added to profile. +> Please add it to your address or channel profile, if you are the owner. + +This is expected, and confirms the name points at your link. The next step +finishes the setup. + +## Step 4. Claim the name in the app + +Set the name on the same profile the record points at. + +- For your **contact address**, open your SimpleX address, tap **Get SimpleX + name**, enter the name, and save. +- For your **channel**, open the channel information, tap **Get SimpleX name** (under + **Channel link**), enter the name, and save. + +This proves to people who connect to you that `#name.testing` (or `@name.testing`) is your name. + +## Step 5. Connect by name + +On another device, copy `#name.testing` (or `@name.testing`). Paste the name into the search bar, or simply type it. This time the app connects, and the name +shows a check mark next to it. + +You can paste the name in your own device too - the app will warn you that it is your own name. + +Anyone can now reach you by name, and their app confirms it is really you. + +## If something doesn't work + +| Message | Meaning | Fix | +|---|---|---| +| Unconfirmed name | The name points at a link, but the link's profile does not claim the name yet. | Do step 4: set the name on the profile it points at. | +| Name not found | No name is registered. | Check the spelling, or register it (step 2). | +| No valid link | The name has no contact or channel link. | Add a link to the name on the website, on its **Records** tab. | +| Error saving name | You tried to claim a name that has no matching link on the website. | Add your contact address or channel link to the name, then set the name again. | +| None of your servers are set to resolve SimpleX names | No server in the app is set to resolve names. | In server settings, turn on **To resolve names** for a server. | + +## See also + +- [Making connections](./making-connections.md) +- [Chat profiles](./chat-profiles.md) +- [Channel webpage](./channel-webpage.md) diff --git a/docs/lang/fr/TRANSLATIONS.md b/docs/lang/fr/TRANSLATIONS.md index 1e216900e7..cb7de707ff 100644 --- a/docs/lang/fr/TRANSLATIONS.md +++ b/docs/lang/fr/TRANSLATIONS.md @@ -26,7 +26,7 @@ Ce document est créé pour accélérer ce processus, et partager quelques astuc 2. Certaines des chaînes n'ont pas besoin d'être traduites, mais elles doivent quand même être copiées - il y a un bouton dans l'interface weblate pour cela : -
+
3. Weblate propose également des suggestions automatiques qui peuvent accélérer le processus. Parfois, elles peuvent être utilisées telles quelles, parfois elles nécessitent quelques retouches - cliquez pour les utiliser dans les traductions.
@@ -34,7 +34,7 @@ Ce document est créé pour accélérer ce processus, et partager quelques astuc
5. Quand vous traduisez [l'app iOS](https://hosted.weblate.org/projects/simplex-chat/ios/), la plupart des chaînes de caractères sont identiques, elles peuvent être copiées en un clic dans la section Glossaire. L'indice visuel que cela est possible est que la chaîne source entière est surlignée en jaune. De nombreuses autres chaînes sont très similaires, elles ne diffèrent que par la syntaxe d'interpolation ou la façon dont la police en gras est utilisée - elles ne nécessitent qu'une édition minimale. Certaines chaînes sont propres à la plate-forme iOS. Elles doivent être traduites séparément.
-
+
## Une fois la traduction terminée
diff --git a/docs/lang/pl/SERVER.md b/docs/lang/pl/SERVER.md
index f4bffc1bcc..e3ffe40c16 100644
--- a/docs/lang/pl/SERVER.md
+++ b/docs/lang/pl/SERVER.md
@@ -482,4 +482,4 @@ Możliwe jest również udostępnienie adresu swojego serwera znajomym, pozwalaj
_Uwaga_: Do obsługi haseł wymagany jest serwer SMP w wersji 4.0. Jeśli już posiadasz serwer, możesz dodać hasło do niego poprzez wpisanie hasła do pliku INI serwera.
-
+
diff --git a/docs/lang/pl/TRANSLATIONS.md b/docs/lang/pl/TRANSLATIONS.md
index 36daa5a148..531177dba5 100644
--- a/docs/lang/pl/TRANSLATIONS.md
+++ b/docs/lang/pl/TRANSLATIONS.md
@@ -39,7 +39,7 @@ Kroki są następujące:
2. Niektóre ciągi nie wymagają tłumaczenia, ale nadal trzeba je skopiować - w interfejsie użytkownika weblate znajduje się odpowiedni przycisk:
-
+
3. Weblate posiada również automatyczne sugestie, które mogą przyspieszyć ten proces. Czasami mogą być używane w niezmienionej formie, a czasami wymagają edycji - kliknij, aby użyć ich w tłumaczeniach.
@@ -68,7 +68,7 @@ My wtedy:
Serdecznie dziękujemy! To ogromny wysiłek i wielka pomoc dla rozwoju sieci SimpleX.
-
+
## Częste błędy w tłumaczeniu
diff --git a/docs/lang/pl/WEBRTC.md b/docs/lang/pl/WEBRTC.md
index d279491fb8..e291d887b5 100644
--- a/docs/lang/pl/WEBRTC.md
+++ b/docs/lang/pl/WEBRTC.md
@@ -139,7 +139,7 @@ To tyle - teraz możesz wykonywać połączenia audio i wideo za pośrednictwem
2. W sekcji **Build up ICE Server List** dodaj:
- 
+ 
- `STUN: stun::` kliknij `Add STUN`
- `TURN: turn::`, `Username: `, `Credential: ` kliknij `Add TURN`
@@ -148,11 +148,11 @@ To tyle - teraz możesz wykonywać połączenia audio i wideo za pośrednictwem
3. Powinieneś zobaczyć swoje serwery w sekcji **ICE server list**. Jeśli wszystko jest skonfigurowane poprawnie, naciśnij `Start test`:
- 
+ 
4. W sekcji **Results** powinieneś zobaczyć coś takiego:
- 
+ 
Jeśli wyniki pokazują `srflx` i `relay`, wszystko jest skonfigurowane poprawnie!
diff --git a/docs/protocol/channels-overview.md b/docs/protocol/channels-overview.md
index d4cd2d2965..7a55f8b6e5 100644
--- a/docs/protocol/channels-overview.md
+++ b/docs/protocol/channels-overview.md
@@ -182,7 +182,7 @@ The low-level protocol supports multiple owners from the initial release. The ap
- **Subscribers** connect to relays and receive content. They cannot send messages by default, but can be given posting rights.
-Additional roles (moderator, admin, member, author) exist in the hierarchy and are inherited from the group protocol.
+Additional roles (moderator, admin, member, author) exist in the hierarchy and are inherited from the group protocol. The owner-signed roster tracks the promoted set - members, moderators, and admins; subscribers are observers until an owner promotes them.
For protocol-level detail - wire formats, message types, signing and verification mechanics, delivery pipeline - see [SimpleX Channels Protocol](./channels-protocol.md).
@@ -242,6 +242,7 @@ This threat model assumes the [SimpleX network threat model](https://github.com/
- Undetectably substitute content - subscribers on honest relays receive the original.
- Alter the channel's authoritative state on the owner's device.
- Substitute the channel profile or impersonate an owner - these require valid signatures.
+- Replay an old roster or role change to re-elevate a removed or demoted member for existing subscribers - they reject anything older than the roster version they applied (a new joiner with no prior roster can still be served an old one, until it syncs from another relay).
- Redirect subscribers to a different channel - the entity ID is validated across link and profile.
- Determine subscriber identity or network address - inherited from SMP transport.
- Correlate subscriber participation across channels - each connection uses independent SMP queues. The subscriber chooses their SMP router independently, so collusion between a relay and the relay's SMP router does not compromise connections through a different router.
diff --git a/docs/protocol/names-overview.md b/docs/protocol/names-overview.md
new file mode 100644
index 0000000000..e9fe33a791
--- /dev/null
+++ b/docs/protocol/names-overview.md
@@ -0,0 +1,271 @@
+Revision 1, 2026-07-14
+
+# SimpleX Public Names for Channels and Businesses
+
+## Table of contents
+
+- [Introduction](#introduction)
+ - [Names](#names)
+ - [Use cases](#use-cases)
+ - [On-chain registry](#on-chain-registry)
+ - [Privacy considerations](#privacy-considerations)
+- [Architecture](#architecture)
+ - [Names and records](#names-and-records)
+ - [Resolution](#resolution)
+ - [Private decentralized RPC layer](#private-decentralized-rpc-layer)
+ - [Claiming and verification](#claiming-and-verification)
+- [Differences from ENS](#differences-from-ens)
+- [Security](#security)
+ - [Design objectives](#design-objectives)
+ - [Threat model](#threat-model)
+ - [Current gaps](#current-gaps)
+- [Future work](#future-work)
+- [Conclusion](#conclusion)
+
+
+## Introduction
+
+The SimpleX network provides communication without user identifiers - people connect by exchanging links out of band. This protects private communication, but public entities - channels and businesses - need to be discoverable. Today this requires distributing a long link, which is impossible to remember and can be deleted by the router that hosts it. SimpleX public names provide memorability and ease of connection without adding user identifiers.
+
+### Names
+
+A SimpleX name is a human-readable name, registered on a public blockchain, that resolves to SimpleX links: `#example.simplex` opens a channel (for the `.simplex` namespace, the short variant `#example` can also be used for channel names) and `@example.simplex` connects to a contact or business address. One name can include both links - a business can publish `@example.simplex` for customer conversations and `#example.simplex` for its announcement channel from a single registration. Names support subnames (`support.example.simplex`). A separate test namespace (`.testing`) is deployed for early adopters before the main namespace launches.
+
+A name is not an account and not an identity. It is a record that maps a human-readable string to the links a channel or business already has, controlled by a cryptographic key that only its owner holds. The network does not use or require names; they are a discovery layer on top of it, described in this document.
+
+This document covers the naming layer built for [SimpleX Channels](./channels-overview.md) and the [SimpleX network](https://github.com/simplex-chat/simplexmq/blob/master/protocol/overview-tjr.md). For the user-facing registration steps see [Registering a SimpleX name](../guide/register-simplex-name.md); for protocol-level details see the resolver commands in the [SMP protocol](https://github.com/simplex-chat/simplexmq/blob/stable/protocol/simplex-messaging.md).
+
+### Use cases
+
+Names are intended for entities that are already public:
+
+- **Channels.** A channel reachable as `#example` can be easily shared in many ways - conversation, print, social media, and messages. If the channel's link is removed or blocked, the owner can point the name to a new link, and the channel remains reachable via the same name.
+
+- **Businesses and organizations.** A business address reachable as `@example.simplex` gives customers a way to start a conversation without scanning a QR code or trusting a link from a search result.
+
+- **Creators and public figures.** Anyone publishing to an audience can be reachable by name while their audience remains private.
+
+Names are opt-in and are only useful for public entities. Private users do not need them. Even when an entity uses a name, the network cannot track who connects to it - the communication graph remains private.
+
+### On-chain registry
+
+Names must be globally unique, so they require a shared registry. Every conventional registry design places names under an operator's control:
+
+- **A platform registry** (usernames in messaging apps) is owned by the operator: names can be revoked, impersonated, or reassigned, and the platform sees who looks up whom.
+
+- **DNS** is subject to domain seizure at the registrar and registry level, and requires registrant records.
+
+A record on a public blockchain has no operator: only the holder of the registration key can change what a name points to, and no authority can delete it. This mitigates censorship at these levels:
+
+- **SMP routers.** The router that hosts a link can delete it, and the link stops working for everyone who saved it. A name is not affected: the owner points it to a new link on a different router, and clients connect via the same name as before.
+
+- **Centralized registries.** An on-chain record cannot be revoked, because there is no intermediary.
+
+### Privacy considerations
+
+Names do not:
+
+- **Identify users.** There is no user directory, no requirement to register a name, and nothing links a name to the people who connect to it.
+
+- **Put communication on the chain.** The blockchain stores only the mapping from a name to links and optional public profile fields. Messages, membership, and channel content are never stored on the blockchain.
+
+- **Certify identity.** A verified name proves that the name's owner controls the address it points to - not who the owner is. It is the same trust model as a domain name.
+
+- **Replace links.** Links remain the primary and the more private connection mechanism, since resolving a name reveals interest in it to one resolver operator. Names are for public entities that choose to be contactable more easily.
+
+
+## Architecture
+
+### Names and records
+
+Names are lowercase labels of ASCII letters, digits, and single hyphens, forming domains under the `.simplex` top-level name (`example.simplex`, `my-channel.simplex`), with `.simplex` implied when omitted for channels: `#example` is interpreted as `#example.simplex`. The restricted alphabet prevents homograph attacks: visually identical names from mixed scripts cannot exist as distinct records.
+
+A name's on-chain record stores:
+
+- **Channel links and contact links** - each an ordered list, primary first. Multiple links give redundancy across SMP routers: clients try them in order, so the name remains usable if one router becomes unavailable. Client support for this redundancy is planned for the `.simplex` namespace launch.
+- **Optional profile fields** - a display name, website, location.
+- **Optional donation addresses** (Monero, Bitcoin, Ethereum, etc.) that apps can show to channel subscribers.
+
+Registration is a two-transaction commit-reveal process from the owner's wallet: the first transaction records only a hash, so an observer of the pending registration cannot see the name and front-run it; the second transaction reveals the name and completes the registration. The name is held as an ordinary token in the owner's wallet and is renewable and transferable. Subnames are created by the name's owner, are transferred together with the name, and cannot be separately sold - the same ownership model as DNS subdomains.
+
+### Resolution
+
+Connecting by name is two independent resolutions:
+
+1. **Name to link.** The client queries the on-chain record through the SimpleX network (next section) and obtains the channel or contact link.
+
+2. **Link to connection.** The link resolves through the existing SimpleX short-link protocol: the client retrieves the link's immutable data - cryptographically bound to the link's owner keys - and the entity's profile, and connects.
+
+The second step is unchanged from connecting by link. A name adds discoverability on top of the link protocol; it does not weaken the link's own verification, and everything a client checks when joining by link is still checked when joining by name.
+
+### Private decentralized RPC layer
+
+Reading blockchain state normally requires querying an RPC service, and in practice almost all applications - including wallets and name services - use a handful of centralized API providers. Those providers see every query, the account it concerns, and the querier's IP address, and can censor or falsify responses. Resolving names through such a provider would reveal every lookup and the client's IP address to a third party.
+
+SimpleX resolves names through the network itself. Operators can enable a *names role* on their SMP routers: a names router runs its own resolver process and its own Ethereum node, holding a full copy of the relevant chain state - operators must not share this backend with other operators. The lookup is a protocol command sent as ordinary SimpleX traffic:
+
+1. The client selects a names router among its configured servers and sends the lookup *through an SMP proxy operated by a different operator*, encrypted so the proxy cannot read it.
+2. The proxy forwards the lookup without access to its content; the names router responds from its local chain state.
+
+```mermaid
+sequenceDiagram
+ participant C as Client
+ participant P as SMP proxy
(operator A) + participant N as Names router
(operator B) + participant E as Ethereum node
(operator B, local) + + C->>P: lookup, encrypted for the names router + note over P: sees the client,
not the name + P->>N: forwarded lookup + note over N: sees the name,
not the client + N->>E: read name record (eth_call) + E-->>N: name record + N-->>P: response, encrypted for the client + P-->>C: name record: channel and contact links +``` + +The result is a knowledge split with no single observer: the proxy sees which client communicates with a names router, but not the name; the names router sees the name, but not which client sent the query - no client address, session, or identity. A passive network observer sees fixed-size encrypted blocks indistinguishable from other traffic. Clients also keep the set of parties that see a lookup minimal: a query is sent to one names router, and after an authoritative response the client does not repeat the name to other servers. + +This layer is not specific to names. Private access to blockchain state via independent operators is a network capability that can be used in other contexts in the future. + +### Claiming and verification + +A name is trustworthy when: + +1. **The on-chain record points to the link.** Only the name owner's wallet key can set this. +2. **The link's profile claims the name.** Only the link owner's keys can publish this, and the claim is signed by the link's owner key, binding it to that specific link. + +For name resolution to succeed, SimpleX clients require both to be true. This mutual binding prevents abuse, such as: + +- Registering a name that points to someone else's address. The profile does not claim the name, so clients refuse to connect to it. +- Claiming a name in a profile without owning it. The on-chain record does not point to that profile's address, so the claim fails verification. + +Apps display the outcome next to the name - verified (the record and the claim match), failed, or not yet verified - and can re-verify on demand or automatically. Verification is a fresh resolution through the private RPC layer, so it reflects the current on-chain state. + +Names are used only to establish connections, not to deliver messages. Once connected, a contact or channel subscription is an ordinary SimpleX connection, independent of the name. A name expiring or being transferred affects future connections only; existing conversations and subscriptions are not affected. + + +## Differences from ENS + +The on-chain layer is the SimpleX Name Service (SNS), a fork of the [Ethereum Name Service](https://ens.domains) (ENS). ENS is the most widely used decentralized naming system, and SNS retains its core design: the registry and resolver contracts, commit-reveal registration, and expiry-based ownership. + +Each top-level name (`.testing`, `.simplex`) is an independent deployment of the same contracts: + +```mermaid +flowchart TD + CT["Controller
commit-reveal registration"] + RG["Registrar
name tokens, on-chain name index"] + PR["Resolver
simplex.contact / simplex.channel records"] + R["Registry
owner and resolver of every name"] + MR["Metadata renderer
token metadata as on-chain JSON + SVG"] + SR["Subname registrar
creates and indexes subnames"] + + CT -->|registers names| RG + CT -->|writes records| PR + RG -->|sets name ownership| R + RG -->|renders tokens| MR + SR -->|owns subname nodes| R +``` + +ENS, however, is not fully decentralized in use. Its applications depend on two off-chain services: an indexer (the subgraph) for queries such as listing the names held by an address (without it the ENS app is unusable), and a hosted metadata service to render name tokens in wallets. SNS removes both dependencies, and simplifies the ownership model: + +1. **No indexer.** The SNS contracts index names on-chain: reverse lookup from an address to the names it holds, from a token to its plaintext label, and from a name to its subnames are all direct contract reads. Every view in the SNS web app (currently, the app for test names is https://testing-names.simplex.chat) - the list of owned names, their subnames, and each name's records - is served by plain `eth_call`s against an Ethereum RPC. + +2. **Fully on-chain tokens.** A name's token metadata and image are generated by the contract as inline JSON and SVG. There is no metadata server; wallets render the name from chain data alone. + +3. **No name wrapper, no separate subname ownership.** ENS's wrapper system lets subnames be split off and owned independently, at the cost of a second token standard and a complex permission system. SNS subnames are owned together with the name and are transferred with it (the DNS model), removing the need for the wrapper. + +Resolution also differs. ENS names are resolved by applications through their RPC providers, so lookups are as centralized and observable as the provider. SNS records are read through the private RPC layer described above: many independent operators hold the chain state, and no single party sees who resolves which name. + +The result is a naming system with no off-chain services: registration, ownership, enumeration, rendering, and resolution are all either on-chain or served by the SimpleX network itself. + +The current implementation uses a web app for registration, which accesses the chain via a centralized RPC provider. We plan to add name purchases to the SimpleX apps, using the same decentralized blockchain access that is already used for name resolution. + + +## Security + +### Design objectives + +1. **Non-custodial.** Only the holder of the name's key can change or transfer the record; there is no registrar, operator, or intermediary with override authority. +2. **No infrastructure censorship.** A name does not depend on any single router: the links it points to can be replaced without changing the name, and resolution uses chain state held by many independent operators. +3. **Impersonation resistance.** A name is shown as verified only when the on-chain record and the signed claim in the link's profile match. +4. **Lookup privacy.** No single party observes both the user and the name being resolved. +5. **Availability.** A record can list multiple links across routers, and any names-capable router of the user's choosing can respond to a lookup. + +### Threat model + +This threat model assumes the [SimpleX network threat model](https://github.com/simplex-chat/simplexmq/blob/stable/protocol/security.md) and the [channels threat model](./channels-overview.md#threat-model), and addresses the naming layer. + +**A compromised names router (or its chain backend)** + +*can:* + +- Deny that a name exists, or serve a stale record, to the clients that query it. Detectable by resolving through a different operator's router. +- Serve a false record - effective only against a client that queries this router *and* only if the false record's target cooperates by claiming the name, since the claim check runs against the attacker-supplied record. Resolver agreement across operators ([future work](#future-work)) makes this require collusion of the queried operators. +- Observe which names are looked up, and how often. + +*cannot:* + +- Learn who is looking up a name - it never sees the client's address, session, or identity. +- Alter the on-chain record, or affect clients resolving through other routers. +- Affect existing connections - they do not depend on names. + +**An SMP proxy forwarding lookups** + +*can:* + +- See that a client communicates with a names router (which is an ordinary SMP router). + +*cannot:* + +- See that a request forwarded to a destination router is a name resolution request. +- See the name being looked up, or the response - both are encrypted between client and names router. + +**An impersonator** + +*can:* + +- Register a confusingly similar name. The restricted alphabet keeps such names visibly different - homographs are not possible. + +*cannot:* + +- Register a visually identical variant of an existing name using other scripts or invisible characters. +- Achieve verified status for a name pointing to someone else's address, or for an address whose name points elsewhere. + +**Compromise of the owner's wallet key** + +An attacker holding the registration key can repoint or transfer the name. New lookups then resolve to the attacker's links; the owner's profile claim no longer matches the record, so clients verifying the owner's profile see a failure. Existing connections are unaffected. Protecting the registration key is the owner's responsibility, the same as protecting the channel's own keys. An expired name that is not renewed can also be registered by someone else, so the key must be backed up and the name renewed on time. + +**A passive network observer** + +*can:* + +- See SimpleX traffic between clients and routers. + +*cannot:* + +- Distinguish name lookups from any other traffic, or learn which names anyone resolves. Inherited from SMP transport. + +### Current gaps + +1. **Single-resolver lookups.** A client currently accepts the response of one names router per lookup. Cross-checking two operators' resolvers is designed but not implemented - see below. +2. **No state proofs.** The names router is trusted to report chain state correctly; responses do not yet include proofs verifiable against a chain header. +3. **Self-hosted routers.** All pre-configured routers support name resolution, but most self-hosted routers do not support it yet. Name resolution requires at least one configured server with the names role. + + +## Future work + +- **Two-resolver agreement.** Resolve each name through two independent operators via two different proxies and compare the responses: a match is trusted; a mismatch is shown as a warning and the record is not used. This removes the single-resolver trust noted above and makes record substitution require cross-operator collusion. + +- **State proofs.** Responses including Merkle proofs of Ethereum state, verified by the client - removing the need to trust the resolver, with or without agreement. + +- **Main namespace launch.** The `.testing` namespace is deployed for early adopters; the `.simplex` namespace launches after the testing period. + +- **Registration via an app.** Registration currently requires an on-chain transaction from a wallet. + +- **DNS-based names.** The client already parses arbitrary domains (`example.com`) as web links. In the future, it will be possible to register owned domains in the SNS contract to use them as channel and contact names (`#example.com` and `@example.com`). + + +## Conclusion + +SimpleX names give channels and businesses memorable addresses that do not depend on any single server and cannot be revoked by a platform or registrar. Resolution runs through the SimpleX network, so no party observes who looks up which name. The naming system is fully decentralized on-chain, with no indexer or metadata service, and access to it is private, with no RPC provider observing requests. Names are optional and used only by public entities; private communication in SimpleX remains identifier-free. diff --git a/docs/rfcs/2026-08-05-markdown-hyperlink-connect.md b/docs/rfcs/2026-08-05-markdown-hyperlink-connect.md new file mode 100644 index 0000000000..2fe40755e8 --- /dev/null +++ b/docs/rfcs/2026-08-05-markdown-hyperlink-connect.md @@ -0,0 +1,33 @@ +# Connecting via a SimpleX link written as a markdown hyperlink + +## Problem + +Pasting a short SimpleX link written as a markdown hyperlink — `[label](https://smp6.simplex.im/a#...)` — into the chat list search, the new chat sheet search, or "Tap to paste link" fails with "Invalid connection link" instead of connecting. + +## Cause + +`markdownP` parses such a link into a single fragment whose `format` is `SimplexLink` but whose `text` is the whole markdown source: + +``` +[{"format":{"type":"simplexLink","showText":"label","linkType":"contact", + "simplexUri":"simplex:/a#...?h=smp6.simplex.im","smpHosts":["smp6.simplex.im"]}, + "text":"[label](https://smp6.simplex.im/a#...)"}] +``` + +`strConnectTarget` returns that `text` as the string to connect with. For a bare link `text` is the link, so it works; for a hyperlink it is `[label](link)`, which the core rejects as `InvalidConnReq`. + +## Design + +Use `simplexUri` — the link the parser already resolved — when the fragment came from the hyperlink parser, and keep using `text` otherwise: + +``` +text = if showText != null then simplexUri else text +``` + +`showText` is an exact discriminator, not a heuristic: `simplexUriFormat` is called with `Just t` only from `sowLinkP` (the hyperlink parser) and with `Nothing` from `wordMD` (bare link). Gating on it leaves every bare-link path unchanged. + +This also matches how the chat item renderer already resolves the same format — `TextItemView.kt` takes `simplexUri`, never the fragment `text`, when `showText` is set. `strConnectTarget` was the outlier. + +## Scope + +Short links only. `sowLinkP` rejects a full link inside a hyperlink (`fail "full SimpleX link in hyperlink"`), so `[label](full-link)` yields no formatting at all and never reaches this code — it stays treated as search text, as before. Bare full links are unaffected. diff --git a/images/github-banner.jpg b/images/github-banner.jpg new file mode 100644 index 0000000000..ef3cb5e6f5 Binary files /dev/null and b/images/github-banner.jpg differ diff --git a/packages/simplex-chat-client/types/typescript/package.json b/packages/simplex-chat-client/types/typescript/package.json index 756e181307..01d88ab770 100644 --- a/packages/simplex-chat-client/types/typescript/package.json +++ b/packages/simplex-chat-client/types/typescript/package.json @@ -1,6 +1,6 @@ { "name": "@simplex-chat/types", - "version": "0.9.0", + "version": "0.10.3", "description": "TypeScript types for SimpleX Chat bot libraries", "main": "dist/index.js", "types": "dist/index.d.ts", diff --git a/packages/simplex-chat-client/types/typescript/src/commands.ts b/packages/simplex-chat-client/types/typescript/src/commands.ts index d1b89ffe27..3f4e3ad7ee 100644 --- a/packages/simplex-chat-client/types/typescript/src/commands.ts +++ b/packages/simplex-chat-client/types/typescript/src/commands.ts @@ -89,6 +89,7 @@ export interface APISendMessages { sendRef: T.ChatRef liveMessage: boolean ttl?: number // int + signMessages: boolean composedMessages: T.ComposedMessage[] // non-empty } @@ -96,7 +97,7 @@ export namespace APISendMessages { export type Response = CR.NewChatItems | CR.ChatCmdError export function cmdString(self: APISendMessages): string { - return '/_send ' + T.ChatRef.cmdString(self.sendRef) + (self.liveMessage ? ' live=on' : '') + (self.ttl ? ' ttl=' + self.ttl : '') + ' json ' + JSON.stringify(self.composedMessages) + return '/_send ' + T.ChatRef.cmdString(self.sendRef) + (self.liveMessage ? ' live=on' : '') + (self.ttl ? ' ttl=' + self.ttl : '') + (self.signMessages ? ' sign=on' : '') + ' json ' + JSON.stringify(self.composedMessages) } } @@ -495,12 +496,12 @@ export namespace APIAddContact { } } -// Determine SimpleX link type and if the bot is already connected via this link. +// Determine SimpleX link type and if the bot is already connected via this link or name. // Network usage: interactive. export interface APIConnectPlan { userId: number // int64 - connectionLink?: string - resolveKnown: boolean + connectTarget?: string + resolveMode: T.PlanResolveMode linkOwnerSig?: T.LinkOwnerSig } @@ -508,7 +509,7 @@ export namespace APIConnectPlan { export type Response = CR.ConnectionPlan | CR.ChatCmdError export function cmdString(self: APIConnectPlan): string { - return '/_connect plan ' + self.userId + ' ' + self.connectionLink + return '/_connect plan ' + self.userId + ' ' + self.connectTarget } } @@ -528,18 +529,18 @@ export namespace APIConnect { } } -// Connect via SimpleX link as string in the active user profile. +// Connect via SimpleX link or name as string in the active user profile. // Network usage: interactive. export interface Connect { incognito: boolean - connLink_?: string + connTarget_?: string } export namespace Connect { export type Response = CR.SentConfirmation | CR.ContactAlreadyExists | CR.SentInvitation | CR.ChatCmdError export function cmdString(self: Connect): string { - return '/connect' + (self.connLink_ ? ' ' + self.connLink_ : '') + return '/connect' + (self.connTarget_ ? ' ' + self.connTarget_ : '') } } diff --git a/packages/simplex-chat-client/types/typescript/src/responses.ts b/packages/simplex-chat-client/types/typescript/src/responses.ts index 0fcf0e6eca..f54acfbeb1 100644 --- a/packages/simplex-chat-client/types/typescript/src/responses.ts +++ b/packages/simplex-chat-client/types/typescript/src/responses.ts @@ -186,6 +186,8 @@ export namespace CR { type: "connectionPlan" user: T.User connLink: T.CreatedConnLink + planSimplexName?: T.SimplexNameInfo + otherSimplexName?: T.SimplexNameInfo connectionPlan: T.ConnectionPlan } diff --git a/packages/simplex-chat-client/types/typescript/src/types.ts b/packages/simplex-chat-client/types/typescript/src/types.ts index 883728f943..e2e30d43bc 100644 --- a/packages/simplex-chat-client/types/typescript/src/types.ts +++ b/packages/simplex-chat-client/types/typescript/src/types.ts @@ -66,6 +66,7 @@ export type AgentErrorType = | AgentErrorType.NTF | AgentErrorType.XFTP | AgentErrorType.FILE + | AgentErrorType.NO_NAME_SERVERS | AgentErrorType.PROXY | AgentErrorType.RCP | AgentErrorType.BROKER @@ -84,6 +85,7 @@ export namespace AgentErrorType { | "NTF" | "XFTP" | "FILE" + | "NO_NAME_SERVERS" | "PROXY" | "RCP" | "BROKER" @@ -136,6 +138,10 @@ export namespace AgentErrorType { fileErr: FileErrorType } + export interface NO_NAME_SERVERS extends Interface { + type: "NO_NAME_SERVERS" + } + export interface PROXY extends Interface { type: "PROXY" proxyServer: string @@ -283,6 +289,7 @@ export interface BusinessChatInfo { chatType: BusinessChatType businessId: string customerId: string + businessDomain?: SimplexDomainClaim } export enum BusinessChatType { @@ -835,7 +842,7 @@ export interface CIMeta { editable: boolean forwardedByMember?: number // int64 showGroupAsSender: boolean - msgSigned?: MsgSigStatus + msgVerified?: MsgVerified createdAt: string // ISO-8601 timestamp updatedAt: string // ISO-8601 timestamp } @@ -1021,7 +1028,6 @@ export type ChatErrorType = | ChatErrorType.NoSndFileUser | ChatErrorType.NoRcvFileUser | ChatErrorType.UserUnknown - | ChatErrorType.ActiveUserExists | ChatErrorType.UserExists | ChatErrorType.ChatRelayExists | ChatErrorType.DifferentActiveUser @@ -1037,6 +1043,8 @@ export type ChatErrorType = | ChatErrorType.ChatNotStopped | ChatErrorType.ChatStoreChanged | ChatErrorType.InvalidConnReq + | ChatErrorType.SimplexDomainNotReady + | ChatErrorType.NotResolvedLocally | ChatErrorType.UnsupportedConnReq | ChatErrorType.ConnReqMessageProhibited | ChatErrorType.ContactNotReady @@ -1099,7 +1107,6 @@ export namespace ChatErrorType { | "noSndFileUser" | "noRcvFileUser" | "userUnknown" - | "activeUserExists" | "userExists" | "chatRelayExists" | "differentActiveUser" @@ -1115,6 +1122,8 @@ export namespace ChatErrorType { | "chatNotStopped" | "chatStoreChanged" | "invalidConnReq" + | "simplexDomainNotReady" + | "notResolvedLocally" | "unsupportedConnReq" | "connReqMessageProhibited" | "contactNotReady" @@ -1197,10 +1206,6 @@ export namespace ChatErrorType { type: "userUnknown" } - export interface ActiveUserExists extends Interface { - type: "activeUserExists" - } - export interface UserExists extends Interface { type: "userExists" contactName: string @@ -1273,6 +1278,16 @@ export namespace ChatErrorType { type: "invalidConnReq" } + export interface SimplexDomainNotReady extends Interface { + type: "simplexDomainNotReady" + simplexDomain: SimplexDomain + simplexDomainError: SimplexDomainError + } + + export interface NotResolvedLocally extends Interface { + type: "notResolvedLocally" + } + export interface UnsupportedConnReq extends Interface { type: "unsupportedConnReq" } @@ -2163,6 +2178,7 @@ export type ErrorType = | ErrorType.LARGE_MSG | ErrorType.EXPIRED | ErrorType.INTERNAL + | ErrorType.NAME | ErrorType.DUPLICATE_ export namespace ErrorType { @@ -2181,6 +2197,7 @@ export namespace ErrorType { | "LARGE_MSG" | "EXPIRED" | "INTERNAL" + | "NAME" | "DUPLICATE_" interface Interface { @@ -2247,6 +2264,11 @@ export namespace ErrorType { type: "INTERNAL" } + export interface NAME extends Interface { + type: "NAME" + nameErr: NameErrorType + } + export interface DUPLICATE_ extends Interface { type: "DUPLICATE_" } @@ -2375,6 +2397,11 @@ export interface FileTransferMeta { cancelled: boolean } +export enum FileType { + Normal = "normal", + Roster = "roster", +} + export type Format = | Format.Bold | Format.Italic @@ -2503,6 +2530,7 @@ export interface FullGroupPreferences { support: SupportGroupPreference sessions: RoleGroupPreference comments: CommentsGroupPreference + signMessages: GroupPreference commands: ChatBotCommand[] } @@ -2577,6 +2605,7 @@ export enum GroupFeature { Support = "support", Sessions = "sessions", Comments = "comments", + SignMessages = "signMessages", } export enum GroupFeatureEnabled { @@ -2605,9 +2634,11 @@ export interface GroupInfo { uiThemes?: UIThemeEntityOverrides customData?: object groupSummary: GroupSummary + rosterVersion?: number // int64 membersRequireAttention: number // int viaGroupLinkUri?: string groupKeys?: GroupKeys + groupDomainVerified?: boolean } export interface GroupKeys { @@ -2716,6 +2747,7 @@ export interface GroupMember { supportChat?: GroupSupportChat memberPubKey?: string relayLink?: string + memberVerifiedCode?: SecurityCode } export interface GroupMemberAdmission { @@ -2784,6 +2816,7 @@ export interface GroupPreferences { support?: SupportGroupPreference sessions?: RoleGroupPreference comments?: CommentsGroupPreference + signMessages?: GroupPreference commands?: ChatBotCommand[] } @@ -2978,12 +3011,15 @@ export interface LocalProfile { displayName: string fullName: string shortDescr?: string + description?: string image?: string contactLink?: string preferences?: Preferences peerType?: ChatPeerType localBadge?: LocalBadge localAlias: string + contactDomain?: SimplexDomainClaim + contactDomainVerified?: boolean } export enum MemberCriteria { @@ -3177,6 +3213,48 @@ export enum MsgSigStatus { SignedNoKey = "signedNoKey", } +export type MsgVerified = MsgVerified.Signed | MsgVerified.SigMissing + +export namespace MsgVerified { + export type Tag = "signed" | "sigMissing" + + interface Interface { + type: Tag + } + + export interface Signed extends Interface { + type: "signed" + sigStatus: MsgSigStatus + } + + export interface SigMissing extends Interface { + type: "sigMissing" + } +} + +export type NameErrorType = NameErrorType.NO_RESOLVER | NameErrorType.NOT_FOUND | NameErrorType.RESOLVER + +export namespace NameErrorType { + export type Tag = "NO_RESOLVER" | "NOT_FOUND" | "RESOLVER" + + interface Interface { + type: Tag + } + + export interface NO_RESOLVER extends Interface { + type: "NO_RESOLVER" + } + + export interface NOT_FOUND extends Interface { + type: "NOT_FOUND" + } + + export interface RESOLVER extends Interface { + type: "RESOLVER" + resolverErr: string + } +} + export type NetworkError = | NetworkError.ConnectError | NetworkError.TLSError @@ -3230,6 +3308,7 @@ export interface NewUser { profile?: Profile pastTimestamp: boolean userChatRelay: boolean + clientService: boolean } export interface NoteFolder { @@ -3294,6 +3373,12 @@ export interface PendingContactConnection { updatedAt: string // ISO-8601 timestamp } +export enum PlanResolveMode { + AllGroups = "allGroups", + Unknown = "unknown", + Never = "never", +} + export interface PrefEnabled { forUser: boolean forContact: boolean @@ -3329,11 +3414,13 @@ export interface Profile { displayName: string fullName: string shortDescr?: string + description?: string image?: string contactLink?: string preferences?: Preferences peerType?: ChatPeerType badge?: BadgeProof + contactDomain?: SimplexDomainClaim } export type ProxyClientError = @@ -3394,7 +3481,7 @@ export namespace ProxyError { export interface PublicGroupAccess { groupWebPage?: string - groupDomain?: string + groupDomainClaim?: SimplexDomainClaim domainWebPage: boolean allowEmbedding: boolean } @@ -3640,6 +3727,7 @@ export interface RcvFileTransfer { xftpRcvFile?: XFTPRcvFile fileInvitation: FileInvitation fileStatus: RcvFileStatus + fileType: FileType rcvFileInline?: InlineFileMode senderDisplayName: string chunkSize: number // int64 @@ -3811,6 +3899,7 @@ export enum RelayStatus { New = "new", Invited = "invited", Accepted = "accepted", + AcknowledgedRoster = "acknowledgedRoster", Active = "active", Inactive = "inactive", Rejected = "rejected", @@ -3895,6 +3984,41 @@ export interface SimplePreference { allow: FeatureAllowed } +export interface SimplexDomain { + nameTLD: SimplexTLD + domain: string + subDomain: string[] +} + +export interface SimplexDomainClaim { + domain: string + proof?: SimplexDomainProof +} + +export type SimplexDomainError = SimplexDomainError.NoValidLink | SimplexDomainError.UnknownDomain + +export namespace SimplexDomainError { + export type Tag = "noValidLink" | "unknownDomain" + + interface Interface { + type: Tag + } + + export interface NoValidLink extends Interface { + type: "noValidLink" + } + + export interface UnknownDomain extends Interface { + type: "unknownDomain" + } +} + +export interface SimplexDomainProof { + linkOwnerId?: string + presHeader: string + signature: string +} + export enum SimplexLinkType { Contact = "contact", Invitation = "invitation", @@ -3903,15 +4027,9 @@ export enum SimplexLinkType { Relay = "relay", } -export interface SimplexNameDomain { - nameTLD: SimplexTLD - domain: string - subDomain: string[] -} - export interface SimplexNameInfo { nameType: SimplexNameType - nameDomain: SimplexNameDomain + nameDomain: SimplexDomain } export enum SimplexNameType { @@ -4879,8 +4997,9 @@ export interface User { sendRcptsSmallGroups: boolean autoAcceptMemberContacts: boolean userMemberProfileUpdatedAt?: string // ISO-8601 timestamp - uiThemes?: UIThemeEntityOverrides userChatRelay: boolean + clientService: boolean + uiThemes?: UIThemeEntityOverrides } export interface UserChatRelay { diff --git a/packages/simplex-chat-client/typescript/src/client.ts b/packages/simplex-chat-client/typescript/src/client.ts index 12fa150fc4..10c4ee0a81 100644 --- a/packages/simplex-chat-client/typescript/src/client.ts +++ b/packages/simplex-chat-client/typescript/src/client.ts @@ -121,7 +121,7 @@ export class ChatClient { async apiSendMessages(chatType: T.ChatType, chatId: number, messages: T.ComposedMessage[]): Promise {
const r = await this.sendChatCmd(
- CC.APISendMessages.cmdString({sendRef: {chatType, chatId}, composedMessages: messages, liveMessage: false})
+ CC.APISendMessages.cmdString({sendRef: {chatType, chatId}, composedMessages: messages, liveMessage: false, signMessages: false})
)
if (r.type === "newChatItems") return r.chatItems
throw new ChatCommandError("unexpected response", r)
diff --git a/packages/simplex-chat-nodejs/package.json b/packages/simplex-chat-nodejs/package.json
index e5360df2b4..76833f70c8 100644
--- a/packages/simplex-chat-nodejs/package.json
+++ b/packages/simplex-chat-nodejs/package.json
@@ -1,6 +1,6 @@
{
"name": "simplex-chat",
- "version": "6.5.6",
+ "version": "7.0.0",
"main": "dist/index.js",
"types": "dist/index.d.ts",
"files": [
@@ -24,7 +24,7 @@
"docs": "typedoc"
},
"dependencies": {
- "@simplex-chat/types": "^0.9.0",
+ "@simplex-chat/types": "^0.10.3",
"extract-zip": "^2.0.1",
"fast-deep-equal": "^3.1.3",
"node-addon-api": "^8.5.0"
diff --git a/packages/simplex-chat-nodejs/src/api.ts b/packages/simplex-chat-nodejs/src/api.ts
index 0d3339df9a..958304a8ea 100644
--- a/packages/simplex-chat-nodejs/src/api.ts
+++ b/packages/simplex-chat-nodejs/src/api.ts
@@ -423,7 +423,8 @@ export class ChatApi {
CC.APISendMessages.cmdString({
sendRef,
composedMessages: messages,
- liveMessage
+ liveMessage,
+ signMessages: false
})
)
if (r.type === "newChatItems") return r.chatItems
@@ -688,7 +689,7 @@ export class ChatApi {
* Network usage: interactive.
*/
async apiConnectPlan(userId: number, connectionLink: string): Promise<[T.ConnectionPlan, T.CreatedConnLink]> {
- const r = await this.sendChatCmd(CC.APIConnectPlan.cmdString({userId, connectionLink, resolveKnown: false}))
+ const r = await this.sendChatCmd(CC.APIConnectPlan.cmdString({userId, connectTarget: connectionLink, resolveMode: T.PlanResolveMode.Unknown}))
if (r.type === "connectionPlan") return [r.connectionPlan, r.connLink]
throw new ChatCommandError("error getting connect plan", r)
}
@@ -707,7 +708,7 @@ export class ChatApi {
* Network usage: interactive.
*/
async apiConnectActiveUser(connLink: string): Promise {
- const r = await this.sendChatCmd(CC.Connect.cmdString({incognito: false, connLink_: connLink}))
+ const r = await this.sendChatCmd(CC.Connect.cmdString({incognito: false, connTarget_: connLink}))
return this.handleConnectResult(r)
}
@@ -866,7 +867,7 @@ export class ChatApi {
* Network usage: no.
*/
async apiCreateActiveUser(profile?: T.Profile): Promise {
- const r = await this.sendChatCmd(CC.CreateActiveUser.cmdString({newUser: {profile, pastTimestamp: false, userChatRelay: false}}))
+ const r = await this.sendChatCmd(CC.CreateActiveUser.cmdString({newUser: {profile, pastTimestamp: false, userChatRelay: false, clientService: false}}))
if (r.type === "activeUser") return r.user
throw new ChatCommandError("unexpected response", r)
}
diff --git a/packages/simplex-chat-nodejs/src/download-libs.js b/packages/simplex-chat-nodejs/src/download-libs.js
index 8fbed9efe0..e0685e0123 100644
--- a/packages/simplex-chat-nodejs/src/download-libs.js
+++ b/packages/simplex-chat-nodejs/src/download-libs.js
@@ -4,7 +4,7 @@ const path = require('path');
const extract = require('extract-zip');
const GITHUB_REPO = 'simplex-chat/simplex-chat-libs';
-const RELEASE_TAG = 'v6.5.6';
+const RELEASE_TAG = 'v7.0.0';
const BACKEND = (process.env.SIMPLEX_BACKEND || process.env.npm_config_simplex_backend || 'sqlite').toLowerCase();
if (BACKEND !== 'sqlite' && BACKEND !== 'postgres') {
diff --git a/packages/simplex-chat-python/examples/squaring_bot.py b/packages/simplex-chat-python/examples/squaring_bot.py
index 296b51347e..4d062ad718 100644
--- a/packages/simplex-chat-python/examples/squaring_bot.py
+++ b/packages/simplex-chat-python/examples/squaring_bot.py
@@ -26,7 +26,15 @@ bot = Bot(
profile=BotProfile(display_name="Squaring bot"),
db=SqliteDb(file_prefix="./squaring_bot"),
welcome="Send me a number, I'll square it.",
- commands=[BotCommand(keyword="help", label="Show help")],
+ commands=[
+ # `params=None` (default): the client SENDS `/help` immediately
+ # when the user taps it in the commands menu.
+ BotCommand(keyword="help", label="Show help"),
+ # `params=""`: the client PASTES `/square `
+ # into the input box and positions the cursor at the end. The
+ # user replaces `` with the actual number and sends.
+ BotCommand(keyword="square", label="Square a number", params=""),
+ ],
)
NUMBER_RE = re.compile(r"^-?\d+(\.\d+)?$")
@@ -48,5 +56,19 @@ async def help_cmd(msg: Message, _cmd: ParsedCommand) -> None:
await msg.reply("Send a number, I'll square it.")
+@bot.on_command("square")
+async def square_cmd(msg: Message, cmd: ParsedCommand) -> None:
+ """Demonstrates the `params` flow: `cmd.args` is the trimmed text
+ AFTER `/square`. When the user tapped the menu entry above, the
+ client pasted `/square ` and the user replaced
+ `` with the actual value before sending."""
+ try:
+ n = float(cmd.args)
+ except ValueError:
+ await msg.reply(f"Usage: /square (got {cmd.args!r})")
+ return
+ await msg.reply(f"{n} * {n} = {n * n}")
+
+
if __name__ == "__main__":
bot.run()
diff --git a/packages/simplex-chat-python/src/simplex_chat/_version.py b/packages/simplex-chat-python/src/simplex_chat/_version.py
index 0b25146728..e1cbccc2da 100644
--- a/packages/simplex-chat-python/src/simplex_chat/_version.py
+++ b/packages/simplex-chat-python/src/simplex_chat/_version.py
@@ -5,5 +5,5 @@ Bump both together for normal releases. For wrapper-only fixes use a PEP 440
post-release: __version__ = "6.5.2.post1", LIBS_VERSION unchanged.
"""
-__version__ = "6.5.6" # PEP 440 — read by hatchling for wheel metadata
-LIBS_VERSION = "6.5.6" # simplex-chat-libs release tag (no 'v' prefix)
+__version__ = "7.0.0" # PEP 440 — read by hatchling for wheel metadata
+LIBS_VERSION = "7.0.0" # simplex-chat-libs release tag (no 'v' prefix)
diff --git a/packages/simplex-chat-python/src/simplex_chat/api.py b/packages/simplex-chat-python/src/simplex_chat/api.py
index ef37e28384..51de063329 100644
--- a/packages/simplex-chat-python/src/simplex_chat/api.py
+++ b/packages/simplex-chat-python/src/simplex_chat/api.py
@@ -193,6 +193,7 @@ class ChatApi:
"sendRef": send_ref,
"composedMessages": messages,
"liveMessage": live_message,
+ "signMessages": False,
}
)
)
@@ -466,7 +467,7 @@ class ChatApi:
) -> tuple[T.ConnectionPlan, T.CreatedConnLink]:
r = await self.send_chat_cmd(
CC.APIConnectPlan_cmd_string(
- {"userId": user_id, "connectionLink": connection_link, "resolveKnown": False}
+ {"userId": user_id, "connectTarget": connection_link, "resolveMode": "unknown"}
)
)
if r["type"] == "connectionPlan":
@@ -487,7 +488,7 @@ class ChatApi:
async def api_connect_active_user(self, conn_link: str) -> ConnReqType:
r = await self.send_chat_cmd(
- CC.Connect_cmd_string({"incognito": False, "connLink_": conn_link})
+ CC.Connect_cmd_string({"incognito": False, "connTarget_": conn_link})
)
return self._handle_connect_result(r)
@@ -641,7 +642,7 @@ class ChatApi:
raise
async def api_create_active_user(self, profile: T.Profile | None = None) -> T.User:
- new_user: T.NewUser = {"pastTimestamp": False, "userChatRelay": False}
+ new_user: T.NewUser = {"pastTimestamp": False, "userChatRelay": False, "clientService": False}
if profile is not None:
new_user["profile"] = profile
r = await self.send_chat_cmd(CC.CreateActiveUser_cmd_string({"newUser": new_user}))
diff --git a/packages/simplex-chat-python/src/simplex_chat/bot.py b/packages/simplex-chat-python/src/simplex_chat/bot.py
index fb511e2818..4e385493b2 100644
--- a/packages/simplex-chat-python/src/simplex_chat/bot.py
+++ b/packages/simplex-chat-python/src/simplex_chat/bot.py
@@ -33,8 +33,38 @@ from .types import T
@dataclass(slots=True)
class BotCommand:
+ """One entry in the bot's advertised slash-command list (wire-side
+ `groupPreferences.commands` or profile `preferences.commands`).
+
+ `keyword` and `label` are required: `keyword` is what the user
+ types after `/`; `label` is the human-readable description shown
+ next to the keyword in the SimpleX client's commands menu.
+
+ `params` is an optional placeholder string that controls how the
+ client behaves when the user taps the command in the menu:
+
+ * `params=None` (default) — the client SENDS `/`
+ immediately on tap; no input-box detour. Use this for
+ zero-argument commands (`/help`, `/ping`) where the action is
+ unambiguous.
+
+ * `params=""` — the client PASTES `/ `
+ into the input box and positions the cursor at the end. The
+ user edits the placeholder and sends. Use this for commands
+ that take a required argument (`/review `,
+ `/order `) so the user sees the expected shape
+ without having to remember it.
+
+ Mirrors `CBCCommand` in the Haskell core
+ (`Simplex.Chat.Types.Preferences`) and the wire TypedDict
+ `ChatBotCommand_command`. Both SimpleX clients (Android/Kotlin
+ and iOS/Swift) implement the paste-vs-send branch on the
+ `params` field; see `CommandsMenuView.{kt,swift}` for the
+ reference UI behaviour.
+ """
keyword: str
label: str
+ params: str | None = None
class Bot(Client):
@@ -145,10 +175,24 @@ class Bot(Client):
"files": {"allow": "yes" if self._allow_files else "no"},
}
if self._commands:
- prefs["commands"] = [
- {"type": "command", "keyword": c.keyword, "label": c.label}
- for c in self._commands
- ]
+ cmds: list[T.ChatBotCommand] = []
+ for c in self._commands:
+ entry: T.ChatBotCommand_command = {
+ "type": "command",
+ "keyword": c.keyword,
+ "label": c.label,
+ }
+ # `params` is `NotRequired[str]` on the wire; omit the
+ # key entirely when None so the Haskell parser sees
+ # `Nothing` rather than `Just ""`. The two have
+ # different client semantics: `Nothing` (`params=None`)
+ # triggers an immediate send on tap; `Just ""` would
+ # paste `/ ` (with a trailing space) into the
+ # input box, which is rarely what the operator wants.
+ if c.params is not None:
+ entry["params"] = c.params
+ cmds.append(entry)
+ prefs["commands"] = cmds
p["preferences"] = prefs
p["peerType"] = "bot"
return p
diff --git a/packages/simplex-chat-python/src/simplex_chat/types/_commands.py b/packages/simplex-chat-python/src/simplex_chat/types/_commands.py
index 3847f44811..a7f4a56465 100644
--- a/packages/simplex-chat-python/src/simplex_chat/types/_commands.py
+++ b/packages/simplex-chat-python/src/simplex_chat/types/_commands.py
@@ -80,11 +80,12 @@ class APISendMessages(TypedDict):
sendRef: "T.ChatRef"
liveMessage: bool
ttl: NotRequired[int] # int
+ signMessages: bool
composedMessages: list["T.ComposedMessage"] # non-empty
def APISendMessages_cmd_string(self: APISendMessages) -> str:
- return '/_send ' + T.ChatRef_cmd_string(self['sendRef']) + (' live=on' if self['liveMessage'] else '') + ((' ttl=' + str(self.get('ttl'))) if self.get('ttl') is not None else '') + ' json ' + json.dumps(self['composedMessages'])
+ return '/_send ' + T.ChatRef_cmd_string(self['sendRef']) + (' live=on' if self['liveMessage'] else '') + ((' ttl=' + str(self.get('ttl'))) if self.get('ttl') is not None else '') + (' sign=on' if self['signMessages'] else '') + ' json ' + json.dumps(self['composedMessages'])
APISendMessages_Response = CR.NewChatItems | CR.ChatCmdError
@@ -434,17 +435,17 @@ def APIAddContact_cmd_string(self: APIAddContact) -> str:
APIAddContact_Response = CR.Invitation | CR.ChatCmdError
-# Determine SimpleX link type and if the bot is already connected via this link.
+# Determine SimpleX link type and if the bot is already connected via this link or name.
# Network usage: interactive.
class APIConnectPlan(TypedDict):
userId: int # int64
- connectionLink: NotRequired[str]
- resolveKnown: bool
+ connectTarget: NotRequired[str]
+ resolveMode: "T.PlanResolveMode"
linkOwnerSig: NotRequired["T.LinkOwnerSig"]
def APIConnectPlan_cmd_string(self: APIConnectPlan) -> str:
- return '/_connect plan ' + str(self['userId']) + ' ' + self.get('connectionLink')
+ return '/_connect plan ' + str(self['userId']) + ' ' + self.get('connectTarget')
APIConnectPlan_Response = CR.ConnectionPlan | CR.ChatCmdError
@@ -463,15 +464,15 @@ def APIConnect_cmd_string(self: APIConnect) -> str:
APIConnect_Response = CR.SentConfirmation | CR.ContactAlreadyExists | CR.SentInvitation | CR.ChatCmdError
-# Connect via SimpleX link as string in the active user profile.
+# Connect via SimpleX link or name as string in the active user profile.
# Network usage: interactive.
class Connect(TypedDict):
incognito: bool
- connLink_: NotRequired[str]
+ connTarget_: NotRequired[str]
def Connect_cmd_string(self: Connect) -> str:
- return '/connect' + ((' ' + self.get('connLink_')) if self.get('connLink_') is not None else '')
+ return '/connect' + ((' ' + self.get('connTarget_')) if self.get('connTarget_') is not None else '')
Connect_Response = CR.SentConfirmation | CR.ContactAlreadyExists | CR.SentInvitation | CR.ChatCmdError
diff --git a/packages/simplex-chat-python/src/simplex_chat/types/_responses.py b/packages/simplex-chat-python/src/simplex_chat/types/_responses.py
index e85de02c78..bd61e6dae1 100644
--- a/packages/simplex-chat-python/src/simplex_chat/types/_responses.py
+++ b/packages/simplex-chat-python/src/simplex_chat/types/_responses.py
@@ -57,6 +57,8 @@ class ConnectionPlan(TypedDict):
type: Literal["connectionPlan"]
user: "T.User"
connLink: "T.CreatedConnLink"
+ planSimplexName: NotRequired["T.SimplexNameInfo"]
+ otherSimplexName: NotRequired["T.SimplexNameInfo"]
connectionPlan: "T.ConnectionPlan"
class ContactAlreadyExists(TypedDict):
diff --git a/packages/simplex-chat-python/src/simplex_chat/types/_types.py b/packages/simplex-chat-python/src/simplex_chat/types/_types.py
index 855a967215..96d3f4dea4 100644
--- a/packages/simplex-chat-python/src/simplex_chat/types/_types.py
+++ b/packages/simplex-chat-python/src/simplex_chat/types/_types.py
@@ -78,6 +78,9 @@ class AgentErrorType_FILE(TypedDict):
type: Literal["FILE"]
fileErr: "FileErrorType"
+class AgentErrorType_NO_NAME_SERVERS(TypedDict):
+ type: Literal["NO_NAME_SERVERS"]
+
class AgentErrorType_PROXY(TypedDict):
type: Literal["PROXY"]
proxyServer: str
@@ -123,6 +126,7 @@ AgentErrorType = (
| AgentErrorType_NTF
| AgentErrorType_XFTP
| AgentErrorType_FILE
+ | AgentErrorType_NO_NAME_SERVERS
| AgentErrorType_PROXY
| AgentErrorType_RCP
| AgentErrorType_BROKER
@@ -133,7 +137,7 @@ AgentErrorType = (
| AgentErrorType_INACTIVE
)
-AgentErrorType_Tag = Literal["CMD", "CONN", "NO_USER", "SMP", "NTF", "XFTP", "FILE", "PROXY", "RCP", "BROKER", "AGENT", "NOTICE", "INTERNAL", "CRITICAL", "INACTIVE"]
+AgentErrorType_Tag = Literal["CMD", "CONN", "NO_USER", "SMP", "NTF", "XFTP", "FILE", "NO_NAME_SERVERS", "PROXY", "RCP", "BROKER", "AGENT", "NOTICE", "INTERNAL", "CRITICAL", "INACTIVE"]
class AutoAccept(TypedDict):
acceptIncognito: bool
@@ -200,6 +204,7 @@ class BusinessChatInfo(TypedDict):
chatType: "BusinessChatType"
businessId: str
customerId: str
+ businessDomain: NotRequired["SimplexDomainClaim"]
BusinessChatType = Literal["business", "customer"]
@@ -583,7 +588,7 @@ class CIMeta(TypedDict):
editable: bool
forwardedByMember: NotRequired[int] # int64
showGroupAsSender: bool
- msgSigned: NotRequired["MsgSigStatus"]
+ msgVerified: NotRequired["MsgVerified"]
createdAt: str # ISO-8601 timestamp
updatedAt: str # ISO-8601 timestamp
@@ -727,9 +732,6 @@ class ChatErrorType_noRcvFileUser(TypedDict):
class ChatErrorType_userUnknown(TypedDict):
type: Literal["userUnknown"]
-class ChatErrorType_activeUserExists(TypedDict):
- type: Literal["activeUserExists"]
-
class ChatErrorType_userExists(TypedDict):
type: Literal["userExists"]
contactName: str
@@ -787,6 +789,14 @@ class ChatErrorType_chatStoreChanged(TypedDict):
class ChatErrorType_invalidConnReq(TypedDict):
type: Literal["invalidConnReq"]
+class ChatErrorType_simplexDomainNotReady(TypedDict):
+ type: Literal["simplexDomainNotReady"]
+ simplexDomain: "SimplexDomain"
+ simplexDomainError: "SimplexDomainError"
+
+class ChatErrorType_notResolvedLocally(TypedDict):
+ type: Literal["notResolvedLocally"]
+
class ChatErrorType_unsupportedConnReq(TypedDict):
type: Literal["unsupportedConnReq"]
@@ -1002,7 +1012,6 @@ ChatErrorType = (
| ChatErrorType_noSndFileUser
| ChatErrorType_noRcvFileUser
| ChatErrorType_userUnknown
- | ChatErrorType_activeUserExists
| ChatErrorType_userExists
| ChatErrorType_chatRelayExists
| ChatErrorType_differentActiveUser
@@ -1018,6 +1027,8 @@ ChatErrorType = (
| ChatErrorType_chatNotStopped
| ChatErrorType_chatStoreChanged
| ChatErrorType_invalidConnReq
+ | ChatErrorType_simplexDomainNotReady
+ | ChatErrorType_notResolvedLocally
| ChatErrorType_unsupportedConnReq
| ChatErrorType_connReqMessageProhibited
| ChatErrorType_contactNotReady
@@ -1074,7 +1085,7 @@ ChatErrorType = (
| ChatErrorType_exception
)
-ChatErrorType_Tag = Literal["noActiveUser", "noConnectionUser", "noSndFileUser", "noRcvFileUser", "userUnknown", "activeUserExists", "userExists", "chatRelayExists", "differentActiveUser", "cantDeleteActiveUser", "cantDeleteLastUser", "cantHideLastUser", "hiddenUserAlwaysMuted", "emptyUserPassword", "userAlreadyHidden", "userNotHidden", "invalidDisplayName", "chatNotStarted", "chatNotStopped", "chatStoreChanged", "invalidConnReq", "unsupportedConnReq", "connReqMessageProhibited", "contactNotReady", "contactNotActive", "contactDisabled", "connectionDisabled", "groupUserRole", "groupMemberInitialRole", "contactIncognitoCantInvite", "groupIncognitoCantInvite", "groupContactRole", "groupDuplicateMember", "groupDuplicateMemberId", "groupNotJoined", "groupMemberNotActive", "cantBlockMemberForSelf", "groupMemberUserRemoved", "groupMemberNotFound", "groupCantResendInvitation", "groupInternal", "fileNotFound", "fileSize", "fileAlreadyReceiving", "fileCancelled", "fileCancel", "fileAlreadyExists", "fileWrite", "fileSend", "fileRcvChunk", "fileInternal", "fileImageType", "fileImageSize", "fileNotReceived", "fileNotApproved", "fallbackToSMPProhibited", "inlineFileProhibited", "invalidForward", "invalidChatItemUpdate", "invalidChatItemDelete", "hasCurrentCall", "noCurrentCall", "callContact", "directMessagesProhibited", "agentVersion", "agentNoSubResult", "commandError", "agentCommandError", "invalidFileDescription", "connectionIncognitoChangeProhibited", "connectionUserChangeProhibited", "peerChatVRangeIncompatible", "relayTestError", "internalError", "exception"]
+ChatErrorType_Tag = Literal["noActiveUser", "noConnectionUser", "noSndFileUser", "noRcvFileUser", "userUnknown", "userExists", "chatRelayExists", "differentActiveUser", "cantDeleteActiveUser", "cantDeleteLastUser", "cantHideLastUser", "hiddenUserAlwaysMuted", "emptyUserPassword", "userAlreadyHidden", "userNotHidden", "invalidDisplayName", "chatNotStarted", "chatNotStopped", "chatStoreChanged", "invalidConnReq", "simplexDomainNotReady", "notResolvedLocally", "unsupportedConnReq", "connReqMessageProhibited", "contactNotReady", "contactNotActive", "contactDisabled", "connectionDisabled", "groupUserRole", "groupMemberInitialRole", "contactIncognitoCantInvite", "groupIncognitoCantInvite", "groupContactRole", "groupDuplicateMember", "groupDuplicateMemberId", "groupNotJoined", "groupMemberNotActive", "cantBlockMemberForSelf", "groupMemberUserRemoved", "groupMemberNotFound", "groupCantResendInvitation", "groupInternal", "fileNotFound", "fileSize", "fileAlreadyReceiving", "fileCancelled", "fileCancel", "fileAlreadyExists", "fileWrite", "fileSend", "fileRcvChunk", "fileInternal", "fileImageType", "fileImageSize", "fileNotReceived", "fileNotApproved", "fallbackToSMPProhibited", "inlineFileProhibited", "invalidForward", "invalidChatItemUpdate", "invalidChatItemDelete", "hasCurrentCall", "noCurrentCall", "callContact", "directMessagesProhibited", "agentVersion", "agentNoSubResult", "commandError", "agentCommandError", "invalidFileDescription", "connectionIncognitoChangeProhibited", "connectionUserChangeProhibited", "peerChatVRangeIncompatible", "relayTestError", "internalError", "exception"]
ChatFeature = Literal["timedMessages", "fullDelete", "reactions", "voice", "files", "calls", "sessions"]
@@ -1557,6 +1568,10 @@ class ErrorType_EXPIRED(TypedDict):
class ErrorType_INTERNAL(TypedDict):
type: Literal["INTERNAL"]
+class ErrorType_NAME(TypedDict):
+ type: Literal["NAME"]
+ nameErr: "NameErrorType"
+
class ErrorType_DUPLICATE_(TypedDict):
type: Literal["DUPLICATE_"]
@@ -1575,10 +1590,11 @@ ErrorType = (
| ErrorType_LARGE_MSG
| ErrorType_EXPIRED
| ErrorType_INTERNAL
+ | ErrorType_NAME
| ErrorType_DUPLICATE_
)
-ErrorType_Tag = Literal["BLOCK", "SESSION", "CMD", "PROXY", "AUTH", "BLOCKED", "SERVICE", "CRYPTO", "QUOTA", "STORE", "NO_MSG", "LARGE_MSG", "EXPIRED", "INTERNAL", "DUPLICATE_"]
+ErrorType_Tag = Literal["BLOCK", "SESSION", "CMD", "PROXY", "AUTH", "BLOCKED", "SERVICE", "CRYPTO", "QUOTA", "STORE", "NO_MSG", "LARGE_MSG", "EXPIRED", "INTERNAL", "NAME", "DUPLICATE_"]
FeatureAllowed = Literal["always", "yes", "no"]
@@ -1666,6 +1682,8 @@ class FileTransferMeta(TypedDict):
chunkSize: int # int64
cancelled: bool
+FileType = Literal["normal", "roster"]
+
class Format_bold(TypedDict):
type: Literal["bold"]
@@ -1758,6 +1776,7 @@ class FullGroupPreferences(TypedDict):
support: "SupportGroupPreference"
sessions: "RoleGroupPreference"
comments: "CommentsGroupPreference"
+ signMessages: "GroupPreference"
commands: list["ChatBotCommand"]
class FullPreferences(TypedDict):
@@ -1801,7 +1820,7 @@ class GroupDirectInvitation(TypedDict):
fromGroupMemberConnId_: NotRequired[int] # int64
groupDirectInvStartedConnection: bool
-GroupFeature = Literal["timedMessages", "directMessages", "fullDelete", "reactions", "voice", "files", "simplexLinks", "reports", "history", "support", "sessions", "comments"]
+GroupFeature = Literal["timedMessages", "directMessages", "fullDelete", "reactions", "voice", "files", "simplexLinks", "reports", "history", "support", "sessions", "comments", "signMessages"]
GroupFeatureEnabled = Literal["on", "off"]
@@ -1826,9 +1845,11 @@ class GroupInfo(TypedDict):
uiThemes: NotRequired["UIThemeEntityOverrides"]
customData: NotRequired[dict[str, object]]
groupSummary: "GroupSummary"
+ rosterVersion: NotRequired[int] # int64
membersRequireAttention: int # int
viaGroupLinkUri: NotRequired[str]
groupKeys: NotRequired["GroupKeys"]
+ groupDomainVerified: NotRequired[bool]
class GroupKeys(TypedDict):
publicGroupId: str
@@ -1914,6 +1935,7 @@ class GroupMember(TypedDict):
supportChat: NotRequired["GroupSupportChat"]
memberPubKey: NotRequired[str]
relayLink: NotRequired[str]
+ memberVerifiedCode: NotRequired["SecurityCode"]
class GroupMemberAdmission(TypedDict):
review: NotRequired["MemberCriteria"]
@@ -1947,6 +1969,7 @@ class GroupPreferences(TypedDict):
support: NotRequired["SupportGroupPreference"]
sessions: NotRequired["RoleGroupPreference"]
comments: NotRequired["CommentsGroupPreference"]
+ signMessages: NotRequired["GroupPreference"]
commands: NotRequired[list["ChatBotCommand"]]
class GroupProfile(TypedDict):
@@ -2084,12 +2107,15 @@ class LocalProfile(TypedDict):
displayName: str
fullName: str
shortDescr: NotRequired[str]
+ description: NotRequired[str]
image: NotRequired[str]
contactLink: NotRequired[str]
preferences: NotRequired["Preferences"]
peerType: NotRequired["ChatPeerType"]
localBadge: NotRequired["LocalBadge"]
localAlias: str
+ contactDomain: NotRequired["SimplexDomainClaim"]
+ contactDomainVerified: NotRequired[bool]
MemberCriteria = Literal["all"]
@@ -2222,6 +2248,31 @@ MsgReceiptStatus = Literal["ok", "badMsgHash"]
MsgSigStatus = Literal["verified", "signedNoKey"]
+class MsgVerified_signed(TypedDict):
+ type: Literal["signed"]
+ sigStatus: "MsgSigStatus"
+
+class MsgVerified_sigMissing(TypedDict):
+ type: Literal["sigMissing"]
+
+MsgVerified = MsgVerified_signed | MsgVerified_sigMissing
+
+MsgVerified_Tag = Literal["signed", "sigMissing"]
+
+class NameErrorType_NO_RESOLVER(TypedDict):
+ type: Literal["NO_RESOLVER"]
+
+class NameErrorType_NOT_FOUND(TypedDict):
+ type: Literal["NOT_FOUND"]
+
+class NameErrorType_RESOLVER(TypedDict):
+ type: Literal["RESOLVER"]
+ resolverErr: str
+
+NameErrorType = NameErrorType_NO_RESOLVER | NameErrorType_NOT_FOUND | NameErrorType_RESOLVER
+
+NameErrorType_Tag = Literal["NO_RESOLVER", "NOT_FOUND", "RESOLVER"]
+
class NetworkError_connectError(TypedDict):
type: Literal["connectError"]
connectError: str
@@ -2258,6 +2309,7 @@ class NewUser(TypedDict):
profile: NotRequired["Profile"]
pastTimestamp: bool
userChatRelay: bool
+ clientService: bool
class NoteFolder(TypedDict):
noteFolderId: int # int64
@@ -2304,6 +2356,8 @@ class PendingContactConnection(TypedDict):
createdAt: str # ISO-8601 timestamp
updatedAt: str # ISO-8601 timestamp
+PlanResolveMode = Literal["allGroups", "unknown", "never"]
+
class PrefEnabled(TypedDict):
forUser: bool
forContact: bool
@@ -2335,11 +2389,13 @@ class Profile(TypedDict):
displayName: str
fullName: str
shortDescr: NotRequired[str]
+ description: NotRequired[str]
image: NotRequired[str]
contactLink: NotRequired[str]
preferences: NotRequired["Preferences"]
peerType: NotRequired["ChatPeerType"]
badge: NotRequired["BadgeProof"]
+ contactDomain: NotRequired["SimplexDomainClaim"]
class ProxyClientError_protocolError(TypedDict):
type: Literal["protocolError"]
@@ -2381,7 +2437,7 @@ ProxyError_Tag = Literal["PROTOCOL", "BROKER", "BASIC_AUTH", "NO_SESSION"]
class PublicGroupAccess(TypedDict):
groupWebPage: NotRequired[str]
- groupDomain: NotRequired[str]
+ groupDomainClaim: NotRequired["SimplexDomainClaim"]
domainWebPage: bool
allowEmbedding: bool
@@ -2553,6 +2609,7 @@ class RcvFileTransfer(TypedDict):
xftpRcvFile: NotRequired["XFTPRcvFile"]
fileInvitation: "FileInvitation"
fileStatus: "RcvFileStatus"
+ fileType: "FileType"
rcvFileInline: NotRequired["InlineFileMode"]
senderDisplayName: str
chunkSize: int # int64
@@ -2670,7 +2727,7 @@ class RelayProfile(TypedDict):
shortDescr: NotRequired[str]
image: NotRequired[str]
-RelayStatus = Literal["new", "invited", "accepted", "active", "inactive", "rejected"]
+RelayStatus = Literal["new", "invited", "accepted", "acknowledgedRoster", "active", "inactive", "rejected"]
ReportReason = Literal["spam", "content", "community", "profile", "other"]
@@ -2723,16 +2780,35 @@ class SecurityCode(TypedDict):
class SimplePreference(TypedDict):
allow: "FeatureAllowed"
-SimplexLinkType = Literal["contact", "invitation", "group", "channel", "relay"]
-
-class SimplexNameDomain(TypedDict):
+class SimplexDomain(TypedDict):
nameTLD: "SimplexTLD"
domain: str
subDomain: list[str]
+class SimplexDomainClaim(TypedDict):
+ domain: str
+ proof: NotRequired["SimplexDomainProof"]
+
+class SimplexDomainError_noValidLink(TypedDict):
+ type: Literal["noValidLink"]
+
+class SimplexDomainError_unknownDomain(TypedDict):
+ type: Literal["unknownDomain"]
+
+SimplexDomainError = SimplexDomainError_noValidLink | SimplexDomainError_unknownDomain
+
+SimplexDomainError_Tag = Literal["noValidLink", "unknownDomain"]
+
+class SimplexDomainProof(TypedDict):
+ linkOwnerId: NotRequired[str]
+ presHeader: str
+ signature: str
+
+SimplexLinkType = Literal["contact", "invitation", "group", "channel", "relay"]
+
class SimplexNameInfo(TypedDict):
nameType: "SimplexNameType"
- nameDomain: "SimplexNameDomain"
+ nameDomain: "SimplexDomain"
SimplexNameType = Literal["publicGroup", "contact"]
@@ -3419,8 +3495,9 @@ class User(TypedDict):
sendRcptsSmallGroups: bool
autoAcceptMemberContacts: bool
userMemberProfileUpdatedAt: NotRequired[str] # ISO-8601 timestamp
- uiThemes: NotRequired["UIThemeEntityOverrides"]
userChatRelay: bool
+ clientService: bool
+ uiThemes: NotRequired["UIThemeEntityOverrides"]
class UserChatRelay(TypedDict):
chatRelayId: int # int64
diff --git a/packages/simplex-chat-python/tests/test_bot_registration.py b/packages/simplex-chat-python/tests/test_bot_registration.py
index f6f245c344..06837bdc07 100644
--- a/packages/simplex-chat-python/tests/test_bot_registration.py
+++ b/packages/simplex-chat-python/tests/test_bot_registration.py
@@ -86,8 +86,63 @@ def test_bot_profile_to_wire_with_commands():
)
cmds = bot._profile_to_wire().get("preferences", {}).get("commands") or []
assert len(cmds) == 2
+ # `params` defaults to None and must be ABSENT from the wire dict
+ # (not present as `null`/`""`) so the Haskell parser sees
+ # `Nothing` and the SimpleX client sends the bare `/keyword` on
+ # tap rather than pasting a trailing-space placeholder.
assert cmds[0] == {"type": "command", "keyword": "ping", "label": "Ping bot"}
assert cmds[1] == {"type": "command", "keyword": "help", "label": "Show help"}
+ assert "params" not in cmds[0]
+ assert "params" not in cmds[1]
+
+
+def test_bot_command_params_emits_on_wire():
+ """When `BotCommand.params` is set, the wire dict carries it as
+ `params: `. The SimpleX client (verified against
+ `CommandsMenuView.kt:153-161` and `CommandsMenuView.swift:117-128`
+ in simplex-chat 6.5) then pastes `/ ` into the
+ input box on tap, positions the cursor at the end, and lets the
+ user edit before sending. Use this for commands that take a
+ required argument (`/review `)."""
+ bot = Bot(
+ profile=BotProfile(display_name="x"),
+ db=SqliteDb(file_prefix="/tmp/test"),
+ commands=[
+ BotCommand(keyword="review", label="Review PR", params=""),
+ BotCommand(keyword="order", label="Place order", params=""),
+ ],
+ )
+ cmds = bot._profile_to_wire().get("preferences", {}).get("commands") or []
+ assert cmds[0] == {
+ "type": "command",
+ "keyword": "review",
+ "label": "Review PR",
+ "params": "",
+ }
+ assert cmds[1] == {
+ "type": "command",
+ "keyword": "order",
+ "label": "Place order",
+ "params": "",
+ }
+
+
+def test_bot_command_distinguishes_none_from_empty_params():
+ """`params=None` (immediate send) and `params=""` (paste with
+ trailing space) are semantically different on the client side.
+ Verify the wire form preserves the distinction: None → key
+ absent; empty string → key present with empty value."""
+ bot = Bot(
+ profile=BotProfile(display_name="x"),
+ db=SqliteDb(file_prefix="/tmp/test"),
+ commands=[
+ BotCommand(keyword="send", label="Send", params=None),
+ BotCommand(keyword="paste", label="Paste", params=""),
+ ],
+ )
+ cmds = bot._profile_to_wire().get("preferences", {}).get("commands") or []
+ assert "params" not in cmds[0]
+ assert cmds[1].get("params") == ""
def test_client_profile_to_wire_has_no_bot_extras():
diff --git a/packages/simplex-chat-python/tests/test_native_cache.py b/packages/simplex-chat-python/tests/test_native_cache.py
index 30a1f43e2a..55084eeae8 100644
--- a/packages/simplex-chat-python/tests/test_native_cache.py
+++ b/packages/simplex-chat-python/tests/test_native_cache.py
@@ -4,6 +4,7 @@ from pathlib import Path
import pytest
from simplex_chat._native import _cache_root, _resolve_libs_dir, _download
+from simplex_chat._version import LIBS_VERSION
def test_cache_root_linux(tmp_path, monkeypatch):
@@ -41,7 +42,7 @@ def test_resolve_downloads_when_missing(tmp_path, monkeypatch):
monkeypatch.setattr("simplex_chat._native._download", fake_download)
libs_dir = _resolve_libs_dir("sqlite")
- assert libs_dir == tmp_path / "simplex-chat" / "v6.5.2" / "sqlite"
+ assert libs_dir == tmp_path / "simplex-chat" / f"v{LIBS_VERSION}" / "sqlite"
assert called["backend"] == "sqlite"
assert (libs_dir / "libsimplex.so").exists()
@@ -49,7 +50,7 @@ def test_resolve_downloads_when_missing(tmp_path, monkeypatch):
def test_resolve_uses_cache_on_second_call(tmp_path, monkeypatch):
monkeypatch.setenv("XDG_CACHE_HOME", str(tmp_path))
monkeypatch.setattr("sys.platform", "linux")
- cached = tmp_path / "simplex-chat" / "v6.5.2" / "sqlite"
+ cached = tmp_path / "simplex-chat" / f"v{LIBS_VERSION}" / "sqlite"
cached.mkdir(parents=True)
(cached / "libsimplex.so").touch()
# Should NOT call _download — use the cached file.
diff --git a/packages/simplex-chat-python/tests/test_native_url.py b/packages/simplex-chat-python/tests/test_native_url.py
index b27c3e09cf..df96fff8ae 100644
--- a/packages/simplex-chat-python/tests/test_native_url.py
+++ b/packages/simplex-chat-python/tests/test_native_url.py
@@ -1,6 +1,7 @@
from unittest.mock import patch
import pytest
from simplex_chat._native import _platform_tag, _libs_url, _libname
+from simplex_chat._version import LIBS_VERSION
@patch("sys.platform", "linux")
@@ -42,7 +43,7 @@ def test_url_sqlite(_):
assert (
_libs_url("sqlite")
== "https://github.com/simplex-chat/simplex-chat-libs/releases/download/"
- "v6.5.2/simplex-chat-libs-linux-x86_64.zip"
+ f"v{LIBS_VERSION}/simplex-chat-libs-linux-x86_64.zip"
)
@@ -51,5 +52,5 @@ def test_url_postgres(_):
assert (
_libs_url("postgres")
== "https://github.com/simplex-chat/simplex-chat-libs/releases/download/"
- "v6.5.2/simplex-chat-libs-linux-x86_64-postgres.zip"
+ f"v{LIBS_VERSION}/simplex-chat-libs-linux-x86_64-postgres.zip"
)
diff --git a/packages/simplex-chat-webrtc/src/call.ts b/packages/simplex-chat-webrtc/src/call.ts
index 5f3d2bf332..8441560013 100644
--- a/packages/simplex-chat-webrtc/src/call.ts
+++ b/packages/simplex-chat-webrtc/src/call.ts
@@ -583,6 +583,8 @@ const processCommand = (function () {
case "capabilities":
console.log("starting outgoing call - capabilities")
if (activeCall) endCall()
+ // Stop a preview stream from an earlier pre-connect outgoing call being replaced (activeCall may be null here)
+ stopNotConnectedCall()
let localStream: MediaStream | null = null
try {
@@ -623,7 +625,8 @@ const processCommand = (function () {
if (activeCall) endCall()
// It can be already defined on Android when switching calls (if the previous call was outgoing)
- notConnectedCall = undefined
+ // Stop its preview tracks before clearing, otherwise camera/mic stay live
+ stopNotConnectedCall()
inactiveCallMediaSources.mic = true
inactiveCallMediaSources.camera = command.media == CallMediaType.Video
inactiveCallMediaSourcesChanged(inactiveCallMediaSources)
@@ -1444,6 +1447,14 @@ const processCommand = (function () {
}
}
+ // Call on any path that abandons notConnectedCall, otherwise its preview camera/mic tracks stay live.
+ function stopNotConnectedCall() {
+ if (notConnectedCall) {
+ notConnectedCall.localStream.getTracks().forEach((track) => track.stop())
+ notConnectedCall = undefined
+ }
+ }
+
function resetVideoElements() {
const videos = getVideoElements()
if (!videos) return
diff --git a/packages/simplex-chat-webrtc/src/desktop/ui.ts b/packages/simplex-chat-webrtc/src/desktop/ui.ts
index eac659a17a..862c727bd5 100644
--- a/packages/simplex-chat-webrtc/src/desktop/ui.ts
+++ b/packages/simplex-chat-webrtc/src/desktop/ui.ts
@@ -2,8 +2,8 @@
useWorker = typeof window.Worker !== "undefined"
isDesktop = true
-// Create WebSocket connection.
-const socket = new WebSocket(`ws://${location.host}`)
+// Create WebSocket connection. location.search carries the per-call ?token=... capability required by the server.
+const socket = new WebSocket(`ws://${location.host}${location.search}`)
socket.addEventListener("open", (_event) => {
console.log("Opened socket")
diff --git a/plans/2026-04-29-member-profile-sending-channels.md b/plans/2026-04-29-member-profile-sending-channels.md
index 2ee36b676e..be7d26ecab 100644
--- a/plans/2026-04-29-member-profile-sending-channels.md
+++ b/plans/2026-04-29-member-profile-sending-channels.md
@@ -1,5 +1,16 @@
# Plan: Member Profile Sending in Channels
+## Implementation note (2026-05-18)
+
+The shipped implementation is **monotonic and reuses `member_relations_vector`**, not a new `sent_profile_vector` column:
+
+- The introduction bit lives in `group_members.member_relations_vector` with status `MRIntroduced`. The M20251117 backfill already populates this column for channel rows (relay role is not admin/owner), and `createNewGroupMember` writes `Binary B.empty` for new members.
+- Bits flip 0 → 1 when the relay first announces the member to a recipient via prepended `XGrpMemNew` (or via `XGrpMemIntro` in `introduceInChannel`'s join-time direct path). They are **never cleared**.
+- Profile updates propagate via the sender's own signed `XInfo`, forwarded unchanged by the relay. The relay updates its DB on receipt; subscribers verify with the key obtained from the earlier `XGrpMemNew`. Section 5 below ("Clear vector on profile update") is superseded by this — no clearing happens.
+- The mutually-exclusive two-column delivery-jobs storage (`single_sender_group_member_id` + `sender_group_member_ids`) collapses into a single nullable `sender_group_member_ids BYTEA` column: `[s]` for single-sender jobs, `[s1, s2, ...]` for multi-sender batches, NULL for sender-less jobs (`DJRelayRemoved`).
+
+The plan body below is preserved for historical context.
+
## Context
In channels (relayed groups), subscribers don't know profiles of other subscribers. When subscriber A sends a reaction/message that gets forwarded to subscriber B, B creates an "unknown member" record with a synthesized name. This degrades UX — subscribers see "unknown member" instead of real profiles.
diff --git a/plans/2026-05-08-public-groups-via-relays-overview.md b/plans/2026-05-08-public-groups-via-relays-overview.md
new file mode 100644
index 0000000000..c0114e237d
--- /dev/null
+++ b/plans/2026-05-08-public-groups-via-relays-overview.md
@@ -0,0 +1,45 @@
+# Public groups via relays — plan summary
+
+A third kind of group: relay-mediated like channels, but every member can post like a
+secret group. Resolves the scale ceiling of full-mesh groups without the broadcast-only
+governance of channels. Two orthogonal axes, already in the model:
+
+| `useRelays` | `groupType` | Name |
+|-------------|--------------|--------------|
+| false | (none) | Secret group |
+| true | `GTChannel` | Channel |
+| true | `GTGroup` | Public group | ← new
+| true | `GTUnknown` | refuse | ← older client sees this for `"group"`
+
+`useRelays` is transport; `groupType` is the governance model (broadcast vs
+participatory). The joiner role is a per-group value the owner sets at creation,
+carried on the (owner-signed) channel profile, so every relay derives the same role for
+the same group — not from a relay-side global config and not from `groupType`. The
+blocker is narrow: no path produces `GTGroup` today, and the channel profile carries
+no joiner-role field yet.
+
+## Shape of the work
+
+Backend: wire/version bump, type helpers, create command, owner-configured joiner-role
+field on the channel profile, relay role derivation from that field. Clients (iOS +
+Kotlin mirror): model, audit splitting transport-vs-governance call sites, unified
+create flow with a Channel/Public-group toggle that picks the joiner-role default,
+views, connect-plan messaging.
+
+## Threat model deltas vs. channels
+
+**Relay can fabricate content as any member** (broader than channels, where it could
+only forge as owners). Same deniability property as channels by design; future fix is
+opt-in content signing.
+
+Everything else in the channel threat model carries over unchanged. Out of scope for
+now: member-to-member DMs in relay-mediated groups — deferred, not killed.
+
+## Sequencing & boundary
+
+Hard prerequisite: the member-profile dissemination plan
+(`2026-04-29-member-profile-sending-channels.md`) lands first. Then backend → iOS →
+Kotlin; platforms ship independently; older clients refuse to join. Owner→relay
+role/rejection-rule communication and owner-signature verification on the channel
+profile by relays are not planned here — both apply to channels equally; neither blocks
+Public groups.
diff --git a/plans/2026-05-08-public-groups-via-relays.md b/plans/2026-05-08-public-groups-via-relays.md
new file mode 100644
index 0000000000..702f06fe7f
--- /dev/null
+++ b/plans/2026-05-08-public-groups-via-relays.md
@@ -0,0 +1,378 @@
+# Plan: Public groups via relays
+
+Date: 2026-05-08
+
+## 1. Overview
+
+Channels (shipped) are relay-mediated groups in which the relay forwards
+content from any sender, but subscribers are pinned to `GRObserver` and
+cannot post. Public groups are the second value of the same two-axis design:
+same wire, same transport, members can post. The blocker is narrow — no
+path produces `groupType = GTGroup`, and the relay's joiner-role default
+comes from a global config instead of the owner-signed channel profile.
+Add a `memberRole` field to the profile, plumb it (with `groupType`)
+through the create command, derive the relay's joiner role from it, audit
+clients for sites that conflate transport with governance, ride on the
+approved member-profile dissemination plan. Member-to-member DMs in
+relay-mediated groups are deferred (§10).
+
+## 2. Concept summary: the `useRelays × groupType` matrix
+
+| `useRelays` | `groupType` | Name | Wire shape | UX |
+|-------------|-------------------------|-------------------|-------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------|
+| `false` | (no `publicGroup`) | **Secret group** | P2P `x.grp.inv` invitations; full mesh between members; JSON array batch. | Today's group: all members can post; profiles known eagerly; admins moderate. |
+| `true` | `GTChannel` | **Channel** | Relay-mediated; subscribers join via channel link; binary signed-batch format; profile carries `memberRole` (default `GRObserver` at creation). | Today's channel: only owners post; subscribers anonymous to each other. |
+| `true` | `GTGroup` | **Public group** | Same wire as channel; profile carries `memberRole` (default `GRMember` at creation); profile dissemination on demand. | New: every member can post; member-to-member DMs prohibited (deferred); member roster grown lazily via on-demand profile send. |
+| `true` | `GTUnknown _` (decode) | (refuse to join) | Channel link from a newer client; older client sees unknown discriminator. | New clients reject with a clear "needs newer version" message; pre-existing channels unaffected. |
+
+Three axes: **transport** = `useRelays` (topology, batch, signatures,
+delivery); **governance model** = `groupType` (profile dissemination,
+member affordances; member DMs prohibited in any relay-mediated group);
+**joiner role** = `memberRole` on the owner-signed profile, set at
+creation, type-keyed default. Today's client sites branch on `useRelays`
+as a proxy for `isChannel` — that's the audit work (§4.2, §5.2).
+
+## 3. Backend changes
+
+### 3.1 Wire format / protocol
+
+New optional `memberRole :: Maybe GroupMemberRole` on `PublicGroupProfile`
+(owner-signed; relays read from cache). New chat-protocol version
+`publicGroupsVersion` signals understanding of `groupType = "group"` and
+`memberRole`. Older peers decode unknown `groupType` as `GTUnknown`
+(lossless tag preservation already exists) and ignore unknown JSON fields
+— §7 covers behavior. Channel-protocol docs gain a paragraph naming
+`groupType` the discriminator and `memberRole` the owner-set joiner role.
+
+### 3.2 Type changes
+
+`PublicGroupProfile` gains `memberRole :: Maybe GroupMemberRole`. New
+single-line helpers in the same module as `useRelays'`: `groupType'` /
+`memberRole'` (accessors); `isPublicGroup'` (`useRelays' && groupType'
+== Just GTGroup`); `defaultMemberRoleFor` (`GTChannel → GRObserver`,
+`GTGroup → GRMember`, `GTUnknown _ → GRObserver` defensive);
+`joinerRoleFor` (canonical resolver — `memberRole'` if present, else
+`defaultMemberRoleFor groupType'`). `requiresSignature` unchanged for
+MVP; opt-in content signing is future-work mitigation per §6.
+
+### 3.3 API / command changes
+
+`APINewPublicGroup` / `/public group` gain `groupType` (default channel)
+and optional `memberRole` (default `defaultMemberRoleFor groupType`); both
+are written onto the constructed profile. The subscriber-side prepare-group
+flow reads `memberRole` from the resolved link with the same fallback. The
+`channelSubscriberRole` config is removed (no callers after §3.4); tests
+that flipped it migrate to Public groups or explicit `memberRole`.
+
+#### 3.3.1 Default group preferences
+
+Public-group defaults equal secret-group defaults — the channel override
+(`support = OFF`) does not apply, since member-to-moderator escalation is
+expected. Parameterize the existing channel-prefs parser by `GroupType`
+(Channel keeps its path; Public group and `GTUnknown` use secret-group).
+`directMessages` stays ON by inheritance but is **dormant** in any relay-
+mediated group (relay doesn't forward `XGrpDirectInv`; clients hide the
+toggle); keeping the wire ON lets a future plan re-enable DMs without a
+profile-shape change.
+
+### 3.4 Message processing
+
+- **Relay joiner-role derivation** (today reads `channelSubscriberRole`):
+ switch to `joinerRoleFor gInfo`. Eliminates cross-relay disparity.
+- **Member-DM defensive refusal** (`xGrpDirectInv`): when `useRelays'`,
+ emit `messageError` and create no contact. Belt-and-suspenders with the
+ §4/§5 client suppression; unreachable today (no forwarding, no P2P).
+- **Legacy `x.grp.inv`**: existing channel rejection covers Public groups.
+- **`unverifiedAllowed`**: unchanged. Tightening becomes possible once
+ the dissemination plan distributes member keys; existing TODO is
+ updated to name that precondition.
+- **Inherited unchanged** (add a test each): `checkSendAsGroup`
+ (role-based), receipts cutoff (count-based), introduce-in-channel +
+ history (`useRelays`-keyed).
+- **`memberAdmission` on relay-mediated join**: hardcoded `GAAccepted`
+ bypasses review/captcha. Generic relay-mediated-groups gap; §8.
+
+### 3.5 Database migrations
+
+No schema migration: `groupType` and `memberRole` ride the existing
+JSON-serialized profile; absent fields resolve via `defaultMemberRoleFor`.
+The dissemination plan's `sent_profile_vector BLOB` migration is a hard
+prerequisite owned by that plan.
+
+### 3.6 Test scenarios
+
+Add Public-group helpers paralleling the channel helpers, plus:
+
+1. Member sends content; all members receive it (no "unknown member" lines).
+2. Multi-author session: no "unknown member" lines anywhere.
+3. Member edit / delete / react forwarded by relay to all members.
+4. Member-DM refused on receive: inject `XGrpDirectInv`, expect `messageError`, no contact created; repeat for Channel.
+5. Role changes propagate through signed forwarding.
+6. Blocked member's subsequent messages not forwarded.
+7. Multi-relay delivery with cross-relay deduplication.
+8. History on join.
+9. `asGroup=true` from a non-owner member rejected with existing error.
+10. Receipts disabled above the 20-member limit.
+11. Older-client refusal on `groupType = "group"` shows needs-newer-version.
+12. Incognito member posting attributes the incognito profile to others.
+13. `memberRole` propagates: explicit `GRAuthor` at creation → joiners get `GRAuthor`; resolved link data carries the value.
+14. `memberRole` defaults: Channel → `GRObserver`; Public group → `GRMember`.
+15. Old-profile fallback: `memberRole = Nothing` → `defaultMemberRoleFor groupType` (`GRObserver` for Channel).
+
+## 4. iOS changes
+
+### 4.1 Model
+
+Add `case group` to `GroupType` (with serializer arms);
+`memberRole: GroupMemberRole?` on `PublicGroupProfile`; `isPublicGroup`,
+`groupType`, `memberRole` accessors on `GroupProfile`/`GroupInfo`. Client
+uses `memberRole` for display only; authoritative resolution stays on
+Haskell.
+
+### 4.2 Audit `useRelays` vs `isChannel` (≈73 sites)
+
+Per-site rule: **transport** (link/relay management, owner-can't-leave-own-
+relay-group, relay-status indicator, incognito flag display, typing-state
+gating, member-DM-affordance suppression) → keep `useRelays`. **Governance**
+(titles, "subscribers" vs "members" framing, "Channel preferences" labels,
+channel-style vs group-style member display) → switch to `isChannel`.
+Roughly 70% flip to `isChannel`. Visually compare Public / Channel / Secret
+after.
+
+### 4.3 Create flow
+
+Unified view with a "Channel / Public group" segmented control above the
+display-name field, defaulting to Channel. The toggle drives the screen
+title, link-step label, success screen, and two API parameters: `groupType`
+and `memberRole` (`.observer` for Channel, `.member` for Public group —
+no separate role picker in MVP). Default `groupPreferences` builder is
+`groupType`-keyed per §3.3.1. The `directMessages` toggle is hidden in
+the create-flow prefs section when `useRelays`. When `groupType = .group`,
+render below the title:
+
+> "In a Public group, every member can post. Messages are delivered through
+> relays you choose, which means a malicious relay could change or
+> fabricate messages from any member. Pick relays you trust."
+
+### 4.4 Strings, views, icons, connect-plan
+
+- **Strings:** ~5–10 keys mirroring channel forms with `_public_group`
+ suffixes (create/add/leave/delete/link/temporarily-unavailable/no-
+ relays), plus `create_public_group_threat_model_note`. Reuse
+ `group_members_*` for "members" framing; channels keep `_subscriber*`.
+- **Compose:** existing role-based gates allow members to post; **suppress
+ the member-tap "send direct message" affordance in any relay-mediated
+ group** (client side of the DM prohibition; receive gate at §3.4).
+- **Views:** `GroupChatInfoView` and the link view branch three ways at
+ §4.2 sites; the link view takes `groupInfo` and derives variant inside.
+ `GroupPreferencesView` hides `directMessages` when `useRelays`.
+- **Icon:** `chatIconName` gains a Public-group arm with a distinct icon
+ (different from channel-antenna and secret-group-people — §8).
+- **Members view:** show the relay-known roster; header "subscribers" for
+ channels, "members" for Public groups. No filtered view in MVP.
+- **Connect-plan:** wording keyed on resolved `groupType` — "ok to
+ subscribe via relays" (channel) vs "ok to join via relays" (Public
+ group). CLI string changes alongside; tests follow.
+
+## 5. Kotlin changes
+
+Mirror of §4 across the Compose surface. Subsections parallel §4 and
+note divergences only.
+
+### 5.1 Model
+
+`GroupType` gains `Group`; `memberRole` / `isPublicGroup` accessors on
+`GroupInfo` / `GroupProfile`.
+
+### 5.2 Audit `useRelays` vs `isChannel` (≈74 sites)
+
+Same transport-vs-governance rule as §4.2; ~70% flip to `isChannel`.
+
+### 5.3 Create flow
+
+Single-view create with Channel / Public-group toggle driving
+`groupType`+`memberRole`; threat-model note below the title;
+`directMessages` toggle hidden under `useRelays`.
+
+### 5.4 Strings, views, icons, ConnectPlan
+
+Strings, views, icons, and ConnectPlan mirror §4.4. **Kotlin-only:**
+chat-list filter chips place Public groups in the "groups" bucket
+(mental model: "things I can post in"), not "channels".
+
+## 6. Threat model: changes from channels
+
+This section assumes the channel threat model
+(`docs/protocol/channels-overview.md` §"Threat model"). Public groups
+inherit every property listed there. One threat is *broader* (channels
+have a narrower form of the same threat). The relay's "can / cannot"
+framing matches the existing doc style; the items below are written so
+they can be folded directly into a future revision of
+`channels-overview.md` once Public groups ship.
+
+### 6.A.1 A relay can fabricate content as any member
+
+Content messages (`XMsgNew`, `XMsgUpdate`, `XMsgDel`, `XMsgReact`,
+`XFileCancel`) are unsigned in both channels and Public groups
+(`Protocol.hs:1221`, `requiresSignature` lists only roster /
+administrative events). In channels this gives a compromised relay
+the ability to fabricate content attributed to owners — already
+documented in `channels-overview.md` §"Threat model" ("Substitute
+unsigned content or selectively drop messages for its subscribers").
+In Public groups, the same property has a **broader blast radius**:
+the relay can fabricate content attributed to *any* member, not just
+to owners.
+
+This matches the channel deniability property by design (see
+`channels-overview.md` §"Signing scope: roster only, content
+optional"): unsigned content is precisely what enables cryptographic
+deniability — no third party can prove a member authored anything.
+The trade-off is that the operator on the delivery path cannot be
+prevented from forging in the same channel.
+
+**A single compromised relay**
+
+*can:*
+
+- Fabricate content messages attributed to any member, not just to
+ owners. Detectable by other members through cross-relay
+ consistency (same TODO as the channel case: difference detection
+ not yet implemented).
+- Modify the text or content of messages in transit and re-attribute
+ the modified message to its original author.
+- Drop content messages selectively — same property as channels.
+
+*cannot:*
+
+- Forge signed administrative events: `XGrpInfo`, `XGrpPrefs`,
+ `XGrpMemRole`, `XGrpMemRestrict`, `XGrpMemDel`, `XGrpDel`,
+ `XGrpLeave`, `XInfo` (`Protocol.hs:1221`). Roster manipulation,
+ profile changes, and member-attributed leave / profile-update
+ events all require valid signatures.
+- Substitute the channel profile or impersonate an owner — the
+ channel's entity ID and owner authorization chain are validated
+ by every recipient against the channel link. The new `memberRole`
+ field is part of the (owner-signed) channel profile, so a
+ compromised relay also cannot fabricate a different joiner role
+ than the owner configured.
+- Alter authoritative state on owner devices.
+
+**Mitigation.** No code change for the MVP. The future-work fix is
+opt-in content signing per the channel roadmap
+(`channels-overview.md` §"Future work" / "Transcript integrity" /
+"Opt-in content signing"). When that ships, owners of Public groups
+will be able to require all content (member or owner) to carry a
+signature; member keys are already disseminated to other members
+via the prior plan (`2026-04-29-member-profile-sending-channels.md`),
+so verification on the recipient side is not a separate effort.
+
+In the meantime, the create-flow help text for "Public group" on
+both platforms (§4.3, §5.3) carries this trade-off framing: "In a
+Public group, the relay forwards messages on behalf of every member.
+A compromised relay could change message text or attribute fabricated
+messages to any member. Use a secret group if you need non-
+repudiable peer-to-peer messaging." This is the same trade-off
+channels make for owner posts; making it explicit at create time
+lets users choose Public-group-via-relay vs secret-group based on
+whether they value scale or content integrity.
+
+### 6.A.2 What is unchanged from channels
+
+Every other property of the channel threat model carries over
+without change. In particular:
+
+- A relay cannot impersonate an owner or substitute the channel
+ profile (signed events, validated entity ID). The configured
+ `memberRole` is part of the signed profile, so the relay cannot
+ unilaterally elevate or demote joiners relative to what the owner
+ specified.
+- A relay cannot determine subscriber / member real identity or
+ network address (inherited from SMP transport).
+- All-relays-compromised-and-colluding cannot forge signed events
+ or alter owner-authoritative state.
+- A passive network observer cannot determine which Public group a
+ member is in, or correlate Public-group activity with other
+ SimpleX activity.
+
+Public-group members get the same participant-privacy guarantees as
+channel subscribers, and Public-group owners get the same key-loss
+risk profile as channel owners (see `channels-overview.md`
+§"Compromise of owner keys" and §"Loss of all owner devices").
+
+**Out of scope for now: member-to-member DMs in relay-mediated
+groups.** In channels, members do not DM each other today. In Public
+groups, this plan prohibits the affordance (client-side and
+defensively on the receive path) and the relay does not forward
+`XGrpDirectInv`. The relay therefore does not see a "member DM
+graph" — that threat (which a forwarded-DM design would have
+introduced) does not exist under this plan. A future plan can
+re-introduce member-to-member DMs and revisit the metadata trade-off
+explicitly; the design space is sketched in §10.
+
+### 6.A.3 Release-notes line
+
+For the Public-groups release notes, include a one-line summary of
+the new property:
+
+> "In a Public group, the relay you choose could in principle alter
+> or fabricate group messages attributed to any member. Pick relays
+> you trust, or use a secret group if you need peer-to-peer message
+> integrity."
+
+## 7. Migration / compatibility
+
+- **Existing channels unaffected.** Pre-upgrade profiles have no
+ `memberRole`; readers fall back to `defaultMemberRoleFor GTChannel =
+ GRObserver`. No data migration.
+- **Older clients** decode `groupType = "group"` as `GTUnknown` and must
+ refuse to join with a "needs newer version" alert; they ignore unknown
+ fields on channel profiles otherwise.
+- **Older relays** forward Public-group traffic but resolve joiner role
+ from their global config — joiners via un-upgraded relays get the legacy
+ role and cannot post. Mitigation: warn the owner at create time if any
+ selected relay's chat version is below `publicGroupsVersion`. Soft
+ warning, not a hard block.
+
+## 8. Open questions
+
+1. **Future member-DM design.** (i) Relay-forwarded `XGrpDirectInv`
+ (simple; leaks DM-graph metadata); (ii) relay-blind rendezvous via
+ per-member queues on the profile (privacy-preserving; new protocol).
+ Either re-derives §6.
+2. **`memberAdmission` on relay-mediated join.** Hardcoded `GAAccepted`
+ bypasses review/captcha; generic relay-mediated-groups gap; defer.
+3. **Distinct icon for Public groups.** Visually different from channel-
+ antenna and secret-group-people metaphors. Pending design review.
+4. **`channelSubscriberRole` removal.** Verify no out-of-tree consumer
+ reads it before deleting.
+5. **`memberRole` on profile edit.** MVP exposes no UI; Haskell accepts
+ the edit but role-rebase of existing members is undefined. Deferred.
+6. **Roster filter in members view.** Paginate/filter for 100K+ members?
+ Generic relay-roster question; defer.
+7. **Connect-plan wording.** "subscribe / join / connect via relays" —
+ pick per `groupType`; update tests when CLI string changes.
+
+## 9. Sequencing
+
+1. **Prerequisite:** member-profile dissemination plan lands first.
+2. **Backend:** types, `memberRole` field, command parameters, profile-
+ based role derivation, removal of `channelSubscriberRole`, defensive
+ `XGrpDirectInv` refusal, tests 1–15.
+3. **iOS** then **Kotlin** (independent of each other; API defaults are
+ backward compatible): model, audit, create flow, strings; then views,
+ icons, ConnectPlan, DM-affordance suppression.
+4. **Older-client refusal, version-bump release notes, channel-docs
+ updates** ship with the backend release.
+
+## 10. Adjacent work (not planned here)
+
+- **Owner→relay communication of rejection rules.** Joiner-role side is
+ fixed here (travels on the signed profile); rejection-rule side
+ (admission/captcha) is still relay-side config. Future plan: carry it
+ on the profile too.
+- **Owner-signature verification on the channel profile by relays.**
+ Affects channels equally; does not gate this plan.
+- **Member-to-member DMs in relay-mediated groups.** Deferred (§1, §8 Q1).
+ A future plan must re-derive §6 — relay-forwarded DMs would re-introduce
+ (sender, target, time) metadata exposure this plan
+ avoids.
diff --git a/plans/2026-05-20-fix-hold-on-long-msg-android.md b/plans/2026-05-20-fix-hold-on-long-msg-android.md
new file mode 100644
index 0000000000..f89aa26582
--- /dev/null
+++ b/plans/2026-05-20-fix-hold-on-long-msg-android.md
@@ -0,0 +1,68 @@
+# Fix chat item long-press menu and ripple shape
+
+Branch: `nd/fix-hold-on-long-msg-android` · PR [#6997](https://github.com/simplex-chat/simplex-chat/pull/6997) · issue [#6991](https://github.com/simplex-chat/simplex-chat/issues/6991).
+
+## 1. Problem statement
+
+Two issues with the chat-item bubble on the multiplatform UI:
+
+- **Android (#6991):** long-pressing the lower part of a very tall text message did not open the select/copy/reply context menu. Long-press on the top/middle worked. Reproduced with a long multi-line message (~150+ lines — e.g. 5000 random bytes as hex); never reproduced on short messages. Occurs **only with the message tail enabled** (bubble shape); with the tail preference disabled, messages use a plain rounded-rectangle shape and the bug does not reproduce. iOS unaffected.
+- **Desktop:** the chat-item press ripple, in some cases, rendered as a rectangle instead of following the rounded bubble shape.
+
+## 2. Solution summary
+
+One function — `Modifier.clipChatItem` in `apps/multiplatform/common/src/commonMain/kotlin/chat/simplex/common/views/chat/item/ChatItemView.kt`. It clipped the chat item with `Modifier.clip(shape)` for every shape style. It now clips the **bubble** (`GenericShape`) in the draw pass with `drawWithCache` + `clipPath`, and keeps `Modifier.clip` for the **`RoundRect`** shape, which is unaffected by the bug (§3).
+
+```kotlin
+return when (style) {
+ is ShapeStyle.Bubble -> {
+ val shape = chatItemShape(cornerRoundness, LocalDensity.current, style.tailVisible, chatItem?.chatDir?.sent == true)
+ this.drawWithCache {
+ val path = Path().apply { addOutline(shape.createOutline(size, layoutDirection, this@drawWithCache)) }
+ onDrawWithContent { clipPath(path) { this@onDrawWithContent.drawContent() } }
+ }
+ }
+ is ShapeStyle.RoundRect -> this.clip(RoundedCornerShape(style.radius * cornerRoundness))
+}
+```
+
+Net diff: 1 file (`ChatItemView.kt`), +20 / −5 — the `clipChatItem` function restructured plus two imports.
+
+## 3. Root cause
+
+`Modifier.clip(shape)` is defined in Compose as `graphicsLayer(shape = shape, clip = true)`. A clipping graphics layer restricts **both** drawing **and** pointer hit-test to the shape.
+
+`clipChatItem` is the first (outermost) modifier on the chat-bubble `Column`, and that same `Column` carries the `combinedClickable` long-press handler. So the layer's hit-test region gates every press on the bubble.
+
+- **Android:** for a very tall chat item the layer's hit-test region does not cover the bubble's lower portion — a press there is never delivered to `combinedClickable`, so the long-press menu does not open. This is specific to the bubble's `GenericShape` clip: with the tail disabled the item is clipped with a `RoundedCornerShape`, which hit-tests correctly. The exact reason the `GenericShape` clip's hit-test falls short on tall content was not isolated; the fix does not depend on it (see §4).
+- **Desktop:** the layer's clip did not always extend to the `combinedClickable` press ripple, so the ripple drew to its own rectangular bounds instead of the bubble shape.
+
+## 4. The fix
+
+For the bubble shape, `clipChatItem` clips with a draw modifier instead of a graphics layer. `drawWithCache` builds the shape's `Path` once per size change; `onDrawWithContent { clipPath(path) { drawContent() } }` wraps the whole content draw — bubble background, text, and the press ripple — in a canvas clip.
+
+A draw modifier affects **only drawing**. It is not a layout or pointer-input node and has no effect on hit-test. Therefore:
+
+- the bubble and ripple are still clipped to the shape — visually identical to `Modifier.clip`;
+- pointer hit-test is no longer clipped — `combinedClickable` receives presses anywhere in the `Column`'s bounds, fixing the Android long-press;
+- the canvas `clipPath` clips the ripple reliably, fixing the rectangular desktop ripple.
+
+The `RoundRect` shape keeps `Modifier.clip`: it hit-tests correctly (no bug) and keeps its antialiased outline clip. Scoping by shape — rather than draw-clipping every shape — leaves every non-bubble chat item (service/event messages, tails-off messages, old Android) byte-for-byte unchanged.
+
+## 5. Alternatives rejected
+
+- **Remove `clipChatItem` from the bubble `Column`.** Fixes the Android long-press, but the press ripple loses its shape and renders as a rectangle. Intermediate state during development; replaced.
+- **Draw-pass clip for every shape, unconditionally.** Also correct and a hair simpler (no `when`), but it needlessly moves the `RoundRect` shape off `Modifier.clip`'s antialiased outline clip onto a canvas `clipPath` — a behaviour change with no benefit, since `RoundRect` has no bug. Scoping to the bubble shape keeps `RoundRect` unchanged.
+- **Keep `Modifier.clip`, move `combinedClickable` off the clipped `Column`.** A larger structural change to the chat-item layout tree; the draw-pass clip fixes both issues without moving anything.
+
+## 6. Verification
+
+- **Android** (debug APK): long-press on the lower half of a 150+-line message opens the context menu; top/middle still work; the tap ripple stays bubble-shaped; swipe-to-reply and link tap/long-press are unaffected.
+- **Desktop** (Linux AppImage): the chat-item press ripple follows the bubble shape (rounded corners and tail), not a rectangle — confirmed against a build without the fix.
+- The bubble draw-pass clip above was verified on those Android and desktop builds; this revision additionally keeps `Modifier.clip` for the `RoundRect` shape, which is the unchanged pre-fix behaviour.
+
+## 7. Risk and rollback
+
+- Blast radius: the `Bubble` branch of `clipChatItem`. The `RoundRect` branch is unchanged (`Modifier.clip` as before), so service/event items, tails-off messages and old-Android items are untouched. For the bubble, drawing is clipped identically; the single behavioural change is that pointer hit-test on the bubble is no longer shape-clipped — benign (bubble corners are transparent; a rectangular hit area is a marginally larger touch target).
+- iOS is a separate codebase and is untouched.
+- Rollback: revert the fix commit on the branch, or drop it before merge.
diff --git a/plans/2026-05-20-member-deletion-fulldelete.md b/plans/2026-05-20-member-deletion-fulldelete.md
new file mode 100644
index 0000000000..9d6e516b00
--- /dev/null
+++ b/plans/2026-05-20-member-deletion-fulldelete.md
@@ -0,0 +1,73 @@
+# Full delete on member removal under fullDelete preference
+
+Plan for the next attempt at the change previously tried in PR #6831 (closed as too messy: the member row was deleted twice on one path, and the user's own membership row was deleted when the user was the one removed). The change is small: two SQL-function edits, one new chat-layer helper, an explicit fullDelete branch plus order swap in two backend handlers, and one in-memory removal branch in `removeMemberItems` on each UI platform.
+
+## Problem
+
+When a member is removed via `XGrpMemDel` with `withMessages = True` and the group's `fullDelete` preference is on for the deleter's role, the member's chat items are currently rewritten to `CIModerated` placeholders by `updateMemberCIsModerated`, and the member row is preserved by `deleteOrUpdateMemberRecord` when any item references it. The intent of `fullDelete` is physical deletion. The current behavior leaves placeholder rows and, because `deleteOrUpdateMemberRecord` runs before the items pass, the relay subpath of the latter deletes the member row first and the subsequent file collection returns nothing — files on disk leak. The same ordering bug exists on the moderator side (`APIRemoveMembers`).
+
+## What changes
+
+In `xGrpMemDel` (`src/Simplex/Chat/Library/Subscriber.hs:3157`), only on the branch where `withMessages = True` AND `groupFeatureMemberAllowed SGFFullDelete m gInfo`:
+
+**Case A — the deleted member is the user themselves (`memId == membership.memberId`).** The user's own sent items (those with `group_member_id IS NULL AND item_sent = 1`) and their files are physically deleted. The `membership` row stays with status `GSMemRemoved`, so the group can still be loaded in the chat list and opened.
+
+**Case B — the deleted member is somebody else.** The member's chat items and their files are physically deleted, then the `group_members` row is deleted. Historical system event items that referenced this member as `item_deleted_by_group_member_id` survive with NULL via the existing `ON DELETE SET NULL`.
+
+The non-fullDelete branch, the `withMessages = False` branch, and the entire message-moderation path (`XMsgDel`, `APIDeleteMemberChatItem`, `deleteGroupCIs`, `markGroupCIsDeleted`, `createCIModeration`, `chat_item_moderations`) are not changed.
+
+## Implementation
+
+The whole change is two SQL-function edits in `Store/Messages.hs`, a new member-record helper in `Library/Internal.hs`, and explicit branching plus an order swap in both `xGrpMemDel` (recipient side) and `APIRemoveMembers` (moderator side).
+
+**Edit 1 — rewrite `updateMemberCIsModerated` to physically delete.** Recommended rename: `deleteMemberCIs`. Keep the existing `memId == groupMemberId' membership` branch unchanged (the membership branch selects `WHERE group_member_id IS NULL AND item_sent = 1`; the other branch selects `WHERE group_member_id = ?`). Change the body from "UPDATE chat_items SET moderated content" to "physically delete chat_items + side-table rows analogous to `deleteGroupChatItem` in bulk": delete from `chat_item_messages`, `chat_item_versions`, `chat_item_reactions`, then `DELETE FROM chat_items`. The function loses the `byGroupMember`, `msgDir`, and `deletedTs` parameters since they were only used to construct the moderated content. The chat-layer wrappers `deleteGroupMemberCIs` and `deleteGroupMembersCIs` follow the same signature simplification.
+
+**Edit 2 — extend `getGroupMemberFileInfo` to handle the membership case.** Today it queries `WHERE group_member_id = ?` only, so for Case A it returns nothing and files for the user's own sent items leak (this is a pre-existing bug on both the off and on paths — `markGroupMemberCIsDeleted_` also relies on this function to cancel in-progress transfers). Add the same `memId == groupMemberId' membership` branch as in `deleteMemberCIs`: for the membership case, query `WHERE group_member_id IS NULL AND item_sent = 1`. The only two callers (`deleteGroupMemberCIs_` and `markGroupMemberCIsDeleted_`) both benefit from the fix.
+
+**Edit 3 — add `fullyDeleteMemberRecord` helper in `Library/Internal.hs` next to `deleteOrUpdateMemberRecord`.** Wraps `deleteSupportChatIfExists` + `deleteGroupMember`, returns updated `GroupInfo`. No `isRelay` branch and no `checkGroupMemberHasItems` query — the caller has already physically deleted the member's items, so the existence check would be a wasted query and the function communicates intent explicitly: unconditional row deletion. The `CM` wrapper plus an `IO` variant (`fullyDeleteMemberRecordIO`) mirror the shape of the existing `deleteOrUpdateMemberRecord` / `deleteOrUpdateMemberRecordIO`.
+
+**Edit 4 — swap order and add explicit branching in `xGrpMemDel` Case B (the `else` branch).** Move `when withMessages $ deleteMessages gInfo'' deletedMember' SMDRcv` to run *before* the member-record decision, on the same `gInfo` (the new `deleteMessages` reads only `groupId` and `membership` from the passed `gInfo`). Replace the current member-record dispatch with an explicit branch:
+
+```
+gInfo' <- case deliveryScope of
+ Just (DJSMemberSupport _) | shouldForward -> updateMemberRecordDeleted user gInfo deletedMember GSMemRemoved
+ _ -> if withMessages && groupFeatureMemberAllowed SGFFullDelete m gInfo
+ then fullyDeleteMemberRecord user gInfo deletedMember
+ else deleteOrUpdateMemberRecord user gInfo deletedMember
+```
+
+`deleteMemberItem` (the RGE event creation) keeps its current position after `updatePublicGroupData`. Case A (the `then` branch) needs no order change — the membership row is never deleted there, and `deleteMessages` already runs in the right relative position.
+
+The `DJSMemberSupport _ | shouldForward` subcase keeps its existing `updateMemberRecordDeleted` call regardless of fullDelete — the row is preserved for support-scope forwarding. Under fullDelete the items are still gone (the `deleteMessages` step ran first), the row stays.
+
+**Edit 5 — mirror the swap and explicit branching in `APIRemoveMembers` (`src/Simplex/Chat/Library/Commands.hs:2834`).** Inside `deleteMemsSend`, compute `fullDelete = withMessages && groupFeatureUserAllowed SGFFullDelete gInfo` once. Move the items pass to before `delMember`: run `deleteMessages user gInfo memsToDelete` inside `deleteMemsSend` before the `withStoreBatch'` that calls `delMember`. Change `delMember` to branch explicitly:
+
+```
+delMember db m = do
+ if fullDelete
+ then void $ fullyDeleteMemberRecordIO db user gInfo m
+ else void $ deleteOrUpdateMemberRecordIO db user gInfo m
+ pure m {memberStatus = GSMemRemoved}
+```
+
+`deletePendingMember` flows through `deleteMemsSend` and inherits the new behavior. The outer line 2864 call (`when withMessages $ deleteMessages user gInfo' deleted`) collapses — items are already handled inside `deleteMemsSend` for current and pending members, and invited members (handled by `deleteInvitedMems`) have no chat items. Remove it.
+
+**Edit 6 — extend `removeMemberItems` on both UI platforms to physically remove items from the in-memory list when `fullDelete.on`.** Today (iOS `apps/ios/Shared/Model/ChatModel.swift:814-846`, Kotlin `apps/multiplatform/common/src/commonMain/kotlin/chat/simplex/common/model/ChatModel.kt:699-734`) the function walks the in-memory items, identifies matches by direction and member id, and sets `itemDeleted = .moderated(...)`; under `fullDelete.on` it additionally rewrites content to `Snd/RcvModerated`. Items are never removed from `im.reversedChatItems` / `chatItems.value`. After the backend change, the chat_item rows are physically gone in DB while the UI keeps stale moderated placeholders until the next refetch — flicker. Extend the existing `fullDelete.on` branch so it also removes matching items from the in-memory list (iOS: drop them from `im.reversedChatItems`, decrement unread counters, stop voice playback on dropped items; Kotlin: `removeAllAndNotify { isMemberItem(it) }` equivalent, decrement counters, stop audio). The fullDelete-off branch is unchanged (still marks moderated in place).
+
+The three callers — iOS `removeMember` in `GroupChatInfoView.swift:977`, Kotlin `removeMembers` in `GroupChatInfoView.kt:1316`, Kotlin `removeMember` in `GroupMemberInfoView.kt:339`, and the event handlers for `.deletedMember`/`.deletedMemberUser` in `SimpleXAPI.swift:2578-2596` and `SimpleXAPI.kt:2945-2973` — all converge on the same `removeMemberItems` function on each platform and inherit the new behavior automatically. The chat-list preview path inside `removeMemberItems` (the `else` branch that updates `chat.chatItems[0]`) also needs to drop the preview item under fullDelete so the chat list doesn't show a stale moderated last-message.
+
+The `fullDelete.on` gate matches the backend's `groupFeatureMemberAllowed SGFFullDelete` / `groupFeatureUserAllowed SGFFullDelete` because FullDelete is a `GroupFeatureNoRoleI` feature — the role check collapses to the `.on` check.
+
+## Anti-patterns from PR #6831 to avoid
+
+No path may call `deleteGroupMember` twice. No path under Case A may delete the `membership` row — that row must survive. File info must be collected before any chat-item deletion, since `getGroupMemberFileInfo` reads `chat_items`. Do not rely on `ON DELETE SET NULL` to clean up the deleted member's authored items — they are deleted explicitly first. `fullyDeleteMemberRecord` is the only function that should call `deleteGroupMember` directly on the new path; do not duplicate that call in the handler.
+
+## Tests
+
+Add cases in `tests/ChatTests/Groups.hs` for: Case A (user removed by admin, fullDelete on — user's sent items and their files gone, `membership` row exists with `GSMemRemoved`, group still loadable); Case B (member removed by admin, fullDelete on — member's items and files gone, `group_members` row gone, system event items previously referencing the removed member now have NULL `item_deleted_by_group_member_id` and still display correctly); regression for fullDelete=off (items become `CIModerated` placeholders via `markMemberCIsDeleted`); regression for `withMessages = False` (items untouched, row handled by existing path); regression that message moderation under fullDelete=on still produces `CIModerated` placeholders, confirming the moderation path is unchanged. Verify the same Case A and Case B behaviors over both XGrpMemDel (recipient side, Subscriber.hs) and APIRemoveMembers (moderator side, Commands.hs).
+
+UI checks for the manual smoke test: in a group with fullDelete on, remove a member with messages — that member's bubbles disappear immediately from the open chat view on both moderator's and recipients' devices, the chat list preview updates to the previous non-deleted message, and the unread/report counters decrement; with fullDelete off, the same removal produces moderated placeholders as today. Verify on iOS, Android, and Desktop.
+
+## Open items for review
+
+Naming of the rewritten `updateMemberCIsModerated`: `deleteMemberCIs` is the natural rename (the function physically deletes chat items associated with a member, handling the membership case internally). Naming of the new chat-layer helper: `fullyDeleteMemberRecord` (parallels `deleteOrUpdateMemberRecord`). Confirm or amend before implementation.
diff --git a/plans/2026-05-25-fix-e2e-encryption-section-divider.md b/plans/2026-05-25-fix-e2e-encryption-section-divider.md
new file mode 100644
index 0000000000..69d4bd630a
--- /dev/null
+++ b/plans/2026-05-25-fix-e2e-encryption-section-divider.md
@@ -0,0 +1,50 @@
+# Fix E2E encryption section divider rendered inside the section
+
+Branch: `nd/fix-e2e-encryption-section-divider` · base: `master`.
+
+## Problem
+
+On the contact info screen (Android and desktop, current `master`), the "E2E encryption — Quantum resistant / Standard" card has a horizontal divider line cutting across it under its single row, followed by extra padded space — visually reading as the card being sliced in two with a second, empty card underneath. Repros for any 1:1 contact with an active connection. Behaviour of the row itself is correct; bug is purely visual.
+
+## Fix
+
+One line in `apps/multiplatform/common/src/commonMain/kotlin/chat/simplex/common/views/chat/ChatInfoView.kt` — move `SectionDividerSpaced()` out of the `SectionView { ... }` block:
+
+```diff
+ if (conn != null) {
+ SectionView {
+ InfoRow("E2E encryption", if (conn.connPQEnabled) "Quantum resistant" else "Standard")
+- SectionDividerSpaced()
+ }
++ SectionDividerSpaced()
+ }
+```
+
+Total diff: 1 file, +1 / −1.
+
+## Cause
+
+Two unrelated changes combined to produce the visible bug:
+
+1. PR #4060 (`9e3f528d4`, "android: remove experimental PQ toggle") removed the conditional `AllowContactPQButton` / `SectionTextFooter` that used to sit between the `InfoRow` and the divider — but left `SectionDividerSpaced()` inside the `SectionView { ... }` block. At that point `SectionView` was a plain column, so the leftover divider only looked like extra inter-section spacing.
+
+2. PR #6777 (`df5ea3d46`, "android, desktop: new settings section design") wrapped `SectionView`'s content in `CardColumn` with `SectionCardShape`, giving each section a rounded card background. After this, *anything* drawn by the section content — including the leftover `Divider` — is drawn inside the card.
+
+Rendered structure on current master:
+
+```
+SectionView (card background, rounded shape)
+ └ CardColumn
+ ├ InfoRow("E2E encryption", ...)
+ ├ Divider ← line cutting across the card
+ └ 18 dp bottom padding ← reads as a second, empty card
+```
+
+After the fix the divider re-parents to the enclosing `ChatInfoLayout` column and sits between the E2E card and the next section's card, matching the pattern used by every other section on the screen.
+
+## Risk
+
+- One composable call site, structural move of a single node; no logic, state, or styling change.
+- iOS is a separate codebase and is unaffected.
+- Grep confirms no other `SectionDividerSpaced` call sits inside a `SectionView { ... }` in `apps/multiplatform`.
+- Rollback: `git revert` the fix commit.
diff --git a/plans/2026-05-26-fix-invalid-mention-on-edit.md b/plans/2026-05-26-fix-invalid-mention-on-edit.md
new file mode 100644
index 0000000000..2fe9bad5a5
--- /dev/null
+++ b/plans/2026-05-26-fix-invalid-mention-on-edit.md
@@ -0,0 +1,107 @@
+# Fix "error store invalidMention" and preserve mention bindings across in-place edits
+
+## Symptom
+
+Rare "Error sending message: error store invalidMention" when sending a group
+message that contains an @mention.
+
+## Root cause
+
+When the user picks a member from the picker, the client inserts `@Name` into
+the message text and records `mentions[Name] = memberId` in the compose
+state. The original `removeUnusedMentions` only pruned that map when the
+parsed `@name` count was **strictly less** than the map size:
+
+```kotlin
+if (usedMentions.size < composeState.value.mentions.size) { ... }
+```
+
+If the user **edits the inserted token in place** (e.g. fixes a typo, deletes
+one character) without re-picking from the picker, the parser sees one
+mention with the new name while the map still contains the old key. Both
+have size 1, so the guard does not fire and the stale entry is sent. The
+core's `getCIMentions` (`Internal.hs:267-271`) requires every key in the
+client-supplied mentions map to also appear as a parsed `@name` token in the
+message text, and throws `SEInvalidMention` otherwise.
+
+A naive fix (prune whenever any key is missing from the parsed names) stops
+the crash but also drops the binding the instant a letter is removed — so
+typing the letter back leaves an unresolved `@name` rather than a real
+mention.
+
+## Approach
+
+Stop mutating the compose-state mentions map while editing. Treat the map
+as a sticky cache of `name → memberId` bindings recorded by the picker, and
+filter against the currently-parsed text only at the points where a "current
+set of mentions" is actually needed: sending, picker UX, name
+disambiguation. This both eliminates the `SEInvalidMention` failure and
+lets a round-trip edit (`@Usernama` → `@Usernam` → `@Usernama`) re-resolve
+the original member.
+
+## Changes
+
+### 1. Drop `removeUnusedMentions`
+
+- `apps/multiplatform/.../GroupMentions.kt`: delete the function and its call
+ in `messageChanged`.
+- `apps/ios/.../GroupMentions.swift`: same.
+
+### 2. Filter at send time via `memberMentions`
+
+`ComposeState.memberMentions` intersects the cached map with the names
+currently parsed in `parsedMessage`. All sends already route through this
+getter, so this is the single chokepoint that determines what reaches the
+core.
+
+### 3. Picker "max reached" uses parsed-mention count
+
+`GroupMentions.kt:213,231` and the Swift equivalent at `GroupMentions.swift:50`
+switch from `composeState.mentions.size` to a count of `Format.Mention`
+entries in `parsedMessage`. This keeps the limit aligned with what the
+server will see, regardless of how many stale entries the cache holds.
+
+### 4. `mentionMemberName` disambiguation uses parsed names
+
+`ComposeView.kt`'s `mentionMemberName` walks the set of parsed mention names
+instead of `mentions.containsKey`. Same for Swift. A stale cache entry no
+longer pushes a fresh pick to an awkward `_1` suffix, and a picker tap on a
+broken `@alic` cleanly replaces it with `@alice`.
+
+### 5. Editing-an-existing-item path
+
+`ComposeState(editingItem, ...)` seeds `mentions = editingItem.mentions`.
+That stays as-is — it is already a sticky cache and the new `memberMentions`
+getter handles filtering.
+
+## Manual reproduction (original bug)
+
+1. In a group, type `@` and pick a member. Text becomes `@Name ` and the
+ mentions map gets `{Name → memberId}`.
+2. Place the cursor inside the inserted name and add or delete one character
+ (`@Nam`, `@Names`, etc.) — do not use the picker.
+3. Tap send. Before the fix: send fails with `error store invalidMention`.
+ After the fix: message is sent.
+
+## Edge cases to test
+
+- Pick `Usernama`, delete last `a`, retype it → send: mention resolves to
+ the original member (restoration behaviour).
+- Pick `Usernama`, delete the whole token → send: no mention. Cache still
+ holds a stale `Usernama` entry but `memberMentions` is empty.
+- Pick `alice` (member A), delete the `@alice` text, then pick a different
+ `alice` (member B) → inserted as `@alice` (the cleaner, visible name);
+ cache key rebinds A→B as an explicit user action.
+- Two members with same display name, pick A, edit `@alice` → `@alic` →
+ `@alice` by typing only → A's binding is restored (typing never mutates
+ the cache; only picker taps do).
+- Pick 3 members, delete one of the tokens — picker should not show
+ "max reached"; only 2 mentions are now in the text.
+- Edit an existing sent message: original mentions render, surviving edits
+ re-bind, removed ones disappear from `memberMentions` on send.
+
+## Out of scope
+
+- No core changes. `getCIMentions` (`Internal.hs:267-271`) stays as-is;
+ this is purely client-side cache lifecycle.
+- No change to the @-picker trigger heuristic in `messageChanged`.
diff --git a/plans/2026-05-26-fix-video-drag-and-drop.md b/plans/2026-05-26-fix-video-drag-and-drop.md
new file mode 100644
index 0000000000..16258dea7f
--- /dev/null
+++ b/plans/2026-05-26-fix-video-drag-and-drop.md
@@ -0,0 +1,44 @@
+# Fix desktop drag-and-drop of videos attached as files
+
+Branch: `nd/fix-video-drag-and-drop` · base: `master`.
+
+## Problem
+
+On desktop, dragging a video file into a chat attaches it as a generic file (paperclip + filename) instead of as a video (thumbnail + duration). Dragging an image works. Picking the same video via "Gallery → Video" attaches it correctly — so only the drag-and-drop routing is wrong.
+
+## Fix
+
+One file: `apps/multiplatform/common/src/commonMain/kotlin/chat/simplex/common/views/chat/ComposeView.kt`. Recognise videos as media in `onFilesAttached`'s classifier.
+
+```diff
+ fun MutableState.onFilesAttached(uris: List) {
+- val groups = uris.groupBy { isImage(it) }
+- val images = groups[true] ?: emptyList()
++ val groups = uris.groupBy { isImage(it) || isVideoUri(it) }
++ val media = groups[true] ?: emptyList()
+ val files = groups[false] ?: emptyList()
+- if (images.isNotEmpty()) {
+- CoroutineScope(Dispatchers.IO).launch { processPickedMedia(images, null) }
++ if (media.isNotEmpty()) {
++ CoroutineScope(Dispatchers.IO).launch { processPickedMedia(media, null) }
+ } else if (files.isNotEmpty()) {
+ processPickedFile(uris.first(), null)
+ }
+ }
++
++private fun isVideoUri(uri: URI): Boolean {
++ val name = getFileName(uri)?.lowercase() ?: return false
++ return name.endsWith(".mov") || name.endsWith(".avi") || name.endsWith(".mp4") ||
++ name.endsWith(".mpg") || name.endsWith(".mpeg") || name.endsWith(".mkv")
++}
+```
+
+Total diff: 1 file, +11 / −5.
+
+## Cause
+
+`onFilesAttached` classified URIs by `isImage` only — non-images (including videos) fell through to `processPickedFile`, producing a `FilePreview`. The downstream `processPickedMedia` already handles video correctly (its `else` branch builds `UploadContent.Video`); the classifier above it just never reached that branch. The existing `isVideo` in `Videos.desktop.kt` is `desktopMain`-only and not visible from `ComposeView.kt` in `commonMain` — the structural gap that left the classifier video-blind. The inline `isVideoUri` uses the cross-platform `getFileName`, so the same fix also corrects the paste path (`onFilesPasted` at `ComposeView.kt:1378`).
+
+## Risk
+
+One file, no interface change. Image and non-media drops are bit-identical. Video extension list is now duplicated with `Videos.desktop.kt`; adding a new format means updating both — accepted as the cost of a single-file fix. iOS unaffected. Rollback: revert the commit.
diff --git a/plans/2026-05-26-public-groups-via-relays-unified.md b/plans/2026-05-26-public-groups-via-relays-unified.md
new file mode 100644
index 0000000000..91f7c3a6ce
--- /dev/null
+++ b/plans/2026-05-26-public-groups-via-relays-unified.md
@@ -0,0 +1,227 @@
+# Plan: Public groups via relays (unified)
+
+Date: 2026-05-26
+
+This plan is self-contained. It supersedes `2026-05-08-public-groups-via-relays.md` and folds in the privileged-roster mechanism understood since. Implementers should work from this document alone. File:line anchors are current as of this date — confirm before editing.
+
+## Overview
+
+Channels (shipped) are relay-mediated groups where the relay forwards content from owners only; subscribers are pinned to `GRObserver` and cannot post. Public groups are the second value of the same two-axis design: same wire, same transport, but every member can post, and there are moderators/admins who can act.
+
+| `useRelays` | `groupType` | Name | Posting | Notes |
+|---|---|---|---|---|
+| `false` | (none) | Secret group | all members | today's P2P full-mesh group |
+| `true` | `GTChannel` | Channel | owners only | shipped; subscribers anonymous to each other |
+| `true` | `GTGroup` | **Public group** | every member | **new**; member-to-member DMs deferred |
+| `true` | `GTUnknown _` | (refuse) | — | newer-client link seen by older client → refuse to join |
+
+Three concepts, kept distinct: **transport** = `useRelays` (topology, batch, signatures, delivery); **governance** = `groupType` (who may post, member affordances); **joiner role** = the default role new joiners get, set by the owner on the signed profile.
+
+Two things make public groups work and neither exists today:
+
+1. **The joiner role must come from the owner-signed profile**, not a relay-side global config — otherwise relays disagree on the default role. (Section 2.)
+2. **Members must learn who the moderators/admins are — their identity, signing key, and role — in a way a relay cannot forge.** Today a relay can fabricate a moderator (Section 1, Problem). This is the load-bearing piece and ships first.
+
+`GTGroup`, `PublicGroupProfile`, `useRelays'`, and the relay/signing/forwarding machinery already exist (anchors below). The work is additive.
+
+---
+
+# Section 1 — Privileged roster (`XGrpRoster`)
+
+This is a **general relay-group mechanism**: public groups use it now; channels inherit it for their multi-owner/moderator future. It is the first, self-contained task.
+
+## 1.1 Problem and trust model
+
+Owners are trusted because their keys come from the **link**, never the relay: on join, `createLinkOwnerMember` (`Store/Groups.hs:3072`) writes each owner's `member_pub_key` from the link's `OwnerAuth` chain, validated against `publicGroupId == sha256(rootKey)`. `xGrpMemIntro` even nulls the key when `mRole == GROwner` (`Subscriber.hs:3029`): *"owner key must only come from link data, not from relay intro."*
+
+Non-owner privileged members have no such anchor. Today `xGrpMemIntro` **keeps** the relay-asserted key for `GRModerator`/`GRAdmin`, and `introduceInChannel` (`Internal.hs:1165`) introduces all of `getGroupModerators` (which returns mod+admin+owner, `Store/Groups.hs:1190`). So a malicious relay can assert "X is a moderator, here is X's key," and the subscriber will then trust the relay-chosen key to verify X's signed administrative actions (`XGrpMemDel`, `XGrpMemRestrict`, `XGrpMemRole`). The `when (memRole > GRMember)` gate in `xGrpMemNew` (`Subscriber.hs:2957`) blocks the *dissemination* path but not the *join-time intro* path — the protection is half-applied. Dormant for channels (single-owner broadcast), activated by public groups.
+
+**Conclusion:** a non-owner privileged member's `(memberId, name, key, role)` must be **owner-signed**, exactly like owners are link-signed. That is the roster.
+
+## 1.2 Wire event and signing
+
+New event `XGrpRoster` (add to `ChatMsgEvent`, `Protocol.hs:422`), JSON-encoded, carrying:
+
+- `version :: Word32` — monotonic, from 0.
+- `roster :: [{ memberId, name, key, role }]` — the complete current privileged set, `role ∈ {GRModerator, GRAdmin}`. `name` is a display name only (to avoid ugly "unknown member" records, as `XGrpMsgForward` already carries one). Owners are **not** in the roster.
+
+Add `XGrpRoster_` to `requiresSignature` (`Protocol.hs:1231`) ⇒ `True`. This makes the owner sign it via the existing `groupMsgSigning` (`Internal.hs:1962`, binding `CBGroup <> (publicGroupId, ownerMemberId)`, key `groups.member_priv_key`) and makes recipients require a valid owner signature via `withVerifiedMsg` (`Subscriber.hs:3461`). No new crypto.
+
+**The handler MUST assert the resolved author is an owner** (`memberRole' author == GROwner`). `withVerifiedMsg` verifies the signature against the *author's* key, and the relay chooses `fwdSender` — so without this assertion a relay could route a roster as a member whose key it controls and the signature would verify. Owners exist on recipients only via the link `OwnerAuth` chain, so a relay can neither fabricate an owner nor sign as one. This assertion is the crux of the roster's integrity.
+
+## 1.3 Authoritative model — versioned snapshot, latest-wins, TOFU keys
+
+Each `XGrpRoster` is the complete current privileged set. Recipients treat the highest-version valid roster as authoritative for *who is privileged and their keys*; absence from the newest accepted roster means *not privileged* (reverts to the joiner default unless an accompanying `XGrpMemRole` sets a specific role — see 1.6). This is self-healing: a member who missed one change gets the full current state on the next roster.
+
+**Key handling is trust-on-first-use, pinned per `memberId`** (per entry):
+
+- `memberId` unknown, or known without a key → store the key (first sight, from the owner). Set name/role.
+- `memberId` already has a key:
+ - same key → fine; update name/role.
+ - **different key → error.** Never overwrite; keep the old key; surface a suspicious-roster event.
+
+There is **no in-place key rotation**: a genuine re-key is modeled as a *new member* — the owner removes the old `memberId` (`XGrpMemDel` + roster drop) and adds a new `memberId` with the new key. Consistent with SimpleX's no-mutable-identity stance, and with the `xGrpMemNew` rule in 1.5.
+
+**Anti-replay / rollback.** The relay cannot forge a signed roster but can replay an older one.
+
+- The current roster `version` is anchored in the owner-controlled link mutable data (which already holds `OwnerAuth`, profile, subscriber count). The relay cannot forge it. A roster change that bumps the version also updates link data. **Status:** the write side is implemented; the join-time **read/detect** is deferred — comparing the anchor against the relay-served roster at join is racy (the forwarded roster may not have arrived yet → false positives), so correct staleness detection must be triggered by roster arrival, not at join. The residual new-joiner rollback gap below stands; the hard anti-replay (member + relay) is in place.
+- **Existing members** reject any roster with `version` below the highest already accepted — full anti-replay for them.
+- **New joiners** process the latest version the relay actually serves, even if it lags the link anchor, so honest relay propagation lag never blocks a join. The anchor is used for staleness *detection*, not a hard gate, in v1.
+- **Documented residual gap:** a stale/malicious relay can serve an old-but-valid roster to a brand-new joiner. Documented in `channels-overview.md` with future mitigations: escalate verification to an owner, or have the client compare the relay's version to the link anchor and refuse/retry above a staleness threshold.
+
+## 1.4 Cap on the privileged set
+
+Bound the privileged set so the signed roster always fits one message — never paginate. A hard **cap on moderators + admins** (owners are on the link, not counted), enforced **at promotion time** on the owner: refuse to elevate beyond the cap with a clear error, so the roster is always constructible as one signed message.
+
+Derive the number from the single encoded-message budget (verify the exact constant — the encoded-message-length limit minus signature + JSON overhead) divided by worst-case entry size. With `{memberId, name, key, role}` entries this is comfortably in the tens-to-~100 range; pick the final value from the measured worst-case entry.
+
+## 1.5 Remove the dissemination gates; gate on the roster instead
+
+Because the relay forwards the roster on join **before anything else**, a privileged member's key/role is owner-established before any relay-asserted introduction arrives. So the relay may now disseminate privileged members' full profiles like any other member, and the gates come out:
+
+- **Remove** the `when (memRole > GRMember)` throw in `xGrpMemNew` (`Subscriber.hs:2957`).
+- **Remove** the forward-side `memberRole' s <= GRMember` filter in `sendBodyToMembers` (confirm exact site in `Subscriber.hs`).
+- **Replace** with a roster check in `xGrpMemNew`: for an announcement of a privileged role, require that a member record with that `memberId` already exists **with that privileged role** (roster-established). If found → accept the **profile** update only; **never overwrite `key`, `memberId`, or `role`** (roster-authoritative). If not found → reject (a relay conjuring a privileged member not in the roster).
+
+`introduceInChannel` forwards the cached roster to the new member first, then proceeds; it may still announce the newcomer to moderators and maintain the relations vector. The per-mod `XGrpMemIntro` carrying keys is no longer the trust path for privileged members.
+
+## 1.6 Delivery — what is sent, when, to whom
+
+Two orthogonal axes, and the roster owns only one:
+
+- **Axis A — privileged set + keys** (who is mod/admin, their key/name/role): owned by the roster.
+- **Axis B — group-membership lifecycle** (removed / restricted / left): owned by `XGrpMemDel` / `XGrpMemRestrict` / `XGrpLeave`, unchanged, applies to everyone.
+
+Dispatch by whether an operation touches the {moderator, admin} set (the *roster roles*). Owner is not a roster role — promotion to/from owner uses `XGrpMemRole` (+ link `OwnerAuth`), never the roster.
+
+**`APIMembersRole` (role change, possibly batched):**
+
+- Emit `XGrpMemRole(M, target)` for each affected member exactly as today — this conveys the exact target role for any role, including owner and specific ≤member roles.
+- **Additionally** build and **broadcast** the full signed roster (version++) **iff the {mod, admin} set changed** (any member entered, left, or moved within mod/admin).
+- A mixed batch fires both. Example: target=member over `[moderator M, observer O]` → `XGrpMemRole` for both (exact roles) **and** a roster (M left the set). The promotion case `XGrpMemRole(M, mod)` + roster is mildly redundant on the role field and harmless; the key comes only from the roster.
+
+The broadcast reuses the existing owner-admin-event forwarding (`shouldForward = isUserGrpFwdRelay gInfo && not forwarded`, `Subscriber.hs:3191`). Privileged-set changes are rare administrative events, so this is on the order of an `XGrpInfo`/`XGrpPrefs` broadcast — not per-message. The broadcast roster is the **self-healing** mechanism: a member who missed a prior `XGrpMemRole` is corrected by the snapshot.
+
+**`XGrpMemDel` (removal):** broadcast `XGrpMemDel` as today (it neutralizes the member for existing members). If the removed member was privileged, the owner sends a refreshed roster (version++), which the relay broadcasts like any other version bump (see below).
+
+**Relay broadcast rule — always broadcast on a strict version bump.** A newer-version roster is applied, cached, and broadcast to current members, uniformly — promotion, key/role change, demotion, or privileged removal. We do **not** try to make removal cache-only: a demotion (member stays in the group) is indistinguishable from a deletion at the roster-diff level, so suppressing the broadcast would silently drop the self-healing the spec requires for role changes. The only cost is one redundant roster broadcast alongside `XGrpMemDel` on the rare deletion of a privileged member — and even there the broadcast is not waste, since it self-heals the privileged-set side if the `XGrpMemDel` was lost. (This supersedes an earlier "cache-only on deletion" idea, which could not be implemented without either a wire flag or a fragile demotion-vs-deletion diff.)
+
+**On relay add:** the owner sends the current roster to the new relay so it can serve joiners.
+
+**Joiners:** the relay forwards the cached roster at join (1.5).
+
+**Short offline gaps** are covered by ordinary queued delivery: the role-change roster broadcast sits in the member's SMP queue (FIFO) ahead of any later moderator events, so it is processed first on reconnect.
+
+**Quota-blocked catch-up.** A member offline long enough to fill its queue causes the relay to be quota-blocked — the broadcast may never have been enqueued, so naive queueing would leave the member without the current roster, rejecting moderator events indefinitely. Fix: when the queue drains, the relay **sends the current cached roster ahead of the resumed backlog**, so the member holds the current privileged set before processing the events it couldn't verify.
+
+The hook is confirmed: QCONT is delivered to the **sender** when the recipient drains (`simplexmq Agent.hs:3402`), and the relay receives it per subscriber in the group-member connection handler (`Subscriber.hs:1215` — `continueSending` + `sendPendingGroupMessages user gInfo m conn`, with `gInfo`/`m`/`conn` in scope; a relay→subscriber connection is a group-member connection). Implementation must ensure **roster-first ordering** relative to both the agent-level `continueSending` flush and the re-driven delivery tasks, and gate the extra send on a per-member "delivered roster version" so it fires only when the member is behind.
+
+The roster is **never** delivered through the profile-dissemination prepend. That path (`member_relations_vector` → `XGrpMemNew`) carries **profiles** only; with the gate removed (1.5), a privileged member's profile disseminates through it like any other member's, but only after the roster has established their key/role. Profile via prepend, key/role via roster — orthogonal, no double-prepend.
+
+## 1.7 Relay-side cache (the one new storage pattern)
+
+Relays already forward signed bytes verbatim (`encodeFwdElement` `Batch.hs:106`, `verifiedMsgParts` `Protocol.hs:1445`; `messages.msg_chat_binding` + `msg_signatures`; reconstructed in `toTask` `Delivery.hs:154`). What does **not** exist is "store the latest roster and re-emit to joiners" — `sendHistory` (`Internal.hs:1207`) reconstructs content and does *not* preserve signatures, so it is not a template.
+
+Add a small per-group cache holding the latest signed roster message bytes, plus the roster `version` as a **separate column** alongside them (so the relay compares versions without re-parsing the blob). On receiving `XGrpRoster` from an owner the relay: verifies the owner signature; **checks `version` strictly greater than the cached version** (lower → reject as rollback; equal → idempotent no-op); then updates its own member-role records, overwrites the cache + stored version, and (for a role-change-origin roster) creates a delivery task to all current members. On join, it forwards the cached bytes verbatim.
+
+The relay-side version check protects an **honest** relay's cache from being rolled back by a replayed signed roster — which in turn protects every joiner that relay serves. It does not constrain a **malicious** relay (it controls its own cache); that remains the documented new-joiner residual gap (1.3), bounded by the member-side check (1.3) and the link version anchor.
+
+## 1.8 Races and tests
+
+- **Promotion vs. action ordering.** A newly-promoted mod could act before its roster reaches a recipient ⇒ `RGEMsgBadSignature`. Covered for MVP by causal ordering (the roster is broadcast at promotion, before the mod learns of and acts on it), QCONT catch-up (item 7), and recipient tolerance (a rejected first action is re-sent; the next roster repairs trust). The fuller fix — the **roster-specific prepend** (prepend the cached signed roster ahead of a privileged member's forwarded action for recipients below the current version, reusing the item-7 delivered-version tracker, distinct from the `XGrpMemNew` profile prepend) — touches the hot per-recipient delivery loop that carries every forwarded message, so it is **deferred to a focused, separately-tested pass** rather than shipped untested.
+- **Multi-owner roster signed by an unknown owner** (owner added after the recipient fetched the link): recipient cannot verify ⇒ buffer/refetch link. Cannot occur for single-owner MVP; flag for v7.
+- **Roster vs. profile-update concurrency:** benign (different fields); verify the roster's relations-vector handling does not clobber the profile `MRIntroduced` semantics they share.
+
+Tests: relay-fabricated moderator key is rejected (forgery); promotion delivers a verifiable key; demotion via roster + `XGrpMemRole` reconciles; removed privileged member does not reappear for a new joiner; replayed older roster rejected by existing members; TOFU key-change rejected; batch `APIMembersRole` emits roster + `XGrpMemRole` correctly; self-healing after a dropped role event.
+
+## 1.9 Key anchors for Section 1
+
+`ChatMsgEvent` `Protocol.hs:422`; `requiresSignature` `Protocol.hs:1231`; `groupMsgSigning` `Internal.hs:1962`; `withVerifiedMsg` `Subscriber.hs:3461`; `xGrpMemNew` `Subscriber.hs:2957`; `xGrpMemIntro` `Subscriber.hs:3015`; `introduceInChannel` `Internal.hs:1165`; `getGroupModerators` `Store/Groups.hs:1190`; `memberInfo` `Internal.hs:1187`; `createLinkOwnerMember` `Store/Groups.hs:3072`; `GroupKeys` `Types.hs:462`; `member_relations_vector` machinery in `Types/MemberRelations.hs` (`MemberRelation`, `MRIntroduced`, `IDSubjectIntroduced`, `setNewRelations`); forwarding `Batch.hs:106` / `Protocol.hs:1445` / `Delivery.hs:154`. New columns go in a **new tail migration** (`M20260222_chat_relays` is the *pattern* for relay group columns but is not the tail — never edit an applied migration; `M20260525_member_removed_at` is the current tail).
+
+---
+
+# Section 2 — Joiner role on the signed profile
+
+Today the relay derives a joiner's role from `channelSubscriberRole` (`Controller.hs:161`, default `GRObserver` `Chat.hs:119`), a global config — so relays can disagree and the owner cannot set it per group. Move it onto the owner-signed profile.
+
+## 2.1 Types and helpers
+
+- Add `joinerRole :: Maybe GroupMemberRole` to `PublicGroupProfile` (`Types.hs:798`). No migration: JSON derives via `deriveJSON defaultJSON` with `omitNothingFields = True`, so `Nothing` is omitted on encode and a missing field decodes to `Nothing`.
+- Add a `groupType` accessor and `isChannel` on `GroupInfo`/`GroupProfile`, and a resolver `joinerRoleFor :: GroupInfo -> GroupMemberRole` = `joinerRole` if set, else type-keyed default (`GTChannel → GRObserver`, `GTGroup → GRMember`, `GTUnknown _ → GRObserver`). Reuse the existing `publicGroupEditor`/`memberRole'` (`Types.hs:499`/`506`); do **not** introduce a profile-side `memberRole'` (name collision).
+
+## 2.2 Replace the global config
+
+Switch every `channelSubscriberRole` reader to `joinerRoleFor gInfo` and delete the config: `Controller.hs:161`, `Chat.hs:119`, `Commands.hs:2053`, `Commands.hs:2546`, `Subscriber.hs:3248`, `Subscriber.hs:4019`. Verify no out-of-tree consumer reads it.
+
+## 2.3 Command, preferences, defensive refusal
+
+- `APINewPublicGroup` (`Controller.hs:526`, handler `Commands.hs:2495`) gains `groupType` (default `GTChannel`) and optional `joinerRole` (default `joinerRoleFor` of the type); both written onto the constructed profile (today hardcodes `groupType = GTChannel` at `Commands.hs:2538`).
+- Parameterize the channel-prefs parser by `GroupType`: Channel keeps its override (`support = OFF`); Public group and `GTUnknown` use secret-group defaults (member-to-moderator escalation is expected). Do not duplicate the parser — parameterize it.
+- `directMessages` stays ON by inheritance but is dormant in any relay-mediated group; hide its toggle when `useRelays` and refuse `xGrpDirectInv` defensively when `useRelays'` (`Subscriber.hs:3321`, currently ungated): emit `messageError`, create no contact.
+
+## 2.4 Compatibility
+
+Existing channels: no `joinerRole` ⇒ falls back to `GRObserver` for `GTChannel`. No data migration. Older relays without this change resolve the joiner role from their global config — warn the owner at create time if a selected relay's chat version is below the public-groups version (soft warning, not a block).
+
+---
+
+# Section 3 — Backend tests
+
+Public-group helpers paralleling the channel helpers, plus:
+
+1. Member posts; all members receive it (no "unknown member" lines). 2. Multi-author session: no "unknown member" anywhere. 3. Member edit/delete/react forwarded to all. 4. `xGrpDirectInv` refused under `useRelays` (no contact created); repeat for Channel. 5. Blocked member's messages not forwarded. 6. Multi-relay delivery with cross-relay dedup. 7. History on join. 8. `asGroup=true` from a non-owner rejected. 9. Receipts disabled above the member limit. 10. Older client refuses `groupType = "group"` (needs-newer-version). 11. Incognito member posting attributes the incognito profile. 12. `joinerRole` propagates and defaults correctly (Channel→observer, Public group→member; absent→type default). Plus the roster tests in 1.8.
+
+---
+
+# Section 4 — Clients (iOS, then Kotlin)
+
+## 4.1 Audit `useRelays` vs `isChannel` (structural commit, on its own)
+
+~70–75 sites per platform branch on `useRelays` as a proxy for "is a channel." Split per a mechanical rule and land as a pure structural commit (no behavior change in the same diff):
+
+- **Transport** (keep `useRelays`): link/relay management, owner-can't-leave-own-relay-group, relay-status indicator, incognito flag, typing-state gating, member-DM-affordance suppression.
+- **Governance** (switch to `isChannel`): titles, "subscribers" vs "members" framing, "Channel preferences" labels, channel-style vs group-style member display.
+
+## 4.2 Model and behavior
+
+- Model: add `group` arm to `GroupType` (with serializers); `joinerRole`, `groupType`, `isChannel` accessors. Authoritative role resolution stays in Haskell; clients use it for display.
+- **Narrow the existing refusal:** PR #7009 (merged to `stable`) added `GLPUpdateRequired` for `groupType /= GTChannel` (`Controller.hs:1051`, `Commands.hs` `unsupportedGroupType`). Change it to refuse only `GTUnknown _`; `GTGroup` proceeds to a public-group join.
+- Create flow: one view with a Channel / Public-group segmented control (default Channel) driving the title, link-step label, success screen, and two API params (`groupType`, `joinerRole` = observer for Channel, member for Public group — no role picker in MVP). Hide `directMessages` in create prefs when `useRelays`. Render the threat-model note below the title for Public groups (text in Section 5).
+- Suppress the member-tap "send direct message" affordance in any relay-mediated group.
+- Members view shows the relay-known roster; header "subscribers" (channel) vs "members" (public group). No filtered view in MVP.
+- Strings/icons: ~5–10 `_public_group` string keys mirroring channel forms; reuse `group_members_*` for "members" framing; a distinct Public-group icon (pending design). Kotlin-only: chat-list filter chips place Public groups in the "groups" bucket.
+
+Platforms ship independently (API defaults are backward compatible).
+
+---
+
+# Section 5 — Threat model, docs, release
+
+Fold into `channels-overview.md` (public groups inherit the entire channel threat model; deltas only):
+
+- **A relay can fabricate content as any member** (channels: only as owners). Content (`XMsgNew`/`Update`/`Del`/`React`) is unsigned by design for deniability (`requiresSignature` lists roster/admin events only); broader blast radius in public groups. Detectable via cross-relay consistency. Mitigation is the future opt-in content signing on the channel roadmap; the create-flow note states the trade-off ("a malicious relay could change or fabricate messages from any member — pick relays you trust, or use a secret group for peer-to-peer integrity").
+- **Roster rollback for new joiners** (1.3): documented bounded delta + future mitigations.
+- Unchanged: relay cannot impersonate an owner or substitute the profile (signed events, validated entity ID); `joinerRole` and the privileged roster are owner-signed, so the relay cannot unilaterally change a joiner's default role or fabricate a moderator.
+
+Document `XGrpRoster` (event, signing, versioning, TOFU, delivery) in `channels-protocol.md`. Bump the chat protocol version (the public-groups version that gates `GTGroup` and `joinerRole`). Release notes include the relay-fabrication line.
+
+---
+
+# Sequencing
+
+1. **Section 1 — privileged roster** (backend). The core; gates the rest of the value. Land the gate-removal/roster-check and the event together so no half-applied trust window exists.
+2. **Section 2 — joiner role on profile** (backend). Independent of Section 1.
+3. **Section 3 — backend tests** (alongside 1–2).
+4. **Section 4 — clients**: audit (structural) first, then iOS, then Kotlin.
+5. **Section 5 — docs/version/release** with the backend release.
+
+Backend (1–3) gates the clients. iOS and Kotlin are independent of each other.
+
+---
+
+# Out of scope (deferred)
+
+- **Member-to-member DMs in relay-mediated groups.** Prohibited here (client affordance suppressed, receive-path refusal, relay does not forward `XGrpDirectInv` — so no relay-visible DM graph). A future plan must re-derive the threat model: relay-forwarded DMs would expose (sender, target, time) metadata; relay-blind rendezvous via per-member queues is the privacy-preserving alternative.
+- **`memberAdmission` on relay-mediated join** (hardcoded `GAAccepted` bypasses review/captcha — generic relay-groups gap).
+- **Roster filter/pagination in the members view** for very large groups.
+- **Multi-owner** roster signing/verification and owner promotion via link `OwnerAuth` (v7); **opt-in content signing** (v7 roadmap); **full anti-rollback for new joiners** (link-version hard gate).
diff --git a/plans/2026-06-01-roster-members-multipart.md b/plans/2026-06-01-roster-members-multipart.md
new file mode 100644
index 0000000000..aca98c4698
--- /dev/null
+++ b/plans/2026-06-01-roster-members-multipart.md
@@ -0,0 +1,220 @@
+# Roster: regular members + larger rosters via inline file
+
+Date: 2026-06-01 (revised). Extends Section 1 of `2026-05-26-public-groups-via-relays-unified.md`.
+
+> Anchors below were re-verified against `f/public-groups-members-in-roster` **after** PR #7036 (`core: signed XMember in public group`, commit `0773ccd05`) merged in. Most line numbers shifted; the header-fits check uses `maxEncodedMsgLength = 15602` (now `Protocol.hs:905`). Confirm before editing.
+
+## Reconciliation with PR #7036 (merged into this branch)
+
+PR #7036 landed things this plan predates. Read this section first — it changes the relay flow the plan builds on.
+
+**Renames (the plan's old names no longer exist — grep will miss them):**
+
+| Was | Now | Location |
+|---|---|---|
+| `forwardCachedRoster` | `forwardGroupRoster` | `Internal.hs:1172` |
+| `setCachedGroupRoster` | `setGroupRoster` | `Store/Groups.hs:1415` |
+| `getCachedGroupRoster` | `getGroupRoster` | `Store/Groups.hs:1428` |
+| `setRelayLinkAccepted` | `setRelayKey` (no longer sets relay status) | `Store/Groups.hs:1543` |
+
+"Cached roster" is now "saved roster" throughout; the `roster_msg_*` columns and the `roster_blob` this plan adds are unchanged in intent.
+
+**Roster version baseline is now `Just 0`, not NULL, for relay groups.** `createNewGroup` initializes `roster_version = Just (VersionRoster 0)` for `useRelays` groups (`Store/Groups.hs:365, 427`), and an old channel materializes `0` the first time a relay connects (`Subscriber.hs:905-910`). Consequences: the first promotion bumps `0 -> 1` (not NULL -> 0); the owner and already-onboarded members/relays compare against a real `0`, **but a relay's own `roster_version` is still NULL the first time it receives v0** — applying v0 from NULL is exactly what lets it ack and become publishable (verified: today's `maybe False (newVer <=) (rosterVersion gInfo)` at `Subscriber.hs:3207` applies v0 only because the relay is at `Nothing`; `Just 0` would reject it and the relay would hang `RSInvited`). So the multipart version guards MUST be `Maybe`-comparisons that treat `Nothing` as below `0` (spelled out under *Header handler* and *Completion*); and the **empty roster (v0)** must round-trip through the header+blob path (a 2-byte blob: `Word16` count `0`, one chunk, `chunkSize >= fileSize` -> `RcvChunkFinal` on chunk 1). The empty/small blob is the *common* case for relay onboarding, not an edge case.
+
+**NEW relay roster-ack handshake (`XGrpRosterAck`) — this plan MUST integrate it.** PR #7036 added `XGrpRosterAck :: VersionRoster -> Maybe Text` (`Protocol.hs:499`; tag `x.grp.roster.ack`; NOT in `requiresSignature` — it rides the relay's authenticated connection). Flow:
+
+- On relay connect (`GCInviteeMember` + `isRelay`) the owner **always** sends the current roster via `sendGroupRosterToRelay`, and the relay stays `RSInvited` (**unpublishable**) until it acks (`Subscriber.hs:900-910`).
+- The relay applies the roster in `relayApplyRoster` and, **only while its own status is `RSAccepted`**, sends `XGrpRosterAck author newVer Nothing` (or an error string) — `Subscriber.hs:3210-3221`, `sendRosterAck` at `3276`.
+- The owner's `xGrpRosterAck` handler (`Subscriber.hs:3279-3297`) transitions the relay `RSInvited -> RSAccepted` (and publishes via `setGroupLinkDataAsync`) on a version-matching success ack, or `RSInvited -> RSRejected` on error.
+
+Impact on the multipart design (a REQUIRED change, not just a rename): under this plan the header only *starts* a transfer, so on a relay the **apply, `setGroupRoster`, the ack, AND the broadcast all move to blob completion**, not header receipt. The relay becoming publishable now **gates on the blob transfer completing**: header -> chunks -> verify digest -> `processRoster` + `setGroupRoster` -> (`relayOwnStatus == RSAccepted`) `sendRosterAck` -> broadcast. This is the desired fail-safe (an unpublishable relay can't serve a half-applied roster), but it puts owner->relay blob delivery on the relay-onboarding critical path, not just self-healing. The error branch MUST still ack-with-error (digest mismatch / parse failure -> `sendRosterAck author newVer (Just "...")`) so the owner marks the relay `RSRejected` instead of leaving it hung at `RSInvited`. The current `relayApplyRoster` to fork is `tryAllErrors (setRoster sm)`, where `setRoster` = `processRoster` + `setGroupRoster` (`Subscriber.hs:3205-3228`); the multipart version splits this across header (write `roster_pending_*`) and completion (run `setRoster` + ack + broadcast).
+
+## Goal
+
+Let owners promote channel subscribers to **regular members** who can post, and carry more named members than fit one message.
+
+The JSON roster already exists (event, signing, relay cache, TOFU apply, broadcast, join forward, QCONT). This plan **widens the roster set to include plain members and changes the delivery** to a binary blob over the inline file transfer; the apply logic (`processRoster`) is reused.
+
+The member list moves out of the `XGrpRoster` message into a binary blob sent over the existing inline file transfer. `XGrpRoster` becomes a small signed header (version + the blob's size and digest).
+
+## Roster set: the promoted set {member, mod, admin}
+
+Owners stay on the link, never in the roster. Two edits, then every gate follows.
+
+**1. Widen `isRosterRole`** (`Internal.hs:1237`) to `{GRMember, GRModerator, GRAdmin}`. Every call site wants the promoted set, so this single edit covers:
+
+- `validateGroupRoster` filter (`Internal.hs:1243`) — fixes the bug where member entries are dropped.
+- `buildGroupRoster` filter (`Internal.hs:1255`).
+- promotion gates / cap / trigger / counts (`Commands.hs:2737, 2739, 2746, 2762, 2763, 2768`); update the cap error text at `2740`.
+- owner-remove roster refresh (`Commands.hs:2888`, guarded by `anyPrivilegedRemoved` computed from `isRosterRole` at `2899`) — so removing a plain member, not just a mod/admin, refreshes the roster.
+- receive gates: `xGrpMemNew` (`Subscriber.hs:3011/3026/3045`) and `xGrpMemRole` owner-only (`3185`).
+- **join key-proof gate (NEW in PR #7036, `Subscriber.hs:1620`, `memberJoinRequestViaRelay`)**: a join claiming a `memberId` already roster-established as `isRosterRole` must prove possession of the pinned key (signature + `memberPubKey` match + `viaRelay == this relay's memberId`). Widening to members **extends this proof to promoted members** — a promoted member re-connecting through a relay must sign its `XMember` with the roster-pinned key. This is correct and desirable (it is the receive-side counterpart of the promote-time key invariant in *Known limitations*), and it composes with PR #7036's `acceptGroupJoinRequestAsync existingMem_` path that attaches the connection to the existing roster record. Confirm the promoted member signs its join `XMember` (it does — `encodeXMemberConnInfo`, `Internal.hs`).
+
+**2. Split the role query.** `getGroupRosterMembers` (`Store/Groups.hs:1215`) currently serves two now-diverging needs:
+
+- **Build / revert** wants the promoted set. Redefine `getGroupRosterMembers` to `member_role IN (GRMember, GRModerator, GRAdmin)` (current members). Callers: `bumpAndBroadcastRoster` (`Internal.hs:2175`), `sendGroupRosterToRelay` (`2188`), and the `processRoster` revert set `currentPriv` (`Subscriber.hs:3245`). Build and revert MUST be the same query, or a dropped member is never reverted.
+- **`introduceInChannel`** (`Internal.hs:1188`) wants only the moderation set (mod+admin). Widening it would announce every joiner to every member and introduce every member to every joiner (traffic + anonymity blowup). Reuse the existing `getGroupModerators` (`Store/Groups.hs:1204-1209`, returns mod+admin+owner) rather than adding a function: keep `getGroupOwners` for the owner-first intro, and take mod+admin as `getGroupModerators` minus owners. **Re-apply `filter memberCurrent`** — `getGroupModerators` does NOT filter current members (unlike the old `getGroupRosterMembers`), so without it a removed or left moderator would be introduced to joiners. Members are learned from the roster blob, not introductions.
+
+**Owner-only (confirmed decision).** Only the owner changes any roster role. The alternatives were considered and rejected for v1 — letting a mod/admin set member roles would need either the owner co-signing rosters from a mod/admin (owner round-trip + load) or a separate roster-signing key trusted from mod/admin (broader trust surface) — so owner-only keeps the single owner-key trust anchor.
+
+**Leave and owner-remove differ.** This plan **removes** the `xGrpLeave` roster-bump block (`Subscriber.hs:3439`): since `isRosterRole` is widened, it would otherwise fire `bumpAndBroadcastRoster` on every plain-member leave. So a member **leave** does NOT bump the roster — the leave is the membership axis (`XGrpLeave` neutralizes the member on the relay). An owner **remove** (`APIRemoveMembers`) DOES still bump via `bumpAndBroadcastRoster` (`Commands.hs:2888`, widened to cover plain members). `bumpAndBroadcastRoster` thus stays only for promotion (`APIMembersRole`) and owner-remove.
+
+## Wire: signed header + unsigned blob
+
+**Authoritative metadata is in the signed header.** `version`, blob `fileSize`, and `fileDigest` all live in the owner-signed `XGrpRoster`; the unsigned `BFileChunk`s carry no authoritative metadata. (This is why "total parts in the unsigned part", an earlier review question, is a non-issue here.)
+
+- **Header**: `XGrpRoster { version :: VersionRoster, fileInv :: InlineFileInvitation }`, JSON, signed, forwarded. `InlineFileInvitation { fileSize, fileDigest :: FD.FileDigest }` is a lean `FileInvitation` (no name/connReq/inline/descr; always inline). Tiny; fits `maxEncodedMsgLength` (15602, `Protocol.hs:905`).
+- **Blob**: the binary member list. `RosterMember { memberId, key, role, privileges :: Word16 }` — drop `name`, add `privileges` (reserved: always `0`, parsed and ignored in v1). ~60 B/entry. Members get a placeholder name from `nameFromMemberId`; real profiles arrive on first post.
+- **Serializer/parser**: a binary codec for the blob (a `Word16`-count-prefixed `[RosterMember]`); `RosterMember` becomes binary-only. Full code in *Blob format* below. Owner serializes → digest → chunks; receiver concatenates chunk bytes → verifies the digest → parses.
+- **Cap** `maxGroupRosterSize` → **256** (tunable). Enforce at promotion over the promoted set (`Commands.hs:2739`, via the widened predicate); the receive-side entry-count bound is the parser alone (`rosterBlobP`'s `n > maxGroupRosterSize`); reject a signed `fileSize > cap × max-entry-size` before creating a file. Roster files are exempt from the inline `offer/receiveChunks` ceiling (at 256 ≈ 15 KB the blob is about one `fileChunkSize` chunk; the multipart path handles two if role words push it over).
+
+**Type changes.**
+
+- `GroupRoster` (`Protocol.hs:372-376`): `{version, roster :: [RosterMember]}` → `{version, fileInv :: InlineFileInvitation}`. It stays JSON (the signed header), so `InlineFileInvitation` needs a JSON instance; update its stale doc comment ("Owner-signed snapshot of the privileged (moderator/admin) set").
+- `RosterMember` (`Protocol.hs:378`): drop `name`, add `privileges :: Word16`; remove `deriveJSON` (`Protocol.hs:812`) — binary-only now — and add the `Encoding` below. `buildGroupRoster`'s constructor (`Internal.hs:1255`, currently `name = memberShortenedName m`) drops the `name` field; the consumer side already maps to `nameFromMemberId`.
+- `validateGroupRoster` (`Internal.hs:1241-1242`): was `GroupRoster -> GroupRoster` over `.roster`; now `[RosterMember] -> [RosterMember]`, run on the parsed blob.
+
+### Blob format (serializer / parser)
+
+`RosterMember` is **binary-only** (carried in the blob, never in a JSON message) and gets the `Encoding` below. `MemberKey` (`Types.hs:972`, only `StrEncoding`) and `GroupMemberRole` (`Types/Shared.hs:33`, only `TextEncoding`) lack a binary `Encoding`: `MemberKey` delegates to the underlying `PublicKey` (`Crypto.hs:568`), and the role delegates to its canonical `TextEncoding` (the same `"member"/"moderator"/"admin"` form JSON and the DB use — single source of truth; `GRUnknown` round-trips).
+
+```haskell
+-- MemberKey gains a binary Encoding (it only had StrEncoding); delegate to the Ed25519 key.
+instance Encoding MemberKey where
+ smpEncode (MemberKey k) = smpEncode k
+ smpP = MemberKey <$> smpP
+
+-- General instance (belongs beside GroupMemberRole's TextEncoding in Types/Shared.hs, not here).
+instance Encoding GroupMemberRole where
+ smpEncode = smpEncode . textEncode
+ smpP = maybe (fail "bad GroupMemberRole") pure . textDecode =<< smpP
+
+-- Tuple encoding (Encoding (a,b,c,d), Encoding.hs:192), as GrpMsgForward / FwdSender do.
+instance Encoding RosterMember where
+ smpEncode RosterMember {memberId, key, role, privileges} = smpEncode (memberId, key, role, privileges)
+ smpP = RosterMember <$> smpP <*> smpP <*> smpP <*> smpP
+
+-- Blob = Word16 count (NOT smpEncodeList: its 1-byte count overflows at the 256 cap) followed
+-- by that many entries. This is the byte sequence the digest is computed over and verified
+-- against before parsing.
+encodeRosterBlob :: [RosterMember] -> ByteString
+encodeRosterBlob ms = smpEncode (fromIntegral (length ms) :: Word16) <> B.concat (map smpEncode ms)
+
+rosterBlobP :: Parser [RosterMember]
+rosterBlobP = do
+ n <- fromIntegral <$> smpP @Word16
+ when (n > maxGroupRosterSize) $ fail "roster: too many entries"
+ A.count n smpP
+```
+
+- **Owner**: `encodeRosterBlob` over the promoted set → `FileDigest` (SHA-512, as the file machinery computes it, `LC.sha512Hash`) → chunk; the digest goes in the signed `XGrpRoster` header.
+- **Receiver**: concatenate chunk bytes → verify the digest (S1, over plaintext) → `parseAll rosterBlobP` (consume all input; reject trailing bytes). Parsing runs only after the digest matches, so the bytes are owner-attested; the `n > maxGroupRosterSize` guard and `parseAll` are defensive against a buggy/garbled blob.
+- **Per-entry layout**: `memberId` (1-byte len + id) + `key` (1-byte len + Ed25519 pubkey) + role (1-byte len + role word, e.g. `member` = 7 B) + `privileges` (2 bytes) ≈ ~60 B/entry. The file-transferred blob has no tight size budget, so canonical text is fine.
+- `privileges` is reserved: serialized as `0`, parsed and ignored in v1.
+
+## Delivery: send → header → chunks → completion
+
+### Owner send
+
+`bumpAndBroadcastRoster` and `sendGroupRosterToRelay` build the blob (`buildGroupRoster` over the widened query), compute its `FileDigest`, send the `XGrpRoster` header, then send the blob as `BFileChunk`s against that message's `shared_msg_id`.
+
+`sendFileInline_` reads from a file, so add a send-from-bytes variant (shared with the relay re-serve). The owner's own version bump stays as today (in `bumpAndBroadcastRoster`, `Internal.hs:2176`) — the owner is the source of truth; "bump only at completion" is a receive-side rule.
+
+### Header handler (`xGrpRoster`, member and relay)
+
+The header no longer applies anything — it starts a transfer. It only writes `roster_pending_*`; it never writes `roster_version` or the live `roster_msg_*`.
+
+- **Short-circuit** unless `version > max(roster_version, roster_pending_version)` — strictly greater than both applied and pending — before creating a file. These are **`Maybe` comparisons: `Nothing` (un-materialized version) counts as below `0`** (mirror today's `maybe False (newVer <=) …`, `Subscriber.hs:3207`), so a relay's first receipt at NULL **applies** v0 while a re-receive at `Just 0` short-circuits — the v0 onboarding depends on this.
+ - Why both: the QCONT re-serve is unconditional, so the relay may re-forward a still-cached v5 while a member is mid-receiving v6 (applied 4). Compared only to applied, v5 > 4 would supersede v6, then the arriving v6 chunks fail the v5 digest → stuck.
+ - Why never bump here: a header-time bump makes the genuine blob complete as an equal-version no-op, leaving the receiver at `vN` with `v(N-1)` data.
+- **Create the rcv-file** with `cryptoArgs = Nothing` (see Security), `file_type = roster`, `chat_item_id` NULL, `shared_msg_id` = the header's id. Accept it via `startRcvInlineFT` (chat-item-free), not `acceptRcvInlineFT`, so chunk 1 isn't rejected on `RFSNew`.
+- **One in-flight per group is automatic**: the single `groups` row makes `roster_pending_*` single-valued, and there is one `(group_id, file_type = roster)` file. A duplicate header is idempotent. A version greater than both applied and pending supersedes: `UPDATE roster_pending_*` and delete the existing roster file (cleanup below), then create the new.
+
+### Chunks
+
+The header is enqueued before chunk 1 (per-connection FIFO).
+
+**Reset-on-chunk-1** (decision 4): if chunk 1 arrives with partial chunks, discard and restart so relay restart / re-subscribe / QCONT can re-drive from the start. Discarding MUST (GAP 3):
+
+- delete the `rcv_file_chunks` rows,
+- truncate/remove the on-disk file, and
+- evict its handle from the `rcvFiles` map (`closeFileHandle`).
+
+`appendFileChunk` opens in AppendMode and caches the handle (`Internal.hs:1781`, handle at `1794`), so clearing only the rows would append after the stale bytes and corrupt the blob (digest fails — the stuck state decision 4 avoids).
+
+**Orphaned chunk**: a roster `BFileChunk` matching no in-flight `(group_id, shared_msg_id, file_type = roster)` file is **ACKed and ignored**, never errored (the version is already applied or superseded). This is how an up-to-date member tolerates the unconditional re-serve: the re-served header short-circuits (no file), then its chunks arrive with no transfer in flight. Distinct from reset-on-chunk-1, which fires only when partial chunks exist.
+
+### Completion (on `RcvChunkFinal`)
+
+1. Verify the assembled file's digest against `roster_pending_digest`. On mismatch, discard (delete the file, clear `roster_pending_*`); do not apply or bump.
+2. **Version guard**: apply only if `roster_pending_version > roster_version` (same `Maybe` semantics — a `Nothing` applied version counts as below `0`, so a first v0 completion from NULL applies). A stale/out-of-order completion is rejected, not applied as a downgrade.
+3. Parse → `validateGroupRoster` → `processRoster` (TOFU keys, role updates, revert absent promoted members, role-change items; pass `nameFromMemberId` where it used the entry name).
+
+In **one transaction**: `processRoster` → set `roster_version = roster_pending_version` → set `roster_blob` → clear `roster_pending_*` → delete the file. A **relay** also promotes the pending signed-header columns into the live `roster_msg_*` (this is what `setGroupRoster` writes today at header time — it moves here) and applies to its own records, then **sends the roster ack and broadcasts** (below). So a joiner never sees a live header at `vN` paired with a blob at `vN-1`.
+
+**Relay ack at completion (PR #7036 integration).** The relay's `XGrpRosterAck` (previously sent in `relayApplyRoster` at header receipt) moves to completion, gated exactly as today on `relayOwnStatus gInfo == Just RSAccepted`: on a successful completion send `sendRosterAck author roster_pending_version Nothing`; on digest-mismatch or parse failure send `sendRosterAck author roster_pending_version (Just "...")` so the owner marks the relay `RSRejected` rather than leaving it `RSInvited` forever. A relay therefore becomes publishable only after the full blob arrives and applies — the desired fail-safe, but it makes owner→relay blob delivery part of the relay-onboarding path, so it MUST be reliably driven (see *Owner send* and *Relay re-serve*; for a freshly-connecting relay the owner drives it via `sendGroupRosterToRelay`, including the empty v0 blob). The `relayOwnStatus == Just RSAccepted` gate is ported unchanged but now evaluated at completion rather than header receipt — confirm `relayOwnStatus` cannot change across the header→completion window (it shouldn't: a relay can't reach `RSActive` before acking, since the ack is what publishes it).
+
+The version guard plus the per-version `shared_msg_id` keying are what make the design correct; the short-circuit and one-in-flight-per-group are optimizations.
+
+### Relay re-serve (broadcast / join / QCONT)
+
+Per recipient, forward the signed header (as `forwardGroupRoster` does today, `Internal.hs:1172`) AND re-send the blob as `BFileChunk`s from `groups.roster_blob` (the send-from-bytes variant). An incoming `BFileChunk` returns no delivery task (`Subscriber.hs:1089`), so the blob send is driven here.
+
+**No per-member version gate in v1 (GAP 2).** QCONT/SENT re-forwards the saved roster unconditionally today (`Subscriber.hs:1143`, `1237`), and no per-member delivered-version tracker exists in the tree — this plan adds none. So a re-serve re-sends the whole blob on every drain; at cap 256 that is ~15 KB — one (occasionally two) `BFileChunk`s per drain — acceptable.
+
+It is safe because: an up-to-date member short-circuits the header and ACK-ignores the orphaned chunks; a stale (≤ pending) re-forward mid-transfer is a no-op via the short-circuit; and the completion version guard rejects any stale completion.
+
+If the cap is later raised so the blob spans many chunks, add a per-member `delivered_roster_version` column (read on QCONT/join/broadcast, written on confirmed delivery) and re-serve only when behind — future work.
+
+### Supersede / cancel cleanup
+
+Cleanup spans ALL of these — miss none:
+
+- `files`, `rcv_files`, `rcv_file_chunks`,
+- the on-disk file and its `rcvFiles` handle (`closeFileHandle`),
+- the `roster_pending_*` columns on `groups` (set NULL).
+
+## File-machinery changes (only these)
+
+- **Lookup**: add `files.shared_msg_id`; resolve roster chunks by `(group_id, shared_msg_id, file_type = roster)`. Leave `getGroupFileIdBySharedMsgId` (`Store/Files.hs:310`, chat-item JOIN) for normal files; branch on `file_type` / `chat_item_id IS NULL`.
+- **Fork the three receive sites that call `getChatItemByFileId`** (they throw with no chat item):
+ - `startReceivingFile` (`Internal.hs:827`, reached on chunk 1) — skip the chat item + `CEvtRcvFileStart`.
+ - `receiveFileChunk` `RcvChunkFinal` (`Subscriber.hs:1329`) — replace with the completion path above.
+ - `FileChunkCancel` (`Subscriber.hs:1313`) — delete file + drop in-flight state, no chat item.
+- **Cleanup keyed on `group_id`** (not chat items): `getGroupFileInfo` INNER-JOINs `chat_items`, so group delete (`Commands.hs:1270`) and clear (`1305`) skip roster files; the DB row cascades on group delete but the on-disk file leaks. Add a roster-file cleanup for delete/clear, cancel, and supersede.
+
+## Storage / migration
+
+In-flight state lives on `groups` (mirroring the live saved roster) and `files` (located by `shared_msg_id`) — no join table. These columns go into the in-progress **`M20260602_group_roster`** migration (already part of this work, not yet merged — so it's editable, not an applied migration), SQLite + Postgres; tests regenerate the schema files.
+
+| `groups` column(s) | Holds | Lifecycle |
+|---|---|---|
+| `roster_version` *(kept)* | applied version | bumped at completion |
+| `roster_msg_*` *(kept)* | live signed header (was full JSON) | relay forwards verbatim; promoted from pending at completion |
+| `roster_blob` *(new)* | durable completed blob | written at completion; relay re-serves it |
+| `roster_pending_version`, `roster_pending_digest` *(new)* | in-flight version + digest | set on header receipt; cleared at completion |
+| `roster_pending_msg_*` *(new, relay-only)* | in-flight signed header | set on header receipt; promoted to live at completion (NULL on members) |
+
+The kept `roster_msg_*` columns stay the relay's verbatim-forward source and trust anchor: `forwardGroupRoster` re-forwards them so the joiner verifies the owner signature, and the digest inside authenticates the unsigned blob.
+
+`files` adds `shared_msg_id` and `file_type`. The in-flight transfer is the `files` / `rcv_files` / `rcv_file_chunks` rows with `(group_id, file_type = roster)`.
+
+## Security
+
+- **Owner-signed header**: assert `memberRole' author == GROwner` (`Subscriber.hs:3198`); keep `XGrpRoster_` in `requiresSignature`.
+- **Integrity is entirely the digest** (S1): verify the assembled **plaintext** blob against the owner-signed `fileDigest` at completion. Hence `cryptoArgs = Nothing` — a set cryptoArgs makes `appendFileChunk` re-encrypt the file in place (`Internal.hs:1801`), so the on-disk bytes would be ciphertext and the check would fail. A corrupted chunk fails the digest and the roster is rejected.
+- **TOFU** key pinning per `memberId` unchanged (different key for a known id → keep the trusted key).
+- **Rollback (S2)**: the signature binds `publicGroupId + version` and the digest binds the blob to that header, so cross-group/version substitution stays blocked. But the blob now carries plain members, so a same-group replay of an old `(header, blob)` to a **new joiner** can re-introduce a removed poster or mask a demotion (existing members are protected by the version check). Update `channels-overview.md`.
+
+## Known limitations / out of scope
+
+- A malicious relay can withhold/corrupt chunks → the member stays on its last-applied roster (it can drop any message anyway); new-joiner rollback now covers plain members.
+- A just-promoted member's first posts may show "unknown member" until the file arrives — self-healing.
+- A member who **leaves** lingers in the roster blob until the next bump (this plan drops the leave-triggered refresh). Harmless: they have no relay connection and cannot post, so a new joiner sees only a ghost row; the owner's explicit remove (`APIRemoveMembers`) drops them.
+- Out of scope: granting/enforcing `privileges`; member content signing; joiner-role-on-profile; clients. Do not couple the roster set to the joiner-role mechanism (decision 2) — it is the absolute `{member, mod, admin}`.
+
+## Tests (`tests/ChatTests/Groups.hs`)
+
+The roster tests now live under the `describe "promoted members roster"` block (PR #7036 moved them and added `testChannelAddRelayWithRoster`, which onboards a 2nd relay through the roster-ack handshake). Update those to header+file delivery — `testChannelAddRelayWithRoster` in particular now exercises the v0/empty-roster blob transfer feeding the relay ack, so it must drive the header+chunk(s) to completion before the relay acks.
+
+Then add: digest-mismatch blob rejected (no apply, no version bump) **and the relay acks-with-error → owner marks it `RSRejected`** (PR #7036 path); a relay does **not** ack / become publishable until the blob completes (ack moved to completion); member promotion enters the broadcast roster and can post; reset-on-chunk-1 recovery; superseding version cleans up the in-flight older file; version not bumped on header receipt or on a failed blob; `introduceInChannel` still mod+admin only (no member introductions); on-disk roster file cleaned on group delete/clear mid-transfer; non-owner promotion refused; a promoted member re-connecting through a relay is accepted only with a valid signed `XMember` over the roster-pinned key (the widened `memberJoinRequestViaRelay` gate). Existing mod/admin tests must still pass.
diff --git a/plans/2026-06-04-channel-message-signing.md b/plans/2026-06-04-channel-message-signing.md
new file mode 100644
index 0000000000..be7cc53a92
--- /dev/null
+++ b/plans/2026-06-04-channel-message-signing.md
@@ -0,0 +1,316 @@
+# Plan: optional signing of channel content messages (`XMsgNew` / `XMsgUpdate`)
+
+Anchored on branch `f/msg-signing` (master merged in); all symbols re-verified 2026-06-25 — see **§Verification status** at the end for the current line map and the few mislabeled anchors. Re-confirm by symbol before editing; line numbers are advisory. The public-groups roster already provides everything this builds on: `GroupKeys {publicGroupId, memberPrivKey}` (`Types.hs:465`), `verifyGroupSig` (`Subscriber.hs:116`), per-member public-key distribution via the signed roster, and optional signing of group-state events (`requiresSignature`, `Protocol.hs:1334`). Content messages are *not* signed today.
+
+**PR 1** (this plan): a member can optionally sign their own channel posts and edits so recipients holding the signed roster can verify authorship + integrity; and — once an item is held signed — its edits and deletes are **enforced** to be signed (an unsigned mutation of a signed item is rejected at receive), closing the edit/delete-downgrade spoof at the source. The remaining hard part, history signature preservation (so catch-up members also hold posts signed), is **PR 2** (at the end).
+
+## Goal / user problem
+
+In relay channels, content (`XMsgNew`) is forwarded by relays and is not signed — only group-state events are. A relay can therefore forge or alter content attributed to a member. This feature lets a member optionally attach their member signature; recipients with the roster verify it.
+
+## Decisions
+
+- UI: **per-send long-press override only** — no device-stored default preference. Signing is opt-in for each send.
+- Default off, with an in-UI explanation of the tradeoff (a signature is transferable, non-repudiable proof of authorship).
+- Recipient indicator in scope (iOS + Kotlin), **chat view only** — not the conversation list. Glyph: `checkmark.seal`.
+- Scope: `XMsgNew` + `XMsgUpdate` + `XMsgDel`, **including as-channel posts** (see §5 — signing an as-channel post is verifiable and de-anonymizing, a deliberate team-accepted tradeoff). Edits sign iff the original was signed; deletes sign per-item (self-delete iff the target was signed; moderation/admin delete always-signs — §7). Mutations of a held-signed item are enforced to be signed (§7). Reactions stay unsigned.
+
+## Threat model
+
+Actors: the sending member, recipients, and untrusted **chat relays** that forward content + roster.
+
+- **Forgery of member content** — closed for signed messages: the relay lacks the Ed25519 key, and the signature binds `(publicGroupId, memberId, body)`, so no forgery, cross-bind, or alteration.
+- **Downgrade / stripping** (residual, narrowed) — optional signing lets a relay strip the signature from an *original* post and deliver it unsigned (the recipient never holds it signed, so nothing is enforced). Absence of a badge is *not* proof of forgery; only the presence of a verified badge is a guarantee. Once a recipient holds an item signed, its edits/deletes are enforced (next bullet), so the residual is now only the original-delivery case. A future "required signing" group setting would close even that (out of scope).
+- **Signed-mutation enforcement** (fail-closed) — an `XMsgUpdate`/`XMsgDel` targeting an item the recipient holds signed (`msgSigned = Just _`) MUST itself carry a verifying signature; an unsigned mutation is rejected (drop + `RGEMsgBadSignature`). Closes the edit/delete-downgrade spoof (a relay forging an unsigned edit/delete to overwrite or censor a signed post) at the source. The legitimate sender produces the required signature: edits sign iff the original was signed; self-deletes iff the target was signed; moderation deletes always sign (§7). Coverage is for items the recipient already holds signed — catch-up members holding the post unsigned are outside it until PR 2 history preservation.
+- **As-channel posts: anonymity for unsigned, accepted de-anonymization for signed.** An owner can "publish as the channel"; Design Objective 6 (`docs/protocol/channels-overview.md:214`) hides *which* owner authored a post from subscribers, and owners are "cryptographically indistinguishable to subscribers" (`:159`). This anonymity holds for **unsigned** as-channel posts: they forward via `FwdChannel` (no `memberId`), and a relay revealing the owner is only a deniable, detectable leak (`:237`). **Signing** an as-channel post is opt-in and deliberately gives it up: to be verifiable it forwards via `FwdMember` (§5), so every subscriber's device receives, verifies, and holds non-repudiable proof of the authoring owner. The owner is trading anonymity + deniability (`:198`, `:221`, `:103`) for verifiability on that post; the UI must say so. Verifiable-*and*-anonymous (ring signature / channel-level key) is out of scope.
+- **Non-repudiation** (tradeoff, by design) — a verified signature is transferable proof of authorship; hence opt-in/off.
+- **What "verified" proves** — the signed input is `encodeChatBinding CBGroup (publicGroupId, memberId) <> msgBody`, and `msgBody` embeds `sharedMsgId`, `MsgScope`, `asGroup`, content. It proves authorship + integrity + group/member/scope/message binding, and nothing else — not `fwdBrokerTs` (relay-controlled), ordering, or completeness. Surface in help.
+- **Bad signature is fail-closed** — a signature that fails to verify drops the message and creates an `RGEMsgBadSignature` item (`Subscriber.hs:3828`). Member keys do **not** rotate (communicated once on join, no rotation planned), so a have-the-key-but-mismatch can only mean forgery, tampering, or corruption — a genuine signal, and dropping is correct. New consequence for content (higher-volume, user-visible): such a message is **dropped**, not shown unsigned, exactly as state events already behave. The lagging-roster case is *not* a drop — if the recipient's roster lacks the author's key, that is the `MSSSignedNoKey` path (accepted, shown without badge), not the mismatch path. So there is no honest false-positive for the drop. Needs an edge-case test and a help note.
+- **As-channel spoofing** — because signed as-channel posts arrive as `FwdMember`, the recipient MUST verify the (verified) author is an owner before rendering as-channel (§5); otherwise a non-owner's signed `asGroup=True` post would display as "from the channel".
+- **Replay** — the binding covers `sharedMsgId` + `MsgScope`; cross-scope/group replay is blocked, same-message replay is a dedup duplicate.
+
+## What already exists (reused unchanged)
+
+- **Send / sign**: `groupMsgSigning` (`Internal.hs:2110`) → `createSndMessages` threads `Maybe MsgSigning` → `createNewSndMessage` Ed25519-signs `encodeChatBinding CBGroup (publicGroupId, memberId) <> msgBody`, storing `signedMsg_` in `SndMessage` (`Messages.hs:1156`).
+- **Wire**: `batchMessages` prepends the signature via `encodeBatchElement` (`Batch.hs:45,69`); relay groups always batch.
+- **Forward**: live delivery preserves the original signed bytes by reconstructing `VMSigned` from the stored `msg_chat_binding`/`msg_signatures` (`Store/Delivery.hs:155-165`); `fwdSender` is derived from the stored `showGroupAsSender` (`:158`).
+- **Receive / verify**: `withVerifiedMsg` (`Subscriber.hs:3819`) wraps member-authored messages (non-forwarded path `:1037`, forwarded `FwdMember` path `:3780`). `XMsgNew_`/`XMsgUpdate_`/`XMsgDel_` are not in `requiresSignature` ⇒ `signatureOptional` (`:3848`): signed ⇒ `MSSVerified` (key present) / `MSSSignedNoKey` (no roster key), unsigned ⇒ accepted (§7 adds the held-signed enforcement on top). `FwdMember` verifies against the author's key (`verifyGroupSig`, `:3833`); `FwdChannel` is delivered as `VMUnsigned` (`:3783`). No protocol-version bump.
+- **Persistence**: own item — `createNewSndChatItem` sets `MSSVerified <$ signedMsg_` (`Store/Messages.hs:548`); received item — `RcvMessage.msgSigned` (`Messages.hs:1174`) is stored by `createNewRcvChatItem` (`Store/Messages.hs:563`); `CIMeta.msgSigned` (`Messages.hs:520`).
+- **CLI**: `sigStatusStr` (`View.hs:389`) renders "(signed)" / "(signed, no key to verify)".
+
+Missing: (1) the decision to sign content; (2) per-send plumbing from the API; (3) as-channel forward/display/guard (§5); (4) edit reuse; (5) the badge fix (§7); (6) the apps.
+
+## Core changes (Haskell)
+
+### 1. `signableContent` predicate
+
+Next to `requiresSignature` (`Protocol.hs:1334`):
+
+```haskell
+-- | Content events a member may sign (XMsgNew opt-in; XMsgUpdate/XMsgDel when the target was signed).
+signableContent :: CMEventTag e -> Bool
+signableContent = \case
+ XMsgNew_ -> True
+ XMsgUpdate_ -> True
+ XMsgDel_ -> True
+ _ -> False
+```
+
+### 2. Signing decision takes the opt-in flag
+
+`groupMsgSigning` (`Internal.hs:2110`) gains a leading `Bool` — it stays blind to `showGroupAsSender` (as-channel posts sign with the owner's `CBGroup` binding like any member post):
+
+```haskell
+groupMsgSigning :: Bool -> GroupInfo -> ChatMsgEvent e -> Maybe MsgSigning
+groupMsgSigning sign gInfo@GroupInfo {membership = GroupMember {memberId}, groupKeys = Just GroupKeys {publicGroupId, memberPrivKey}} evt
+ | useRelays' gInfo && shouldSign =
+ Just $ MsgSigning CBGroup (smpEncode (publicGroupId, memberId)) KRMember memberPrivKey
+ where
+ tag = toCMEventTag evt
+ shouldSign = requiresSignature tag || (sign && signableContent tag)
+groupMsgSigning _ _ _ = Nothing
+```
+
+Three call sites — all but the content/edit chain pass `False`: `sendGroupMemberMessages` (`Internal.hs:2119`, hardcode `False`), `sendGroupMessages_` (`:2364`, passes its threaded flag), and the direct `XGrpLeave` send (`Commands.hs:3019`, `False`).
+
+### 3. Thread `sign :: Bool` through the send functions
+
+Add the flag to `sendGroupMessages` (`Internal.hs:2329`), `sendGroupMessages_` (`:2362`), `sendGroupMessage` (`:2255`), and the content wrappers `sendGroupContentMessages` / `sendGroupContentMessages_` (`Commands.hs:4430` / `:4439`). Keep `sendGroupMessage'` (`Internal.hs:2261`) and `sendGroupMemberMessages` (`:2116`) unchanged by hardcoding `False`.
+
+Behavior-preserving (every existing caller passes `False`) ⇒ its own commit. The only two variable-flag sites are content send (`Commands.hs:4469`) and edit (`:751`). Other callers pass `False`: `sendGroupMessages` — `Commands.hs:812,819,2821,2958`; `sendGroupMessages_` — `Commands.hs:2869,3912`; `sendGroupMessage` — `Commands.hs:908,2721,3327,3875,3878,3882`.
+
+`sendGroupContentMessages` has three callers, all reached via §4 except the first: the content-send handler (`Commands.hs:667`, real flag), `APIReportMessage` (`:698`, `False`), and `APIForwardChatItems` (`:994`, `False`).
+
+`Bool`-choice note: `sign` joins `showGroupAsSender :: ShowGroupAsSender (= Bool)` and `live :: Bool` in `sendGroupContentMessages`/`_`. Place `sign` away from the other two in each signature (e.g. after `itemTTL`) to reduce silent transposition.
+
+### 4. API: per-send `sign` flag
+
+Add a field to `APISendMessages` (`Controller.hs:382`):
+
+```haskell
+| APISendMessages {sendRef :: SendRef, liveMessage :: Bool, ttl :: Maybe Int, signMessages :: Bool, composedMessages :: NonEmpty ComposedMessage}
+```
+
+Parser (`Commands.hs:5094`), defaulting off so old command strings still parse:
+
+```haskell
+"/_send " *> (APISendMessages <$> sendRefP <*> liveMessageP <*> sendMessageTTLP <*> signMessagesP <*> (" json " *> jsonP <|> " text " *> composedMessagesTextP))
+-- signMessagesP = " sign=" *> onOffP <|> pure False (after sendMessageTTLP)
+```
+
+The nine internal positional constructors of `APISendMessages` must gain the field (`False`): `Commands.hs:2394,2403,2423,2443,2451,2496,3238,3279,3288`. Compiler-caught, part of the behavior-preserving commit.
+
+The handler (`Commands.hs:654-667`) flows `signMessages` to `sendGroupContentMessages` for group sends and ignores it for direct sends. `APIReportMessage` (`:693-698`) passes `False`.
+
+### 5. As-channel signing: forward with member id, display from `asGroup`, enforce owner
+
+An owner may sign an as-channel post (no gate on `showGroupAsSender`). Three pieces make it verifiable while displaying as the channel:
+
+- **Forward (`Store/Delivery.hs:158`)**: route signed as-channel posts via `FwdMember` so subscribers can verify; keep unsigned as-channel anonymous via `FwdChannel`:
+ ```haskell
+ fwdSender = if showGroupAsSender && isNothing chatBinding_ then FwdChannel else FwdMember senderMemberId senderMemberName
+ ```
+ (`chatBinding_`/`sigs_` are already in scope here for `verifiedMsg`; `isNothing chatBinding_` ⇔ unsigned. Non-as-channel posts already use `FwdMember`, unchanged.)
+- **Display**: the recipient already derives "as channel" from the signed `asGroup` flag, independent of `fwdSender` — `newGroupContentMessage` `sentAsGroup = asGroup_ == Just True` (`Subscriber.hs:2177`), `groupMessageUpdate` `showGroupAsSender = fromMaybe (isNothing m_) asGroup_` (`:2235`). So a `FwdMember` + `asGroup=True` post verifies against the owner and renders as the channel with the verified badge.
+- **Owner guard (security, MUST)**: the forwarded `XMsgNew` path (`xGrpMsgForward` `Subscriber.hs:3771` → `FwdMember` branch `:3775` → `withVerifiedMsg` `:3784` → `newGroupContentMessage` `:3795`) MUST reject as-channel display unless the verified author is an owner — parity with `groupMessageUpdate`'s owner guards (`:2236` send-time, `:2282` store-time) and the direct send path's `checkSendAsGroup` (`Subscriber.hs:1057`, `asGroup == Just True && memberRole' m'' < GROwner ⇒ messageError`); reuse the `validSender … CIChannelRcv ⇒ GROwner` pattern (`:2135`). Without it a non-owner's signed `asGroup=True` post renders as "from the channel". The guard is reliable for *legitimate* owner posts: `GROwner` identity is established from root-key-verifiable link data at connect time (`createLinkOwnerMember`, `Store/Groups.hs:3381`), and `isRosterRole` (`Internal.hs:1257`) excludes `GROwner` — so owner identity is never carried by the roster or `XGrpMemRole` and is therefore independent of the known role-propagation issue. Single owner today.
+- **Invariant**: `FwdChannel` never carries a signature (signed posts always route via `FwdMember`). Assert this in `encodeFwdElement` (`Batch.hs:108`) as a regression guard.
+
+`sendGroupContentMessages_` passes the API `sign` straight through (no `&& not showGroupAsSender` gate). The owner's own as-channel item is marked signed/verified like any signed send.
+
+### 6. Edit reuse (`XMsgUpdate`)
+
+Group edit, `Commands.hs:739-757`. The own sent item is loaded with `CIMeta` (`:739`); add `msgSigned` to the pattern and reuse it:
+
+```haskell
+let reuseSign = isJust msgSigned
+SndMessage {msgId, signedMsg_} <- sendGroupMessage user gInfo scope recipients reuseSign event
+```
+
+For own sent items, `msgSigned` is `Just MSSVerified` iff signed (`createNewSndChatItem`, `Store/Messages.hs:548`), so `isJust` is the right test. An edit is signed exactly when the original was — now **mandatory**, not optional: recipients enforce it (§7). The author's own item is authoritative, so the author always emits a signature exactly when recipients require one (no divergence). Direct/local edits need no change.
+
+### 7. Enforcement: a held-signed item's mutations must be signed (security)
+
+**Replaces the earlier "badge refresh" approach.** Principle: if a recipient holds an item as signed (`msgSigned = Just _`), any subsequent `XMsgUpdate` or `XMsgDel` targeting it MUST itself carry a verifying signature; an unsigned mutation of a signed item is **rejected** (drop, reusing `RGEMsgBadSignature`), not applied. This closes the edit/delete-downgrade spoof at the source (fail-closed) instead of applying attacker content and relabelling the badge.
+
+`updateGroupChatItem` / `updateGroupChatItem_` (`Store/Messages.hs:2749`/`:2758`) and their five callers are left **unchanged** — no `Maybe MsgSigStatus` param, no `msg_signed` in the `UPDATE`, no override of `ci'`. A legitimate enforced-signed edit keeps the original `MSSVerified`, so the badge stays correct without a refresh. (The one thing a refresh would have added — reflecting a rare `MSSSignedNoKey → MSSVerified` transition after a lagging roster catches up — is deliberately dropped.)
+
+**Receive check (both paths; the data is already in scope):**
+
+- **Update** — `groupMessageUpdate` (`Subscriber.hs:2225`): it already loads the target item (`:2277`) and has the incoming `RcvMessage` (`:2226`). Before applying the update, if the target's `meta.msgSigned` is `Just _` and the incoming `rcvMsg.msgSigned` is `Nothing`, reject (`messageError` → drop → `RGEMsgBadSignature`).
+- **Delete** — `groupMessageDelete` (`Subscriber.hs:2307`): the target `CChatItem` from `findItem` (`:2357`) carries `meta.msgSigned`; add `msgSigned` to the `RcvMessage` pattern (`:2356`) to get the incoming verdict. Same check. **One site covers self-delete, moderation, and forwarded delivery** (all route through `groupMessageDelete`). It composes with — does not touch — the existing `checkRole` WHO-gate (`:2382`): a moderation delete verifies against the *moderator* (its sender) via `withVerifiedMsg`, and `checkRole` independently enforces authority.
+
+"Signed" for the requirement means `MSSVerified` **or** `MSSSignedNoKey` (the sender signed); only `Nothing` (unsigned) is rejected. Since keys do not rotate, an item held `MSSVerified` verifies its mutations too, so this never spuriously rejects a legitimate live-held mutation.
+
+**Send side — produce the required signature so legitimate mutations are accepted:**
+
+- **Edits** (`XMsgUpdate`): §6 already signs the edit iff the original was signed (`reuseSign = isJust msgSigned`); under enforcement this is mandatory. The author's own item is authoritative, so the author emits a signature exactly when recipients require one — no divergence.
+- **Deletes** (`XMsgDel`) — per-item, because deletes batch a heterogeneous set of targets (`Commands.hs:811/818/3909`) and signing is currently keyed off event *type*, not instance. Compute the signer per delete at the send sites (the target `items` and their `msgSigned` are already in scope) and thread it in. **Do not** add `XMsgDel_` to `requiresSignature` (over-signs, ignores the per-item condition). Generalize the batch send to carry a per-event `Maybe MsgSigning` rather than recomputing one `groupMsgSigning` per batch — parameterize the existing body, do **not** duplicate it; keep a uniform-sign wrapper so non-delete callers are unchanged (this generalization lands in commit 1, behavior-preserving). Two cases:
+ - **Self-delete** (`memberId = Nothing`, `Commands.hs:811/818`): sign iff the deleter's own copy of the target was signed. The self-deleter's view is authoritative, so signed-holders and catch-up-unsigned-holders both accept — no divergence; and it preserves the deniability choice (an unsigned, deniable post's self-delete stays unsigned/deniable).
+ - **Moderation/admin delete** (`memberId = Just`, `Commands.hs:3909`): **always sign** in relay channels. A moderator who holds the target unsigned (joined late, caught up via unsigned history) would otherwise emit an unsigned delete that members holding the post signed would reject — silently failing moderation. Moderation deletes already carry the target `memberId` (attributable), so always-signing costs no deniability and removes the divergence.
+
+`signableContent` (§1) includes `XMsgDel_` so `groupMsgSigning sign …` produces a signer when the per-item/per-action decision is to sign.
+
+### 8. Paths deliberately left unsigned
+
+- Reactions (`XMsgReact`, `Commands.hs:908`): pass `False` — never signed (a reaction does not mutate the post's content/integrity and is not enforced).
+- Auto-reply welcome content via `sendGroupMessage'` ⇒ `False`.
+- Deletes are signed conditionally and enforced (§7) — no longer left unsigned.
+
+## App changes (iOS + Kotlin)
+
+Locate by symbol — app line numbers drift independently.
+
+- **A. Decode the status.** JSON tags come from `enumJSON (dropPrefix "MSS")`: `MSSVerified → "verified"`, `MSSSignedNoKey → "signedNoKey"` — not the DB strings "verified"/"no_key". Add an optional `msgSigned: MsgSigStatus?` to `CIMeta` on both platforms (iOS `ChatTypes.swift`; Kotlin `ChatModel.kt`), decoding `verified`/`signedNoKey`. Optional ⇒ old core JSON decodes safely.
+- **B. Composer long-press option + thread `sign` to the API.** No device preference — the long-press is the only entry. Add `sign: Bool` to the send closure (default off) and a long-press item next to "Disappearing message" ("Sign message" / "Send without signing", iOS `SendMessageView.swift`; Kotlin `SendMsgView.kt`). Show it for any relay channel, gated on the app's existing relay-channel indicator (`useRelays'` — the same signal that drives the as-channel composer). No key-derived flag is needed: every sendable member holds a signing key (the only keyless state, prepared/`GSMemUnknown`, is non-current and cannot send, so the composer is not available there). Confirm the app's `GroupInfo` exposes a member-agnostic relay-channel boolean (the as-channel toggle is owner-scoped; signing is offered to all members) — if the only existing signal is owner-scoped, add a plain non-secret relay-channel boolean, not a `memberPrivKey`-derived one. It is shown for as-channel sends too, with an explicit note that signing an as-channel post reveals you as the author (§5 tradeoff). Append `sign=on|off` in `apiSendMessages` on both platforms.
+- **C. Recipient indicator.** In the message meta row (`CIMetaView`, chat view only), show `checkmark.seal` when `meta.msgSigned == verified`, in the trust cluster next to `lock` and before the timestamp. iOS: append `statusIconText("checkmark.seal", color)` in `ciMetaText`. Kotlin: add an `Icon` branch in `CIMetaText` **and** the matching `iconSpace` branch in `reserveSpaceForMeta` (the in-file contract requires the two to match); add the matching seal vector to `MR.images`. Omit `signedNoKey` (only `.verified` is badged). Own signed items use the same glyph. Conversation list (`ChatPreviewView`) unchanged. Surface the "verified ≠ timestamp/ordering/completeness" caveat in help.
+
+## Compatibility
+
+- Wire format unchanged (the batch-element signature prefix already exists); no `chatVRange` bump; pre-feature relay-capable peers verify/accept.
+- API command `sign=` is additive with a default; app + core ship together.
+- No DB migration — `chat_items.msg_signed` already exists (written by `createNewChatItem_`, `Store/Messages.hs:614`; read by `mkCIMeta`).
+- The new optional app `msgSigned` decodes as absent on older cores.
+
+## Edge cases, races, correctness
+
+- **Bad signature → drop** (threat model): a signed content message whose signature doesn't verify against the recipient's roster key (forgery/tamper — keys don't rotate) is dropped + `RGEMsgBadSignature`, not shown unsigned. Test it; note it in help. Distinct from §7 enforcement, which rejects an *unsigned* mutation of a *signed* item.
+- **Member without keys** (`groupKeys = Nothing`): only the prepared/`GSMemUnknown` relay-channel state is keyless (`createPreparedGroup`, `Store/Groups.hs:654`, with the `TODO [member keys]` marker), and that state is non-current/non-active — it cannot send content, so the composer is unavailable. Any sendable membership has `groupKeys = Just` (key written before the membership becomes current). `groupMsgSigning` returning `Nothing` for `groupKeys = Nothing` is thus a harmless backstop, never reached on a real content send.
+- **Non-relay groups**: the `useRelays'` guard ⇒ never signed; UI must not offer it.
+- **Live messages**: each `XMsgUpdate` reuses the item's `msgSigned`, so every increment is signed iff the original was — exactly what §7 enforcement requires. Acceptable cost.
+- **Mutation enforcement (§7)**: a forged *unsigned* `XMsgUpdate`/`XMsgDel` of a held-signed item is rejected (`RGEMsgBadSignature`), content/visibility unchanged — not applied-then-unbadged. A legitimate signed edit/delete of a signed item is accepted. Test both, on both paths.
+- **Moderation-delete divergence**: a moderator holding the target *unsigned* (caught up via unsigned history) must still emit a *signed* delete so members holding the post signed accept it — hence moderation always-sign (§7). Without it, moderation of a signed post silently fails for those members. Test a moderation delete from a catch-up moderator.
+- **Non-batched path**: `sndMessageMBR` (`Internal.hs:2428`) uses raw `msgBody`, never reached in relay groups (`memberSendAction → MSASendBatched`). Add a test-asserted invariant; optionally route it through `encodeBatchElement signedMsg_`.
+- **History downgrade (posts, by design this PR)**: relay history catch-up rebuilds content unsigned and as-channel via `FwdChannel` (`sendHistory` / `processContentItem`, `Internal.hs:1278` / `:1349`; the relay re-encodes from `MsgContent` and has no author key). So a signed post (channel or member) is delivered unsigned on catch-up — no badge, and an as-channel post re-anonymizes. Graceful (absence ≠ forgery); document and test. Consequently PR 1's mutation enforcement (§7) does not fire for catch-up members (they hold the post unsigned), so a forged unsigned edit/delete still lands for them — the documented honest limit. PR 2 preserves signatures through history.
+- **Concurrency**: signing/verification are pure given keys; no new shared state. Send holds `withGroupLock`; receive runs under existing serialization. No new races.
+
+## Tests
+
+- Protocol (`tests/ProtocolTests.hs`): round-trip signed `XMsgNew`/`XMsgUpdate`/`XMsgDel`; assert binding `CBGroup <> (publicGroupId, memberId)`; verify accepts the right key, rejects wrong key / altered body / altered binding.
+- Integration (`tests/ChatTests/Groups.hs`, relay/channel setup): sign+verify ⇒ "(signed)"; off/default ⇒ none; missing roster key ⇒ "(signed, no key to verify)"; edit reuse keeps/omits the badge; **edit enforcement** — unsigned forged `XMsgUpdate` over a signed item ⇒ rejected (`RGEMsgBadSignature`), content unchanged (§7), and a legitimate signed edit of a signed item ⇒ accepted; **delete enforcement** — unsigned forged `XMsgDel` of a signed item ⇒ rejected, item not deleted (§7); signed self-delete of a signed item ⇒ deletes; unsigned self-delete of an unsigned item ⇒ deletes (no requirement); **moderation delete** — moderator's signed delete of a signed post ⇒ accepted + role-checked, and moderation always-sign holds even when the moderator holds the target unsigned; **as-channel signed** — owner `as_group=on sign=on` ⇒ recipient verifies and shows "(signed)" while displaying as the channel; **as-channel unsigned** — forwards via `FwdChannel`, no member id on the wire; **as-channel spoof** — non-owner `asGroup=on sign=on` ⇒ rejected (§5 guard); **history downgrade** — live recipient "(signed)", catch-up recipient not, and enforcement does not fire for the catch-up recipient; **bad-signature drop**; forgery rejection ⇒ `RGEMsgBadSignature`.
+- App: minimal decode test that `"verified"` / `"signedNoKey"` parse to the right enum on both platforms.
+
+## Commit plan (PR 1)
+
+1. **Structural (behavior-preserving)**: add `signableContent` (`XMsgNew_`, `XMsgUpdate_`, `XMsgDel_`); parameterize `groupMsgSigning` with `sign :: Bool`; thread `sign` through the content/edit send chain; generalize the batch send to carry a per-event `Maybe MsgSigning` (uniform-sign wrapper so existing callers are unchanged); add `signMessages :: Bool` to `APISendMessages` + its nine positional constructors. Every caller passes `False`/`Nothing` ⇒ no behavior change.
+2. **Content signing + update enforcement (core)**: `APISendMessages` parser; content send passes the real flag; edit signs iff the original was signed (§6); reject an unsigned `XMsgUpdate` of a signed item in `groupMessageUpdate` (§7); as-channel forward/display/owner-guard (§5). After this commit the update path is complete and spoof-free.
+3. **Delete signing + delete enforcement (core)**: per-item delete signing at the three send sites — self-delete conditional, moderation always-sign (§7); reject an unsigned `XMsgDel` of a signed item in `groupMessageDelete` (§7). After this commit the delete path is complete.
+4. **App**: decode `msgSigned` + recipient indicator (§C).
+5. **App**: composer long-press option + `apiSendMessages` wiring (§B).
+6. **Tests** (may accompany 2/3).
+
+Each commit builds and passes tests independently. §7's earlier `updateGroupChatItem` plumbing is dropped — that helper and its five callers are untouched, so there is no badge-fix commit.
+
+### Pre-implementation gates
+
+- **MUST**: the mutation-enforcement check is on **both** `groupMessageUpdate` and `groupMessageDelete` — an unsigned `XMsgUpdate`/`XMsgDel` of a `Just`-signed target is rejected via `RGEMsgBadSignature`. A missed path reopens the spoof.
+- **MUST**: per-item delete signing is wired at all three delete send sites (`Commands.hs:811/818` self-delete conditional; `:3909` moderation always-sign), and `XMsgDel_` is **not** added to `requiresSignature`.
+- **MUST**: the as-channel owner guard (§5) is on the forwarded `XMsgNew` path, and `FwdChannel` carries no signature.
+- **SHOULD**: re-grep `groupMsgSigning` / `sendGroupMessage` / `sendGroupMessages` / `sendGroupMessages_` callers; the batch send is generalized (per-event `Maybe MsgSigning`) without duplicating its body; only content-send, edit, and delete pass a variable signer.
+- **SHOULD**: the "verified" caveats (no timestamp/ordering; history downgrade; bad-signature drop) and the as-channel de-anonymization warning are surfaced in UI/help, and those tests exist.
+
+## Deferred to PR 2: history signature preservation
+
+Signable deletes and recipient enforcement moved into PR 1 (§7). What remains is the hard part PR 1's enforcement degrades around.
+
+**History signature preservation for posts.** On catch-up the relay rebuilds content unsigned (`processContentItem` re-encodes from `MsgContent`, has no author key; re-encoding invalidates the original signature — `Store/Delivery.hs:162`). So a catch-up member holds an originally-signed post as `Nothing`, and PR 1's enforcement does not fire for them (target held unsigned ⇒ no signature required). Two residual gaps that only preservation closes:
+
+- a relay can forge an unsigned delete/edit of a signed post for catch-up members (they hold it unsigned, so nothing is enforced);
+- the deeper inconsistency behind the moderation-divergence handling — members disagreeing on a post's signed status — is fully resolved only when all members hold the post signed.
+
+Design question (unchanged): does the `messages` row survive long enough to forward the original signed bytes on catch-up, or must signed bytes be persisted on the chat item (migration)?
+
+Honest limit until then: enforcement protects a post a recipient already holds verified; a relay that delivered the original unsigned sidesteps it (visible as a missing badge, not prevented).
+
+## Out of scope / future
+
+- Group-level "required signing" owner setting — rejects unsigned messages group-wide, closing the optional-downgrade gap.
+- **Verifiable-anonymous as-channel** — a channel-level signature (ring signature over the owner set, or a shared/authorization-chain channel key) that proves "a valid owner" without revealing which, so an as-channel post is verifiable *and* keeps sender anonymity. This PR's per-member signing cannot do both; signing an as-channel post reveals the owner (§5).
+- Signing reactions; signing auto-reply content; verifiable reports (signed `MCReport`).
+
+## Verification status (2026-06-25, branch `f/msg-signing`)
+
+Every symbol the plan names was located and its logic re-checked against current code. **No logic drift** was found in any anchored function — the plan's described behavior still holds everywhere. Three classes of correction below: mislabeled anchors (fix before relying on them), one structural clarification (threading is slightly larger than the prose implies), and a current line map (most anchors moved a little; re-confirm by symbol regardless).
+
+### Mislabeled / materially-moved anchors
+
+- `MsgSigStatus` is defined in **`src/Simplex/Chat/Types/Shared.hs:134`** (`MSSVerified | MSSSignedNoKey`), not in `Types.hs`/`Messages.hs`. DB encoding: `verified` / `no_key`; JSON tags (`enumJSON $ dropPrefix "MSS"`): `verified` / `signedNoKey`. The JSON/DB divergence the app section (§A) relies on is confirmed. Any core edit to the type itself targets `Types/Shared.hs`.
+- §5 "the direct path (`:1064`)" is wrong: the non-forwarded as-channel owner enforcement lives in **`checkSendAsGroup` (`Subscriber.hs:1057`)**; `:1064` is just the `XMsgNew → newGroupContentMessage` dispatch (fixed inline in §5).
+- §6 wording "add `msgSigned` to the pattern" — confirmed the own-item `CIMeta` pattern at `Commands.hs:739` does **not** bind `msgSigned` today; it must be added to the record pattern (the field exists on `CIMeta`, `Messages.hs:520`).
+- §3 "`sendGroupMessage` … 6 callers" — there are **7** `sendGroupMessage` sites; the 7th is the edit path itself (`Commands.hs:751`, the only variable-`sign` one). The six that pass `False`: `Commands.hs:908,2719,3325,3873,3876,3880`.
+- `signatureOptional` is at `Subscriber.hs:3848` (plan said ~:3844); `RGEMsgBadSignature` creation at `:3828` (plan said :3824). Behavior unchanged.
+
+### Structural clarification (affects §2/§3 threading)
+
+`groupMsgSigning` is invoked at **three** sites, two of them inside functions that do **not** currently receive any as-channel/sign flag:
+
+- `Internal.hs:2122` — inside `sendGroupMemberMessages` (hardcode `False`).
+- `Internal.hs:2367` — inside `sendGroupMessages_`.
+- `Commands.hs:3017` — direct `XGrpLeave` via `createSndMessages` (hardcode `False`).
+
+`sendGroupMessages_` has **no** `ShowGroupAsSender`/`asGroup` parameter, and `sendGroupMessages` (`:2332`) consumes its `ShowGroupAsSender` only for `shouldSendProfileUpdate` — it does **not** pass it down. So threading `sign` to the `groupMsgSigning` call inside `sendGroupMessages_` is genuinely new wiring: `sendGroupContentMessages_`/`sendGroupMessage` → `sendGroupMessages` → **(new param)** → `sendGroupMessages_` → `groupMsgSigning sign …`. The plan's §3 list already includes all these functions; this note just flags that the param add to `sendGroupMessages_` is load-bearing, not a pass-through that already exists.
+
+### Current line map (re-confirm by symbol)
+
+| Symbol | File:line |
+|---|---|
+| `requiresSignature` (insert `signableContent` next to it) | Protocol.hs:1334 |
+| `MsgSigning` (4-field record, applied positionally) | Protocol.hs:469 |
+| `encodeChatBinding` / `CBGroup` / `signChatMsgBody` | Protocol.hs:476 / 442 / 479 |
+| `FwdSender` (`FwdMember MemberId ContactName` / `FwdChannel`) | Protocol.hs:372 |
+| `groupMsgSigning` | Internal.hs:2113 (calls: 2122, 2367, Commands.hs:3017) |
+| `sendGroupMessages` / `_` | Internal.hs:2332 / 2365 |
+| `sendGroupMessage` / `'` | Internal.hs:2258 / 2264 |
+| `sendGroupMemberMessages` | Internal.hs:2119 |
+| `sndMessageMBR` (non-batched; never hit in relay groups) | Internal.hs:2431 (`memberSendAction` 2455, `MSASendBatched` 2453) |
+| `sendHistory` / `processContentItem` (as-channel → `FwdChannel` at 1375) | Internal.hs:1281 / 1352 |
+| `createNewSndMessage` (`signedMsg_`) | Store/Messages.hs:235 |
+| `APISendMessages` ctor | Controller.hs:382 |
+| `/_send` parser / `onOffP` | Commands.hs:5111 / 5490 |
+| 9 positional `APISendMessages` ctors (add `False`; `:2449` passes `live=True`) | Commands.hs:2392,2401,2421,2441,2449,2494,3236,3277,3286 |
+| `APISendMessages` handler / group send | Commands.hs:654 / 667 |
+| `sendGroupContentMessages` / `_` | Commands.hs:4447 / 4456 (callers 667, 698, 994) |
+| group edit (own-item pattern / send) | Commands.hs:739 / 751 |
+| `XGrpLeave` group send (`sendGroupMessage'`) | Commands.hs:3027 |
+| `verifyGroupSig` / `withVerifiedMsg` / `signatureOptional` | Subscriber.hs:116 / 3823 / 3848 |
+| `RGEMsgBadSignature` | Subscriber.hs:3828 |
+| forwarded `XMsgNew`: `xGrpMsgForward` / `FwdMember` / `withVerifiedMsg` / `newGroupContentMessage` / `FwdChannel→VMUnsigned` | Subscriber.hs:3771 / 3775 / 3784 / 3795 / 3787 |
+| `newGroupContentMessage` (`sentAsGroup` 2177) / `groupMessageUpdate` (owner guards 2236, 2282) | Subscriber.hs:2142 / 2225 |
+| `validSender` (`CIChannelRcv ⇒ GROwner`) / `checkSendAsGroup` | Subscriber.hs:2135 / 1057 |
+| `updateGroupChatItem` / `_` / `UPDATE` / `updatedChatItem` | Store/Messages.hs:2749 / 2758 / 2766 / 2547 |
+| §7 `updateGroupChatItem` callers (all 5) | Commands.hs:757; Subscriber.hs:1200,1566,2258,2298 |
+| `createNewSndChatItem` (`MSSVerified <$ signedMsg_`) / `createNewRcvChatItem` / `createNewChatItem_` (`msg_signed`) / `mkCIMeta` | Store/Messages.hs:548 / 562 / 614 / Messages.hs:528 |
+| `Store/Delivery.hs` `fwdSender` / `VMSigned` reconstruction | Delivery.hs:158 / 162–164 |
+| `sigStatusStr` | View.hs:389 |
+| iOS `CIMeta` / composer menu / `ciMetaText` / `/_send` build | ChatTypes.swift:3825 / SendMessageView.swift:238 / CIMetaView.swift:93 / AppAPITypes.swift:243 |
+| Kotlin `CIMeta` / composer menu / `CIMetaText` + `reserveSpaceForMeta` / `/_send` build | ChatModel.kt:3529 / SendMsgView.kt:198 / CIMetaView.kt:67 + 118 / SimpleXAPI.kt:3870 |
+| channels-overview.md anchors (:103,:159,:198,:214,:221,:237) | all confirmed |
+
+## Open design questions (2026-06-25)
+
+Status as of 2026-06-29: all resolved (Q1/Q3/Q5 by the team; Q2/Q4 by code verification). **Design change (2026-06-29):** §7's "badge refresh" was replaced by receive-time **enforcement** — a held-signed item's `XMsgUpdate`/`XMsgDel` must be signed or is rejected (`RGEMsgBadSignature`); signed deletes + enforcement moved from PR 2 into PR 1 (update *and* delete); §7's `updateGroupChatItem` plumbing dropped. One sub-rule baked in pending confirmation: moderation/admin deletes **always** sign in relay channels (self-deletes sign conditionally) to avoid the catch-up-moderator divergence — see §7.
+
+1. **RESOLVED — keep drop + `RGEMsgBadSignature`.** Member keys do not rotate (one key per member, communicated on join), so a have-the-key-but-mismatch is a genuine forgery/tamper signal, and a downgrade-to-unsigned would buy nothing against a malicious relay (which can simply drop the whole message). Behavior stays identical to existing signed events; the lagging-roster case is the `MSSSignedNoKey` accept path, not the drop path, so there is no honest false-positive. Threat-model bullet updated accordingly. Action: edge-case test + help note only.
+
+2. **RESOLVED — gate on `useRelays'` alone, no key-derived flag.** Verified: the only relay-channel state with `groupKeys = Nothing` is prepared/`GSMemUnknown` (`createPreparedGroup`, `Store/Groups.hs:654`), which is non-current/non-active and cannot send — the key is written before the membership becomes sendable. So every sendable member has `groupKeys = Just`. §B simplified to a `useRelays'` gate; §B asks the app task to confirm a member-agnostic relay-channel boolean exists (the as-channel toggle is owner-scoped), adding a plain non-secret one if not. The "member without keys" edge case is now documented as a harmless backstop.
+
+3. **RESOLVED — keep raw `Bool`.** No `SignMessages` newtype. Retain §3's placement guidance (put `sign` away from `showGroupAsSender`/`live` in each signature) as the transposition mitigation.
+
+4. **RESOLVED — guard reads stable, link-data owner identity; no false-negative.** Verified: `GROwner` is established from root-key-verifiable link data at connect time (`createLinkOwnerMember`, `Store/Groups.hs:3381`), and `isRosterRole` (`Internal.hs:1257`) excludes `GROwner`, so owner identity is never carried by the roster or `XGrpMemRole`. The as-channel guard is therefore independent of the known role-propagation bug, and (single owner today) a legitimate owner post never fails it. The §5 propagation note is retracted. The guard stays a MUST — it blocks a non-owner's signed `asGroup=True` post from rendering as the channel.
+
+5. **WITHDRAWN — non-issue.** A send's `sign` flag applies to its whole composed-message batch; `signableContent` filters to `XMsgNew`/`XMsgUpdate` and content sends do not interleave non-signable events.
+
+## Implementation divergences from plan (2026-07-06, branch `f/msg-signing`)
+
+Where the shipped implementation departs from the sections above. Each entry supersedes the referenced section for that detail; everything else was implemented as described. Re-confirm by symbol — line numbers are advisory.
+
+**D1 — §7 enforcement is verified-only, not signature-presence (supersedes §7's "'Signed' for the requirement means `MSSVerified` **or** `MSSSignedNoKey`").** The receive-time guard requires `MSSVerified` on **both** sides: an item held `MSSVerified` accepts a mutation only if the incoming mutation is itself `MSSVerified` (`itemSigned == Just MSSVerified && msgSigned /= Just MSSVerified` ⇒ reject). Reason: `withVerifiedMsg` verifies **only** `CBGroup` bindings — a signature under any other binding (`CBDirect`/`CBChannel`) resolves to `MSSSignedNoKey` *without verification*, even for a recipient that holds the author's key. So a presence-based check (`isNothing msgSigned`) would accept a relay-forged mutation carrying a garbage non-`CBGroup` signature — including against a badged `MSSVerified` item. Enforcement is therefore real only for `MSSVerified`; `MSSSignedNoKey` items get no enforcement (they are never badged, and authorship is unverifiable without the key, so nothing can be protected). The two helpers are `requireVerifiedEdit` / `requireVerifiedDelete` (`Subscriber.hs`; `requireVerifiedEdit` renamed from `requireVerifiedMutation` per review); both create the `RGEMsgBadSignature` item.
+
+**D2 — §7 channel history-delete always-signs (supersedes §7/§8 "self/history deletes sign conditionally").** `delEventSigned` (`Commands.hs`) signs on `onlyHistory || isJust msgSigned`: **channel history-delete (`CIDMHistory`) always signs**, matching moderation; only self-delete (`CIDMEBroadcast`) stays conditional (to preserve deniability of unsigned posts). Reason: the same catch-up divergence the plan fixed for moderation — a future non-authoring owner who caught up via unsigned history would otherwise emit an unsigned history-delete that live members holding the post verified would reject (D3/§7). Latent today (single-owner channels).
+
+**D3 — preemptive-moderation verification added (extends §7).** §7's receive check only guards items the recipient **already holds**. The `Left e` (item-not-found) branch of `groupMessageDelete` — which plants a `CIModeration` that auto-applies when the post later arrives — was unguarded, so a relay could deliver a forged **unsigned** moderation-delete *before* the signed post to pre-censor it. Added: in relay channels, reject an unverified moderation-delete of a not-yet-received item before planting the moderation (`useRelays' gInfo && msgSigned /= Just MSSVerified`, `Subscriber.hs`). Legitimate moderation always-signs (§7) and any recipient that passes `checkRole` holds the moderator's key, so no legitimate case is rejected.
+
+**D4 — §5 `encodeFwdElement` regression guard NOT added (supersedes §5's "Assert this in `encodeFwdElement` … as a regression guard" and the matching Edge-cases bullet).** `encodeFwdElement` (`Batch.hs`) is left as the original one-liner. The asserted invariant (a `FwdChannel` element never carries a signature) is already structural: `Store/Delivery.hs` derives `FwdChannel` only when `isNothing chatBinding_`, and `signedMsg_` is derived from the same value, so `FwdChannel ⟹ unsigned` by construction. An `error` guard would be unreachable and would only risk crashing the delivery worker; a `FwdMember` fallback is impossible there (`FwdChannel` carries no `memberId`).
+
+**D5 — CLI recipient indicator extended to content events (extends §C).** §C scopes the indicator to the apps (`CIMetaView`). The CLI (`View.hs`) additionally shows `(signed)` on content-message events — new messages, edits, and deletes — by appending `sigStatusStr msgSigned` in `viewReceivedMessage_` / `viewSentMessage` (new `appendLast` helper). Because `viewItemDelete` renders via `viewReceivedMessage`, delete events show the deleted post's signed status too. Unsigned content is unaffected (`sigStatusStr Nothing = ""`), so only the signing tests' event assertions changed.
+
+**D6 — bot/client API fixed at the generator (extends §4).** Beyond adding `signMessages` to core `APISendMessages`, the bot/client API was aligned at its source: the flag was added to the generator (`bots/src/API/Docs/Commands.hs`, `OnOffParam "sign" "signMessages" (Just False)`) and the outputs regenerated (`bots/api/COMMANDS.md`, `packages/simplex-chat-client/types/typescript/src/commands.ts`, `packages/simplex-chat-python/src/simplex_chat/types/_commands.py`) so the `cmdString` builders now emit `sign=on`; and `signMessages` was threaded through the three hand-written wrappers (`packages/simplex-chat-python/.../api.py`, TS `client.ts`, nodejs `api.ts`) whose `APISendMessages` construction otherwise omitted the now-required field.
diff --git a/plans/2026-06-04-fix-corrupted-video-upload-error.md b/plans/2026-06-04-fix-corrupted-video-upload-error.md
new file mode 100644
index 0000000000..e88e781a5d
--- /dev/null
+++ b/plans/2026-06-04-fix-corrupted-video-upload-error.md
@@ -0,0 +1,100 @@
+# Fix: IndexOutOfBoundsException when uploading media with an undecodable preview
+
+## Symptom
+
+```
+java.lang.IndexOutOfBoundsException: Index 6 out of bounds for length 6
+ at java.util.ArrayList.get(ArrayList.java:434)
+ at chat.simplex.common.views.chat.ComposeViewKt.ComposeView$sendMessageAsync(ComposeView.kt:827)
+ ...
+```
+
+The crash fires when sending a batch of picked media (e.g. 7 items) in which at least
+one item produces no preview bitmap — most commonly a corrupted or unusual video whose
+first frame cannot be extracted.
+
+## Root cause
+
+`ComposePreview.MediaPreview` carries two parallel lists that are assumed to be
+**equal-length and index-aligned**:
+
+```kotlin
+class MediaPreview(val images: List, val content: List)
+```
+
+Both consumers cross-index one list by the other's index, so the invariant is load-bearing:
+
+- `ComposeImageView` (preview row) iterates `media.images` and reads `media.content[index]`.
+- `ComposeView.sendMessageAsync` iterates `preview.content` and reads `preview.images[index]`
+ (the `MCImage` / `MCVideo` preview string). This is the crash site.
+
+`processPickedMedia` built the two lists out of step:
+
+- `imagesPreview` was appended **only when `bitmap != null`**.
+- `content` was appended **unconditionally** for videos, and for animated images that
+ passed the size check — regardless of whether a preview bitmap was produced.
+
+`getBitmapFromVideo` returns `PreviewAndDuration(null, …)` whenever Android's
+`MediaMetadataRetriever` cannot extract a frame, **even when no exception is thrown**
+(`Utils.android.kt:351`). So a single undecodable video appends to `content` but not to
+`images`, leaving `content.size == images.size + 1`. Iterating `content` then indexes
+`images[lastIndex+1]` → `Index N out of bounds for length N`.
+
+This is a pre-existing bug in the shared media picker; it is unrelated to any in-flight
+feature work and reproduces on both Android and Desktop (both use the `commonMain`
+`processPickedMedia`).
+
+## Fix
+
+Keep `content` and `imagesPreview` strictly paired at the source. The `when` now yields an
+`UploadContent?` instead of mutating `content` inside its branches, and both lists are
+appended together, gated on a non-null preview bitmap:
+
+```kotlin
+if (bitmap != null && uploadContent != null) {
+ content.add(uploadContent)
+ imagesPreview.add(resizeImageToStrSize(bitmap, maxDataSize = 14000))
+}
+```
+
+Each iteration now adds exactly zero or one entry to **both** lists, so the
+equal-length / index-aligned invariant holds by construction.
+
+### Behavior change
+
+Media that yields no decodable preview frame is now **skipped** rather than enqueued.
+Previously such a video crashed the send; now only the bad item is dropped and the rest of
+the picked batch sends normally (the loop evaluates each URI independently).
+
+The skip is **not silent**. A skipped video shows `showVideoDecodingException()`, gated on
+`AlertManager.hasAlertsShown()` so the alert neither stacks across several bad items in one
+batch nor duplicates the one `getBitmapFromVideo` already shows on its exception path. The
+genuinely silent gap this closes is the video path that returns a null frame **without**
+throwing (Android `getFrameAtTime` returns null; Desktop snapshot times out) — that path
+previously produced no alert and then crashed on send.
+
+Image decode failures need no new alert here: `getBitmapFromUri` is already called for every
+image (animated or not) with `withAlertOnException = !hasAlertsShown()`, so a null image
+bitmap is surfaced before this point. Only the video null-frame case lacked any notice.
+
+## Why this approach
+
+- **Fixes the invariant at its origin** rather than papering over it at the two read
+ sites. Guarding `images[index]` in `sendMessageAsync` would stop the crash but leave the
+ preview row (`ComposeImageView`) silently mismatched and the actual media set ambiguous.
+- **Minimal, surgical diff** confined to `processPickedMedia`; no API/type changes, no new
+ placeholder assets, no touch to the read sites.
+- **Cross-platform by construction**: the change lives in `commonMain`, so Android and
+ Desktop are both covered. iOS has a separate Swift compose implementation and is out of
+ scope for this fix.
+
+## Other `MediaPreview` construction sites (verified aligned)
+
+- `cs.preview` → single-element `listOf(mc.image)` / `listOf(content)` (edit path): aligned.
+- `constructFailedMessage` takes `last()` of each list: aligned if the input was aligned.
+
+## Test notes
+
+Manual repro: pick a multi-item batch including a corrupted/zero-frame video and send.
+- Before: `IndexOutOfBoundsException` on send.
+- After: the undecodable item is dropped; remaining media sends normally.
diff --git a/plans/2026-06-09-perf-group-members-merge-on2.md b/plans/2026-06-09-perf-group-members-merge-on2.md
new file mode 100644
index 0000000000..3000103b05
--- /dev/null
+++ b/plans/2026-06-09-perf-group-members-merge-on2.md
@@ -0,0 +1,95 @@
+# Perf — index member merge in `setGroupMembers` to O(n)
+
+**PR:** #7061 (`nd/group-members-merge-on2`)
+**Scope:** client-only (multiplatform: android + desktop). One-line change, no behavioral change.
+**File:** `apps/multiplatform/common/src/commonMain/kotlin/chat/simplex/common/views/chatlist/ChatListNavLinkView.kt:254`
+
+## Root cause (verified)
+
+`setGroupMembers` is the shared loader for the in-memory member list. After fetching
+members from core (`apiListMembers`) it merges the freshly-loaded list with the
+connection stats already held in memory, so an in-flight `connectionStats` isn't lost
+when the list is reloaded — `ChatListNavLinkView.kt:257-267`:
+
+```kotlin
+val currentMembers = chatModel.groupMembers.value
+val newMembers = groupMembers.map { newMember ->
+ val currentMember = currentMembers.find { it.id == newMember.id } // O(n) scan, inside an O(n) map → O(n²)
+ ...
+}
+```
+
+Two compounding costs:
+
+1. **O(n²) merge.** `currentMembers.find { it.id == newMember.id }` is a linear scan
+ run once per new member — `n` lookups × `n` scan = O(n²).
+2. **~n² String allocations + GC pressure.** `GroupMember.id` is a *computed* property,
+ not a stored field — `ChatModel.kt:2424`:
+
+ ```kotlin
+ val id: String get() = "#$groupId @$groupMemberId"
+ ```
+
+ Every `it.id` and `newMember.id` access allocates a fresh `String`. The nested
+ `find` evaluates `it.id` for (worst case) every current member on every iteration,
+ so the merge allocates on the order of n² short-lived strings, each compared by
+ value. In groups with thousands of members this is a visible main-thread lag spike.
+
+## Worst case observed
+
+`setGroupMembers` reloads `chatModel.groupMembers` (and runs the merge) whenever the
+member list is (re)loaded while members are already in memory. The most noticeable
+case: the **Chats with members** support-chat modal (`MemberSupportView`) reloads the
+whole list via `LaunchedEffect(Unit) { setGroupMembers(...) }` every time it (re)enters
+composition — e.g. after reading and closing a member's support chat — so it pays the
+full O(n²) merge and produces a lag spike on close in large groups
+(`MemberSupportView.kt:44`).
+
+## The fix (minimal — one change)
+
+Index the current members by id **once**, then look up in O(1):
+
+```kotlin
+val currentMembersById = chatModel.groupMembers.value.associateBy { it.id }
+val newMembers = groupMembers.map { newMember ->
+ val currentMember = currentMembersById[newMember.id]
+ ...
+}
+```
+
+- `associateBy { it.id }` builds the index in a single O(n) pass; each subsequent
+ lookup is O(1). Total merge cost drops from O(n²) to O(n).
+- String allocations drop from ~n² to ~2n (one `it.id` per current member while
+ building the map, one `newMember.id` per lookup).
+
+## Why it's safe (no behavioral change)
+
+- **Member ids are unique** — `id = "#$groupId @$groupMemberId"` is unique per member
+ within a group, and `setGroupMembers` always works within a single `groupInfo`. So
+ `associateBy { it.id }` cannot collide; `map[id]` returns exactly what
+ `find { it.id == id }` returned.
+- Same result set, same merged `GroupMember` objects, same order of `newMembers`
+ (the `map` over `groupMembers` is unchanged). Only the lookup strategy changes.
+- Everything downstream of the merge is untouched — `groupMembersIndexes`,
+ `groupMembers.value`, `membersLoaded`, `populateGroupMembersIndexes()`
+ (`ChatListNavLinkView.kt:268-271`).
+
+## Also sped up (same shared loader)
+
+`setGroupMembers` is the common in-memory member loader, called from several screens;
+all of them get the same speedup in large groups (identical results, just O(n)):
+
+- Group member list / member management — `GroupChatInfoView` (`:121, :1250, :1267`)
+- @-mention autocomplete — `GroupMentions` (`:119, :134`)
+- Channel relays — `ChannelRelaysView` (`:38, :124`)
+- Add members — `AddGroupView` (`:52`)
+- The group chat's member load on open — `ChatView` (multiple sites)
+- Chats with members — `MemberSupportView` (`:45, :67`)
+
+## Verification
+
+- Reasoned: ids unique within a group → `associateBy`/lookup is semantically identical
+ to the linear `find`. No caller observes a difference.
+- Manual: open **Chats with members** in a large group, read and close a member's
+ support chat repeatedly — the lag spike on close should be gone. Member list,
+ @-mentions, relays, and add-members screens should remain identical, just faster.
diff --git a/plans/2026-06-09-support-chat-unread-on-group-read.md b/plans/2026-06-09-support-chat-unread-on-group-read.md
new file mode 100644
index 0000000000..5d24cc5ff1
--- /dev/null
+++ b/plans/2026-06-09-support-chat-unread-on-group-read.md
@@ -0,0 +1,200 @@
+# Fix: support-chat unread stats not cleared after no-scope group read
+
+Branch: `nd/fix-support-chat-unread-on-group-read` (off `origin/master`)
+
+## Symptom
+
+In a group with member admission ("chat with admins"), some members keep showing
+as unread in the *chats with members* list even after the admin opens their support
+chat and reads everything. Reopening never clears them. It is most visible for
+members who have already been given a role (e.g. `member`), because pending members
+always render the flag icon anyway, so the stuck badge is invisible for them.
+
+## Root cause
+
+The *chats with members* badge is driven by the per-member counters
+`support_chat_items_unread / _member_attention / _mentions` on `group_members`
+(surfaced as `GroupSupportChat`, `Types.hs:1087`). These are denormalized counters,
+maintained by increment on receive and decrement on read.
+
+Reading a group **without a scope** (`APIChatRead` with `scope = Nothing`,
+`Commands.hs:1153-1166`) runs `updateGroupChatItemsRead` (`Store/Messages.hs:2078`),
+whose `UPDATE` filtered only by `group_id`:
+
+```sql
+UPDATE chat_items SET item_status = RcvRead, ...
+WHERE user_id = ? AND group_id = ? AND item_status = RcvNew
+```
+
+This flips **support-scope** items to `RcvRead` too, but never touches the
+`support_chat_items_*` counters. The result is a permanent desync:
+
+- the items are read (so the chat "looks" fully read), but
+- the per-member counters stay > 0 (so the member stays "unread" in the list), and
+- reopening the support chat can't fix it: the scoped read decrement
+ (`updateGroupScopeUnreadStats`, `Store/Messages.hs:2202`) only fires on a real
+ `RcvNew -> RcvRead` transition, and there are no `RcvNew` items left.
+
+This is inconsistent with how the group's main unread **count** is computed, which
+already excludes support items (`Store/Messages.hs:916`,
+`... AND group_scope_tag IS NULL AND group_scope_group_member_id IS NULL`). The read
+path simply forgot the same predicate.
+
+Note: `member_attention` self-heals on open via `checkSupportChatAttention`
+(`Commands.hs:593-613`), recomputing it from loaded items. `unread` and `mentions`
+have **no** such correction, which is why the badge persists.
+
+## Fix (Option A — prevent new corruption)
+
+Add the main-scope predicate to the two queries in the no-scope group-read path so
+that reading a group without a scope leaves support-scope items (and their
+disappearing-message timers) entirely untouched:
+
+- `updateGroupChatItemsRead` (`Store/Messages.hs`) — the read itself.
+- `getGroupUnreadTimedItems`, `Nothing` branch (`Store/Messages.hs`) — its companion
+ timed-items query.
+
+```sql
+AND group_scope_tag IS NULL AND group_scope_group_member_id IS NULL
+```
+
+Both lines are required and neither is droppable:
+
+- Without the read filter, support items get marked read (the bug).
+- Without the timed-items filter, a disappearing support message would have its
+ delete timer started by a main-group read while still unread — a *new*
+ inconsistency introduced by a half-fix. The no-scope `APIChatRead` handler
+ (`Commands.hs:1160-1166`) calls `getGroupUnreadTimedItems` then
+ `setGroupChatItemsDeleteAt` then starts deletion threads, so both must agree that
+ support items are out of scope.
+
+Support items continue to be read (and their counters decremented) the correct way:
+via the scoped read paths (`updateSupportChatItemsRead` / `updateGroupChatItemsReadList`
+with a `MemberSupport` scope), exercised when the support chat is opened.
+
+### Why this is consistent / safe
+
+- Selects exactly the main-scope rows, identical to the authoritative unread-count
+ query (`Store/Messages.hs:916`). No main item is ever wrongly excluded — inserts
+ always set `group_scope_tag` and `group_scope_group_member_id` together
+ (`Store/Messages.hs:600-603`).
+- `groups.members_require_attention` becomes *more* consistent, not less: the
+ no-scope read no longer zeroes support items behind a still-positive group counter.
+- The added predicate is constant, parameterized SQL — no injection surface — and is
+ the existing codebase idiom (916 / 1214 / 1524 / 1745).
+
+## Test
+
+`tests/ChatTests/Groups.hs :: testScopedSupportUnreadStatsGroupReadNoScope`
+(registered under the support-chat `describe` block).
+
+A member sends one support message (`markRead = False`), the admin marks the whole
+group read with `/_read chat #1` (no scope), then reads the item in scope with the
+**per-item** read `/_read chat items #1(_support:2) `. The per-item read only
+decrements on a genuine `RcvNew -> RcvRead` transition, so:
+
+- on master the no-scope read already consumed the item -> decrement is a no-op ->
+ `unread: 1, require attention: 1` (test fails);
+- with the fix the item is still unread -> decrement applies ->
+ `unread: 0, require attention: 0` (test passes).
+
+The full scoped read `/_read chat #1(_support:2)` is deliberately *not* used to
+assert this, because `updateSupportChatItemsRead` hard-zeroes the counters
+regardless of item state and would mask the bug.
+
+## Performance
+
+The added predicate makes both queries **faster**, not slower, and needs no new
+index. Verified two ways.
+
+### Query plan (EXPLAIN QUERY PLAN, via the checked-in plan snapshots)
+
+Regenerating `chat_query_plans.txt` shows both statements switch index:
+
+```
+- SEARCH chat_items USING INDEX idx_chat_items_groups_user_mention
+ (user_id=? AND group_id=? AND item_status=?) -- 3-column seek
++ SEARCH chat_items USING INDEX idx_chat_items_group_scope_stats_all
+ (user_id=? AND group_id=? AND group_scope_tag=? AND
+ group_scope_group_member_id=? AND item_status=?) -- 5-column seek
+```
+
+SQLite compiles `group_scope_tag IS NULL` / `group_scope_group_member_id IS NULL`
+into equality constraints (`=?`), so the two new columns *deepen the index seek*
+rather than adding a post-seek filter or scan. The read now uses
+`idx_chat_items_group_scope_stats_all`
+(`user_id, group_id, group_scope_tag, group_scope_group_member_id, item_status, …`,
+`M20250721_indexes.hs`), which already exists — this is the same index the
+authoritative unread-count query uses. No migration, no new index.
+
+Note: master was **not** degraded here — it already got a full 3-column seek via
+`idx_chat_items_groups_user_mention`. So this is a modest improvement, not the repair
+of a regression. The plan file only records two hunks (the two flipped statements);
+the `saveQueryPlans` test also churns an unrelated `group_members` count entry and the
+whole `agent_query_plans.txt`, both of which were reverted to keep the diff to exactly
+those two queries.
+
+### Micro-benchmark (synthetic 200k-row group)
+
+On a synthetic group of ~200k `chat_items` where ~25% are support-scope, running the
+old vs. new `UPDATE` in alternating trials:
+
+| Query | mean wall-clock |
+|-----------------|-----------------|
+| old (no filter) | ~10.5 s |
+| new (scoped) | ~7.4 s (≈ −29%) |
+
+The speedup tracks the row reduction: the new query touches only the ~75% main-scope
+rows, so it does ~25% less work and the tighter seek trims a bit more. This also
+directly demonstrates the bug — the old query flips ~50k support rows to `RcvRead`
+(without decrementing counters); the new one flips **0**.
+
+Caveat: absolute timings were noisy (concurrent GHC builds on the box); only the
+*relative* comparison across alternating trials is reliable, and it was consistent in
+direction and magnitude across runs. The gain scales with the support-item share — a
+group with no support chats sees no measurable change.
+
+## Limitations (accepted, by decision)
+
+1. **No retroactive repair.** This change only prevents *new* corruption. Rows already
+ stuck (counter > 0 while the items are `RcvRead`) stay stuck until either the
+ per-member "Mark read" action (`apiSupportChatRead` -> `updateSupportChatItemsRead`,
+ which hard-zeroes) or, for `member_attention` only, the self-heal on open
+ (`checkSupportChatAttention`). A one-shot migration recomputing the three counters
+ from `chat_items` was considered and **intentionally not done**.
+
+2. **`setUserChatsRead` is not fixed.** The global "mark all chats read"
+ (`APIUserRead` -> `setUserChatsRead`, `Store/Direct.hs:640-646`) has the same flaw:
+ its `UPDATE chat_items ... WHERE user_id = ? AND item_status = ?` has no chat-type
+ and no scope filter, so it reads support items user-wide without decrementing the
+ counters. It is **left as-is on purpose**: no GUI client invokes `APIUserRead`
+ (it exists only as the Haskell command type `Controller.hs:357` and the CLI
+ binding), so it is not reachable from Android / desktop / iOS — only the terminal
+ CLI. The same one-line predicate would close it if a client ever exposes it.
+
+3. **`getUpdateGroupItem` relies on a UI contract.** The per-item read
+ (`updateGroupChatItemsReadList` -> `getUpdateGroupItem`, `Store/Messages.hs:2178`)
+ has no scope filter on its `UPDATE` and its `Nothing` branch decrements nothing, so
+ passing a support item ID with `scope = Nothing` would reproduce the desync. This is
+ defended only by the in-code assumption ("we rely on UI to not pass item IDs from
+ incorrect scope", `Store/Messages.hs:2162-2163`), not by the query. Not reachable in
+ normal flow; left unchanged to keep the diff surgical.
+
+## Files changed
+
+- `src/Simplex/Chat/Store/Messages.hs` — two one-line scope predicates.
+- `tests/ChatTests/Groups.hs` — one regression test + its `it` registration.
+
+## Build & test run
+
+Library compiled clean via `bash /home/user/build/linux.sh`. The full test suite was
+subsequently built and run against this branch (968 examples). The regression test
+`should not read support chat items when reading group without scope` passes with the
+fix and fails when the fix is reverted (confirmed by rebuilding master and re-running),
+so it genuinely catches the desync.
+
+The suite had 8 failures on the run; each was classified as flaky/environmental,
+by-design, or pre-existing on master — none attributable to this change. In particular
+the timed-message failure (`both users have configured timed messages … restart`) was
+reproduced identically on master with the fix reverted (3/3), proving it pre-existing;
+it is a direct-chat test that never touches the group-scope read path.
diff --git a/plans/2026-06-12-fix-migrate-text-overlap.md b/plans/2026-06-12-fix-migrate-text-overlap.md
new file mode 100644
index 0000000000..1bb1d3a5c6
--- /dev/null
+++ b/plans/2026-06-12-fix-migrate-text-overlap.md
@@ -0,0 +1,71 @@
+# Fix overlapping warning texts after finalizing migration
+
+Branch: `nd/fix-migrate-text` · regression from PR [#6777](https://github.com/simplex-chat/simplex-chat/pull/6777) (`df5ea3d46`, new settings section design).
+
+## 1. Problem statement
+
+On the "Migrate device" screen (Android and desktop), after tapping **Finalize migration** the finished state renders broken: the two warning texts — "You **must not** use the same database on two devices." and "**Please note**: using the same database on two devices will break the decryption of messages…" — are painted on top of each other and on top of the "Migration complete" section card, directly under the section header.
+
+Reproduced on desktop with default settings. The screen immediately before (`LinkShownView`, with the QR code) renders correctly.
+
+## 2. Solution summary
+
+Move the two `SectionTextFooter` calls in `FinishedView` out of the `Box` and place them after it, so they render as sequential children of the screen's scroll `Column` — the same placement `LinkShownView` already uses for its footers.
+
+```diff
+ }
+- SectionTextFooter(annotatedStringResource(MR.strings.migrate_from_device_you_must_not_start_database_on_two_device))
+- SectionTextFooter(annotatedStringResource(MR.strings.migrate_from_device_using_on_two_device_breaks_encryption))
+ if (chatDeletion) {
+ ProgressView()
+ }
+ }
++ SectionTextFooter(annotatedStringResource(MR.strings.migrate_from_device_you_must_not_start_database_on_two_device))
++ SectionTextFooter(annotatedStringResource(MR.strings.migrate_from_device_using_on_two_device_breaks_encryption))
+ }
+```
+
+Total diff: 1 file, 2 lines moved (+2 / −2 at different indentation).
+
+## 3. Root cause
+
+PR #6777 added card chrome to `SectionView` and, in a sub-commit ("Migrate views: move all SectionTextFooter / SectionSpacer out of SectionView lambdas"), moved footers out of the card lambdas so they read as captions below the cards. In `FinishedView` (`MigrateFromDevice.kt`) the footers were moved out of the `SectionView` — but left **inside the wrapping `Box`**:
+
+```kotlin
+Box {
+ SectionView(stringResource(MR.strings.migrate_from_device_migration_complete)) {
+ // "Start chat" / "Delete database" buttons
+ }
+ SectionTextFooter(…you_must_not_start_database_on_two_device…) // Box child 2
+ SectionTextFooter(…using_on_two_device_breaks_encryption…) // Box child 3
+ if (chatDeletion) {
+ ProgressView() // Box child 4 (overlay)
+ }
+}
+```
+
+That `Box` exists for exactly one reason: to overlay `ProgressView` (a fullscreen-centered spinner) over the section while the chat database is being deleted. `Box` stacks its children at `TopStart`, so both footers render at the Box's top-left corner — over the card's top edge and over each other. This is the only migration sub-view where the refactor produced this shape: the other `Box`-wrapped states keep all flow content inside one child (a `SectionView` or an inner `Column`), and `LinkShownView` has no `Box` at all.
+
+`FinishedView` is composed inside `ColumnWithScrollBar` (via `SectionByState`), so composables emitted at the function's top level land in the scroll `Column` and stack vertically — which is where the footers belong.
+
+## 4. The fix in detail, and why this shape
+
+Three candidate fixes were compared:
+
+- **Move the 2 footer lines after the `Box`** (chosen). Smallest possible diff, zero re-indentation. Footers become siblings of the Box in the scroll `Column`, identical to the working `LinkShownView` pattern in the same file. `ProgressView` keeps its overlay semantics unchanged (same as `DatabaseInitView`, `ArchivingView`, `LinkCreationView`). Only behavioural delta beyond the bug fix: during the transient `chatDeletion` spinner, the overlay centers over the card rather than card + footers — matching every other migration sub-view.
+- **Wrap card + footers in a `Column` inside the Box.** Behaviorally near-identical, but ~40 lines of indentation churn and a layout shape no sibling view uses. Rejected: larger diff, no benefit.
+- **Also hoist `ProgressView` out of the Box.** Changes overlay semantics (spinner would flow below content instead of over it). Rejected: touches behavior the bug report doesn't concern.
+
+Regression risk: the change is placement-only — no logic, no state, no measurement changes. The new arrangement is the proven pattern of the adjacent view.
+
+## 5. Scope verification — no other instances of the bug class
+
+The class ("flow content as direct children of an overlay `Box`") was searched for across all Kotlin source sets (`commonMain`, `androidMain`, `desktopMain`, `android`, `desktop`) with three complementary structural scans:
+
+1. Every `Box` block with ≥2 stacking flow children (section views, footers, spacers, settings items): **only** `FinishedView`.
+2. All 384 footer/spacer call sites classified by nearest enclosing block: the only ones directly inside a `Box` are the two fixed lines.
+3. All ~25 composable functions that emit footers at function top level (placement decided by caller): no caller invokes them inside a `Box`.
+
+iOS is structurally immune: SwiftUI footers are part of `Section { } footer: { }` inside a `List`; `MigrateFromDevice.swift`'s `finishedView` was verified correct.
+
+Related but distinct (not fixed here): 10 `SectionTextFooter` calls app-wide still sit *inside* `SectionView` card lambdas (6 in migration views, plus `LinkAMobileView`, `ConnectMobileView`, 2 in `NetworkAndServers`), rendering inside the white card instead of as captions below it. Cosmetic placement inconsistency with #6777's stated pattern, no overlap — left for a separate change if desired.
diff --git a/plans/2026-06-15-fix-cli-outdated-help.md b/plans/2026-06-15-fix-cli-outdated-help.md
new file mode 100644
index 0000000000..e0105ef5bb
--- /dev/null
+++ b/plans/2026-06-15-fix-cli-outdated-help.md
@@ -0,0 +1,42 @@
+# Remove CLI help entries for long-removed commands
+
+Branch: `nd/fix-cli-outdated-help` · file `src/Simplex/Chat/Help.hs`.
+
+## 1. Problem statement
+
+Typing `/get stats` in the terminal CLI does nothing useful — it is documented in `/help` but no parser accepts it, so it fails to parse. Investigation found this is not isolated: four documented commands no longer exist in the parser.
+
+## 2. Solution summary
+
+Remove the four stale entries (five lines, including one continuation note) from `Help.hs`:
+
+- `/pq @ on/off` + its "(both have to enable…)" note — `contactsHelpInfo`
+- `/pq on/off` — `settingsInfo`
+- `/get stats` — `settingsInfo`
+- `/reset stats` — `settingsInfo`
+
+The stats pair were the tail of `settingsInfo`, so the now-orphaned trailing comma on the preceding `/(un)mute #` element is also dropped to keep the list literal valid.
+
+No replacement text is added: PQ has no command (it is automatic), and the stats functionality has no argument-compatible successor (see §4).
+
+## 3. Root cause
+
+Both removals were core changes that deleted parser, handler, and command constructor but left `Help.hs` untouched:
+
+- **`/pq` (both forms)** — commit `756779186` "core: enable PQ encryption for contacts (#4049)", 2024-04-22. It removed the parsers `"/pq @" *> (SetContactPQ …)` and `"/pq " *> (APISetPQEncryption …)`; post-quantum encryption for contacts became automatic, so the manual toggle was obsolete. `SetContactPQ` and `APISetPQEncryption` no longer exist in `src/`.
+- **`/get stats` / `/reset stats`** — commit `5907d8bd0` "core: remove legacy agent stats (#4375)", 2024-07-01. It removed the parsers `"/get stats" $> GetAgentStats` and `"/reset stats" $> ResetAgentStats`, their handlers, the `GetAgentStats`/`ResetAgentStats` constructors in `Controller.hs`, and the `View.hs` rendering — but its diff touched `Chat.hs`, `Controller.hs`, `View.hs`, `cabal.project`, `sha256map.nix`, not `Help.hs`.
+
+In both cases the help text became a promise the binary could no longer keep.
+
+## 4. Scope verification — no other stale entries, no replacements documented
+
+All 120 commands documented across every section of `Help.hs` were extracted and matched against the parser string literals in `Library/Commands.hs` (`chatCommandP`). Every entry resolves to a live parser except the four above. ~10 entries that a naive prefix match flagged were manually confirmed valid: incognito-suffix forms parsed by `incognitoP` (`/accept incognito`, `/connect incognito`, `/simplex incognito`), usage examples (`/file bob ./photo.jpg`, `/group team`), and inline sub-alternatives (`/start remote host new`, `/stop remote host new`, `/switch remote host local`, `/chats all`).
+
+Why no replacement text:
+
+- **PQ** — there is no command; encryption is negotiated automatically. Documenting nothing is correct.
+- **Stats** — the nearest live commands are `/get servers summary ` and `/reset servers stats`, but they require a `userId` argument and return the agent servers summary, not the old argument-less usage statistics. They were never in CLI help; adding them is a separate documentation enhancement, deliberately out of scope for a "remove what no longer exists" fix.
+
+## 5. Why this shape
+
+Pure deletion of dead documentation — no behavioral change, smallest diff that makes `/help` truthful. Comma handling is the only subtlety: the `/pq @` and `/pq on/off` removals sit before comma-bearing neighbors (a `""` separator and `/network` respectively) and need no adjustment; the `/get stats` + `/reset stats` removal makes `/(un)mute #` the last `settingsInfo` element, so its trailing comma is removed to avoid a dangling-comma parse error before `]`.
diff --git a/plans/2026-06-15-fix-file-upload-long-name.md b/plans/2026-06-15-fix-file-upload-long-name.md
new file mode 100644
index 0000000000..f0917783bd
--- /dev/null
+++ b/plans/2026-06-15-fix-file-upload-long-name.md
@@ -0,0 +1,77 @@
+# Fix: long file name hides the close icon in the compose file preview
+
+Date: 2026-06-15
+Branch: `nd/fix-file-upload-with-long-name`
+Platforms affected: Android, Desktop, iOS
+
+## Problem
+
+When a file is attached for sending, the compose area shows a preview row with the
+file icon, the file name, and a close (X) icon to cancel/remove the file before
+sending. If the file name is long, the close icon is not shown, so the user cannot
+dismiss the attachment.
+
+## Cause
+
+The bug is the same layout defect on both codebases: the file-name text is
+unconstrained, so a long name consumes all horizontal space and squeezes the
+trailing close button to zero width.
+
+### Android / Desktop — `ComposeFileView.kt`
+
+The row was laid out as:
+
+```
+Icon(fixed) | Text(fileName) | Spacer(weight 1f) | IconButton(close)
+ ^ unweighted, no maxLines
+```
+
+In a Compose `Row`, unweighted children are measured first and take the remaining
+width before weighted children get anything. The unweighted `Text` therefore grabbed
+the whole remaining width on a long name, leaving the weighted `Spacer` — and the
+`IconButton` after it — with ~0 width. The flexible element was the `Spacer`, but a
+`Spacer` can only distribute the space the rigid `Text` did not already eat.
+
+### iOS — `ComposeFileView.swift`
+
+```
+Image(fixed) | Text(fileName) | Spacer() | Button(close)
+ ^ no lineLimit
+```
+
+A `Text` with no `lineLimit` reports its full single-line ideal width and refuses to
+truncate, so a long name collapses the `Spacer` and pushes the `Button` past the
+`.frame(maxWidth: .infinity)` edge, off-screen.
+
+## Fix
+
+Make the file name the element that yields space and let it truncate, so the
+fixed-size close control's space is always reserved.
+
+- **Kotlin:** give the `Text` the `weight(1f)` (instead of the `Spacer`) and
+ `maxLines = 1`, and drop the now-redundant `Spacer`. This matches the existing
+ idiom — `ComposeImageView` puts `weight(1f)` on its content, and `CIFileView`
+ caps file-name text with `maxLines = 1`.
+- **Swift:** add `.lineLimit(1)` to the `Text`, so it truncates instead of
+ overflowing, matching how file names are shown elsewhere on iOS.
+
+## Why this is the right fix (not a workaround)
+
+`ComposeFileView` was the only compose preview that gave the weight to a `Spacer`
+rather than to its content; every sibling preview (`ComposeImageView`,
+`ContextItemView`) reserves space for the trailing close control by weighting the
+content. The change brings the file preview in line with the established pattern
+rather than adding a special case. It is purely structural — no behavior changes
+beyond layout.
+
+## Scope / risk
+
+- One-spot edit per file; no API or behavior change.
+- Android and Desktop share the Kotlin file, so both are fixed together; iOS is the
+ separate Swift file.
+- No string/translation keys touched.
+
+## Verification
+
+- Visual: attach a file with a very long name on Android, Desktop, and iOS; confirm
+ the name truncates and the close (X) icon stays visible and tappable.
diff --git a/plans/2026-06-17-fix-group-garbled-error.md b/plans/2026-06-17-fix-group-garbled-error.md
new file mode 100644
index 0000000000..c660d13a48
--- /dev/null
+++ b/plans/2026-06-17-fix-group-garbled-error.md
@@ -0,0 +1,27 @@
+# Fix garbled error when saving group profile (member admission)
+
+## Problem
+
+Saving a group profile change — e.g. enabling member admission (Review = "All") from Group preferences → Member admission — can fail with an unreadable alert:
+
+```
+chat.simplex.common.model.API$Error@3ea295c.err
+```
+
+The user sees an object reference instead of the actual error, so there is no way to tell what went wrong.
+
+## Cause
+
+In `apiUpdateGroup` the `API.Error` branch builds the alert message with `"$r.err"` (`SimpleXAPI.kt:2292`). In a Kotlin string template `"$r.err"` interpolates `r.toString()` — and `API.Error` has no custom `toString`, so it yields `chat.simplex.common.model.API$Error@` — then appends the literal text `.err`. The meaningful message (`r.err.string`) is never read.
+
+This surfaces whenever the core rejects the update. A concrete trigger is a **desynced member role**: the client shows the Save controls because `groupInfo.isOwner` is true, but the core's `assertUserGroupRole gInfo GROwner` (`Commands.hs:3840`) disagrees and returns `CEGroupUserRole`. The display bug then hides which error it was.
+
+## Fix
+
+Render the error message instead of the object reference:
+
+```kotlin
+AlertManager.shared.showAlertMsg(generalGetString(errorTitle), "${r.err.string}")
+```
+
+One-line change in `SimpleXAPI.kt`. This is the only occurrence of the `"$r.err"` pattern in the codebase. The underlying core rejection is unchanged — but it is now shown clearly to the user.
diff --git a/plans/2026-06-17-message-info-file-xftp-servers.md b/plans/2026-06-17-message-info-file-xftp-servers.md
new file mode 100644
index 0000000000..f7803984cf
--- /dev/null
+++ b/plans/2026-06-17-message-info-file-xftp-servers.md
@@ -0,0 +1,140 @@
+# Plan: Show XFTP servers used for a file in Message Info
+
+## Goal
+In the message-info screen, when the message contains a file, show the list of XFTP servers that hosted the file's chunks ("servers used to upload the file").
+
+## Why this is needed
+For transparency: a recipient downloads a file's chunks from XFTP relays without any visible indication of which servers those are. Surfacing them in message info lets a user see exactly what servers they are downloading from (and, for sent files, uploading to) whenever they want to know — useful for trust, debugging, and deciding whether to download.
+
+## Decisions (confirmed)
+- **Direction:** Both sent and received files.
+- **Visibility:** Always shown when the item has a file (not gated behind Developer tools).
+- **Platform:** Android, desktop, and iOS.
+
+## Why this needs a core change (not Kotlin-only)
+The server list is **already known to the app** — the file description (which lists each chunk's XFTP server replicas) is what the agent uses to upload/download. But that data lives in the **core (Haskell) layer**: it's stored in the `files` table (`private_snd_file_descr` for sent, the rcv file descr row for received) and parsed inside the core. It is **never surfaced across the core→client API boundary**: the client-facing `CIFile` and `ChatItemInfo` types carry no server info. So this is a **plumbing task** (expose existing data through the API response), not an algorithmic one. The core already has the extraction helper.
+
+## Existing building blocks (no new logic needed)
+- `Internal.hs:764-766` — `fileServers` extracts the unique `[XFTPServer]` from a parsed description's chunk replicas. Currently a local `where` helper; will be lifted to a reusable top-level function.
+- `Internal.hs:747` — `parseFileDescription :: Text -> CM (ValidFileDescription 'FRecipient)`.
+- `Store/Files.hs:42` — `getRcvFileDescrByRcvFileId` returns `RcvFileDescr {fileDescrText, fileDescrComplete}` (received files).
+- `Store/Files.hs:197` — `setSndFTPrivateSndDescr` stores `private_snd_file_descr` (sent files). A matching getter must be added (none exists today).
+- `XFTPServer` already JSON-encodes to a string on the wire (see `XFTPServerSummary.xftpServer :: XFTPServer` → Kotlin `xftpServer: String`), so the Kotlin field can be `List`.
+
+---
+
+## Implementation
+
+### 1. Core — extraction helper (`src/Simplex/Chat/Library/Internal.hs`)
+- Lift `fileServers` out of `receiveViaCompleteFD`'s `where` block to a top-level function, generalized to work on any party's description chunks:
+ ```haskell
+ fileDescrServers :: FD.FileDescription p -> [XFTPServer]
+ fileDescrServers FD.FileDescription {chunks} =
+ S.toList $ S.fromList $ concatMap (\FD.FileChunk {replicas} -> map (\FD.FileChunkReplica {server} -> server) replicas) chunks
+ ```
+ (Keep `receiveViaCompleteFD` working by calling the lifted helper.)
+- Add a convenience that resolves a file's servers by direction, returning `[]` when no XFTP description exists (inline/legacy files):
+ ```haskell
+ getChatItemFileServers :: User -> ChatItem c d -> CM [XFTPServer]
+ ```
+ - For **received** (`SMDRcv`) with an XFTP file: `getRcvFileDescrByRcvFileId` → `parseFileDescription` → `fileDescrServers`.
+ - For **sent** (`SMDSnd`) with an XFTP file: read `private_snd_file_descr` (new getter) → parse the sender description → `fileDescrServers`.
+ - Guard on `fileProtocol == FPXFTP`; wrap parse in tolerant error handling so a missing/partial descr yields `[]` (no crash, no section).
+
+### 2. Core — store getter (`src/Simplex/Chat/Store/Files.hs`)
+- Add `getSndFTPrivateSndDescr :: DB.Connection -> User -> FileTransferId -> IO (Maybe Text)` reading `private_snd_file_descr` from `files` (mirror of `setSndFTPrivateSndDescr`; column already selected at `Files.hs:799`). Export it.
+
+### 3. Core — extend `ChatItemInfo` (`src/Simplex/Chat/Messages.hs`)
+- Add field:
+ ```haskell
+ data ChatItemInfo = ChatItemInfo
+ { itemVersions :: [ChatItemVersion],
+ memberDeliveryStatuses :: Maybe (NonEmpty MemberDeliveryStatus),
+ forwardedFromChatItem :: Maybe AChatItem,
+ fileXftpServers :: [XFTPServer] -- NEW (empty when no file / not XFTP)
+ }
+ ```
+- `$(JQ.deriveJSON defaultJSON ''ChatItemInfo)` at `Messages.hs:1531` regenerates the instance automatically. Import `XFTPServer` if not already in scope.
+- Note: using `[XFTPServer]` (not `Maybe`) keeps the JSON additive and the Kotlin side simple; empty list = nothing to show.
+
+### 4. Core — populate in handler (`src/Simplex/Chat/Library/Commands.hs:619`)
+- In `APIGetChatItemInfo`, after computing `forwardedFromChatItem`:
+ ```haskell
+ fileXftpServers <- getChatItemFileServers user ci
+ pure $ CRChatItemInfo user aci ChatItemInfo {itemVersions, memberDeliveryStatuses, forwardedFromChatItem, fileXftpServers}
+ ```
+
+### 5. Kotlin model (`apps/multiplatform/.../model/ChatModel.kt:5207`)
+```kotlin
+class ChatItemInfo(
+ val itemVersions: List,
+ val memberDeliveryStatuses: List?,
+ val forwardedFromChatItem: AChatItem?,
+ val fileXftpServers: List = emptyList() // NEW; server hosts as strings
+)
+```
+(`XFTPServer` serializes to a string, matching the existing `XFTPServerSummary.xftpServer: String`.)
+
+### 6. Desktop/shared UI (`apps/multiplatform/.../views/chat/ChatItemInfoView.kt`)
+- In `Details()` (`:250-283`), after the existing file-status block, add (always-visible, when present):
+ ```kotlin
+ if (ci.file != null && ciInfo.fileXftpServers.isNotEmpty()) {
+ // section header + one InfoRow/host per server
+ }
+ ```
+ - Render as its own `SectionView` with a title (e.g. "File servers") and one row per server host, styled like the existing info rows. For long host strings, single-line with ellipsis (consistent with the long-name handling already on this branch).
+- Add the servers to the shareable text in `itemInfoShareText` (`:534-580`), near the existing file-status share line (`:564-565`), so "Share" / copy includes them.
+
+### 7. Translations (additive only — never rename/remove keys)
+- Add one new key to `apps/multiplatform/common/src/commonMain/resources/MR/base/strings.xml`, e.g.:
+ ```xml
+ File servers
+ ```
+ Base locale only; Weblate fans out to other locales. Do not touch existing keys.
+
+### 8. iOS model (`apps/ios/SimpleXChat/ChatTypes.swift:5773`)
+Same core change (shared `libsimplex`), so iOS only needs the Swift model + view. Add the optional field (optional so an absent key never breaks decoding):
+```swift
+public struct ChatItemInfo: Decodable, Hashable {
+ public var itemVersions: [ChatItemVersion]
+ public var memberDeliveryStatuses: [MemberDeliveryStatus]?
+ public var forwardedFromChatItem: AChatItem?
+ public var fileXftpServers: [String]? // NEW
+}
+```
+
+### 9. iOS UI (`apps/ios/Shared/Views/Chat/ChatItemInfoView.swift`)
+- In `details()`, after the `developerTools` block (always-visible when present):
+ ```swift
+ if ci.file != nil, let servers = chatItemInfo?.fileXftpServers, !servers.isEmpty {
+ infoRow("File servers", servers.map(serverHostname).joined(separator: "\n"))
+ }
+ ```
+ `serverHostname(_:)` is public in `SimpleXChat` (`ErrorAlert.swift:142`).
+- Add the same to `itemInfoShareText()` (joined with ", "). Strings are inline `NSLocalizedString` (no separate resource file to edit).
+
+---
+
+## Edge cases / behavior
+- **Inline / legacy files** (no XFTP description): `fileXftpServers == []` → section hidden. No crash.
+- **Sent file before upload completes** (`private_snd_file_descr` not yet set): `[]` → hidden until available.
+- **Received file not yet accepted/downloaded:** the rcv description exists as soon as the offer is received (it's what enables download), so servers are available even before download. ✓
+- **Multiple chunks across different servers:** deduped via `S.fromList`; all distinct servers listed.
+- **Large files (any size up to the limits):** servers are accurate regardless of size. Chat-message files **never** use XFTP redirect — the description is split across multiple `XMsgFileDescr` messages (`splitFileDescr`) and reassembled in full by the recipient (`appendRcvFD`), so a received chat file always carries the real data-chunk servers. (`maxFileSize` = 1 GB soft, `maxFileSizeHard` = 5 GB; XFTP chunk sizes 64 KB / 256 KB / 1 MB / 4 MB.)
+- **Redirect descriptions:** XFTP redirect (a small `redirect = Just` description whose chunks point to the relay hosting the real description) is used **only** for *standalone file links* (`SFDONE` `Nothing` branch → `xftpSndFileRedirect`), which have no chat item and never appear in message info. The chat-message branch never redirects, so no redirect description can reach `getChatItemFileServers` — no guard is needed.
+
+## Build / verification
+- **Heaviest step:** rebuild the native core lib (`libsimplex`) consumed by the multiplatform app, since core types changed. Without the rebuild, the new JSON field is simply ignored by the old lib (the Kotlin default `emptyList()` keeps it backward-compatible — section just won't appear).
+- Tests: a core unit/integration check that `APIGetChatItemInfo` returns a non-empty `fileXftpServers` for an XFTP file (sent and received), empty for a text message and for an inline file.
+- Manual: send a file → open message info → confirm the server list; repeat on the receiving device for the received item.
+
+## Touch list
+- `src/Simplex/Chat/Library/Internal.hs` — lift `fileDescrServers`, add `getChatItemFileServers`.
+- `src/Simplex/Chat/Store/Files.hs` — add `getSndFTPrivateSndDescr` (+ export).
+- `src/Simplex/Chat/Messages.hs` — add `fileXftpServers` to `ChatItemInfo`.
+- `src/Simplex/Chat/Library/Commands.hs` — populate it in `APIGetChatItemInfo`.
+- `apps/multiplatform/.../model/ChatModel.kt` — add Kotlin field.
+- `apps/multiplatform/.../views/chat/ChatItemInfoView.kt` — UI section + share text.
+- `apps/multiplatform/.../resources/MR/base/strings.xml` — new label key.
+- `apps/ios/SimpleXChat/ChatTypes.swift` — add `fileXftpServers` to the Swift `ChatItemInfo`.
+- `apps/ios/Shared/Views/Chat/ChatItemInfoView.swift` — UI row in `details()` + `itemInfoShareText()`.
diff --git a/plans/2026-06-19-channel-received-remove-right-gap.md b/plans/2026-06-19-channel-received-remove-right-gap.md
new file mode 100644
index 0000000000..5ada84b2b0
--- /dev/null
+++ b/plans/2026-06-19-channel-received-remove-right-gap.md
@@ -0,0 +1,95 @@
+# Remove the right gap on received messages in channels
+
+## Problem
+
+In groups, received messages are laid out as left-aligned chat bubbles whose
+maximum width is capped well short of the right edge, leaving a large empty gap
+on the right so long content wraps early. In channels this wastes horizontal
+space — channel posts are broadcast/feed-style content that reads better using
+nearly the full row width.
+
+## Change
+
+For channels only, received messages drop the right-side gap so content can use
+nearly the full row width (a small edge margin remains). This only changes the
+maximum available width: long text uses more of the row, short messages still
+size to content, and media stays within its existing cap. Sent messages keep
+their existing layout.
+
+### Android / desktop (`apps/multiplatform`)
+
+The `end` padding becomes `12.dp` (the same edge margin sent messages use)
+instead of `adjustTailPaddingOffset(66.dp, …)`, at the four received-message
+layout sites in `ChatItemsList` (`ChatView.kt`): the `GroupRcv`
+(member-attributed) and `ChannelRcv` (unattributed) branches, each with and
+without an avatar.
+
+```kotlin
+end = if (voiceWithTransparentBack || chatInfo.isChannel) 12.dp
+ else adjustTailPaddingOffset(66.dp, start = false)
+```
+
+### iOS (`apps/ios`)
+
+iOS computes one per-message `maxWidth` in `ChatView.swift` and applies it to
+every bubble; the `* 0.84` factor is the gap. For a received message in a
+channel that factor is dropped (full width minus the avatar inset) — the same
+geometry the voice-message case already uses:
+
+```swift
+let channelReceived = !ci.chatDir.sent && cInfo.isChannel
+let maxWidth = cInfo.chatType == .group
+? voiceNoFrame || channelReceived
+? (g.size.width - 28) - 42
+: (g.size.width - 28) * 0.84 - 42
+: ...
+```
+
+The received check (`!ci.chatDir.sent`) is explicit here because, unlike the
+Kotlin layout (which has a separate received branch), iOS shares one `maxWidth`
+between sent and received.
+
+## Why gate on `ChatInfo.isChannel` (`useRelays`)
+
+The change is gated per chat on `ChatInfo.isChannel`, which is
+`groupInfo?.useRelays == true` — `chatInfo.isChannel` on both Android/desktop and
+iOS (`cInfo.isChannel`).
+
+This is the robust signal. The whole channel feature on both platforms keys on
+`useRelays` (channel preferences, member management, info view, broadcast
+compose, etc.); `useRelays` is a non-optional `Bool` that is always present on a
+group.
+
+- **Not on the group-type `isChannel`** (`publicGroup?.groupType == channel`).
+ This was the first attempt and it left the gap in place on iOS. The likely
+ mechanism: `publicGroup` is an optional reconstructed from nullable DB columns
+ (`src/Simplex/Chat/Store/Groups.hs` `toGroupProfile`, plus a creation path that
+ sets `publicGroup = Nothing`), so when it is not populated for a chat the
+ optional chain silently evaluates to `false` and the gap is never removed.
+ `useRelays` cannot fail this way — it is a required `Bool` set at group
+ creation (`useRelays = not direct`, `Commands.hs:2080`). Independent of the
+ exact mechanism, `useRelays` is the safer signal. It is also as precise: the
+ only group type ever constructed is `GTChannel` (`GTGroup` is defined but never
+ instantiated), and `useRelays == true` is set on exactly that same
+ public-group/channel path, so `useRelays == true` ⟺ "is a channel" for every
+ chat today — regular groups, business chats and direct chats all have
+ `useRelays` false/absent (verified: no non-channel path sets it true).
+- **Not on the item direction.** The unattributed `ChannelRcv` direction is
+ produced for any group message without an attributed member, not only in
+ channels, and channels also contain member-attributed (`GroupRcv`) posts.
+ Gating on direction would both over- and under-match, so the gate is the
+ per-chat `isChannel`.
+
+## Scope
+
+Regular groups, business chats, and direct chats are unchanged (`isChannel` is
+false for them). Sent messages are untouched.
+
+## Verification
+
+- Android/desktop: `:common:compileKotlinDesktop` compiles clean.
+- iOS: change is a small, type-safe Swift expression; build/verify on macOS
+ (Xcode) — not compilable on the Linux build host used here.
+- Visual (both platforms): in a channel, long received messages widen toward the
+ right edge; in a regular group and in direct chats the right gap is unchanged;
+ sent messages are unchanged everywhere.
diff --git a/plans/2026-06-20-channel-received-no-avatar-left-padding.md b/plans/2026-06-20-channel-received-no-avatar-left-padding.md
new file mode 100644
index 0000000000..13ee4ebc4f
--- /dev/null
+++ b/plans/2026-06-20-channel-received-no-avatar-left-padding.md
@@ -0,0 +1,103 @@
+# Remove left padding on consecutive (no-avatar) received messages in channels
+
+## Problem
+
+In a channel, received messages show the sender avatar on the first message of a
+run and hide it on consecutive messages, but those consecutive messages still
+reserve the avatar-sized **left padding** so they line up under the first. For a
+channel's feed-style layout this indentation wastes horizontal space —
+consecutive received messages should sit flush-left where the avatar would be.
+This applies to **both** the channel owner's broadcasts and contributors' posts.
+
+Desired behaviour: in channels, any received message that does **not** show an
+avatar (a consecutive post from the same sender) drops the avatar-sized left
+padding. The first message of a run still shows the avatar and keeps its layout;
+when the run is broken (a different sender, or a time gap), the next message
+shows the avatar again — this run logic is unchanged, only the no-avatar left
+padding is reduced.
+
+## The two received directions in a channel
+
+Received items in a channel arrive as one of two directions
+(`Subscriber.hs`, `saveRcvCI`):
+
+- **`ChannelRcv`** (no member) — the **owner's** broadcast, sent "as the channel".
+ The backend permits sending-as-group only to the owner, and a channel owner's
+ main-scope messages are always sent as group (`ChatInfo.sendAsGroup` is true
+ for `useRelays && memberRole >= Owner` in the main scope), so received owner
+ posts arrive as `ChannelRcv`. Shows the channel avatar.
+- **`GroupRcv(member)`** (attributed) — a **contributor's** post, carrying the
+ member. Shows the member avatar.
+
+Both are received messages, and the change now applies to **both** when they hide
+the avatar. (An earlier revision scoped this to `ChannelRcv`/owner only; it now
+covers contributors too, per request.)
+
+## Change
+
+In channels — gated on `ChatInfo.isChannel` (the `useRelays` flag, which is
+reliably present, unlike the optional group-type predicate) — the no-avatar
+branches for **both** `ChannelRcv` and `GroupRcv` drop the avatar-sized left
+padding down to the base inset where the avatar itself starts. In non-channel
+groups the `GroupRcv` no-avatar layout is unchanged (`isChannel` is false). The
+avatar-shown layouts, sent messages, and all other chats are unchanged.
+
+The same Row's `end` padding is already gated on `chatInfo.isChannel` (the merged
+right-gap change #7106), so gating `start` on `isChannel` keeps each Row
+internally consistent and the change precisely "in channels".
+
+### Android / desktop (`apps/multiplatform`, `ChatView.kt`, `ChatItemsList`)
+
+Both the `CIDirection.GroupRcv` and `CIDirection.ChannelRcv` `showAvatar == false`
+rows:
+
+```kotlin
+// before
+.padding(start = 8.dp + (MEMBER_IMAGE_SIZE * fontSizeSqrtMultiplier) + 4.dp, end = …)
+// after
+.padding(start = if (chatInfo.isChannel) 8.dp else 8.dp + (MEMBER_IMAGE_SIZE * fontSizeSqrtMultiplier) + 4.dp, end = …)
+```
+
+### iOS (`apps/ios`, `ChatView.swift`, `chatItemListView`)
+
+Both the `.groupRcv` and `.channelRcv` no-avatar branches:
+
+```swift
+// before
+.padding(.leading, 10 + memberImageSize + 12)
+// after
+.padding(.leading, chat.chatInfo.isChannel ? 12 : 10 + memberImageSize + 12)
+```
+
+## Run behaviour (unchanged)
+
+`shouldShowAvatar(current, older)` shows the avatar on the first message of a
+same-sender run and hides it on consecutive ones; a different sender or a gap
+resets the run. For `GroupRcv` "same sender" is the same `memberId`; for
+`ChannelRcv` consecutive channel broadcasts count as the same sender. Only the
+no-avatar left padding is changed.
+
+## Scope
+
+- Affects: all received consecutive (no-avatar) messages **in channels** — owner
+ broadcasts (`ChannelRcv`) and contributor posts (`GroupRcv`). This includes a
+ channel's member-support sub-scope, which renders through the same
+ `ChatItemsList` with the channel's `isChannel`; treating it the same way is
+ consistent with the merged right-gap change (#7106), which also gates that
+ Row's `end` padding on `isChannel` without a scope filter.
+- Unchanged: the first message of each run (avatar shown), sent messages, regular
+ groups, business chats and direct chats (`isChannel` false — the `else` branch
+ preserves the original avatar-inset value exactly), and any non-channel
+ `ChannelRcv` welcome item.
+
+## Verification
+
+- Android/desktop: `:common:compileKotlinDesktop` compiles clean.
+- iOS: small, type-safe constant change; build/verify on macOS (Xcode) — not
+ compilable on the Linux build host used here.
+- Visual (both platforms), in a channel:
+ - First message of a run (owner or contributor): avatar shown, layout unchanged.
+ - Following messages from the same sender (no avatar): now flush-left.
+ - A different sender / time gap resets the run — the next message shows the
+ avatar again.
+ - Regular groups, business and direct chats keep their existing indentation.
diff --git a/plans/2026-06-22-fix-card-section-stray-dividers.md b/plans/2026-06-22-fix-card-section-stray-dividers.md
new file mode 100644
index 0000000000..72beec92bd
--- /dev/null
+++ b/plans/2026-06-22-fix-card-section-stray-dividers.md
@@ -0,0 +1,40 @@
+# Fix stray card dividers in server info, connect-to-desktop, appearance and migration screens
+
+Branch: `nd/fix-ui-lines` · base: `master`.
+
+## Problem
+
+On several card screens (Android and desktop, current `master`), near-black horizontal lines appear inside section cards where they don't belong — most visible in dark/black themes:
+
+- **Servers info → tap an SMP or XFTP server**: the server-detail card is sliced by stray lines around its nested stats / subscriptions / sessions blocks.
+- **Use from desktop → "Connected to desktop"** (also the connecting / found / verify states): two black lines between the desktop name and its version (e.g. "Desktop" and "v7.0.0.1").
+- **Settings → Appearance** with a custom image wallpaper: a double line with a gap between "Remove image" and "Color mode".
+- **Migrate from this device**, "error stopping chat" state: a double line between the error text and the stop-chat action.
+
+Behaviour is correct everywhere; the bugs are purely visual.
+
+## Cause
+
+PR #6777 (`df5ea3d46`, "android, desktop: new settings section design") wrapped `SectionView`'s content in `CardColumnLayout`, which draws a 2 dp divider (`canvasColorForCurrentTheme()`, near-black in dark/black themes) at the bottom of every direct child except the last. The same PR turned these screens into card screens (`ModalView(cardScreen = true)`) but left three content patterns that pre-date the card chrome, each of which now produces stray lines:
+
+1. **Nested `SectionView`s** inside one outer `SectionView` (server detail) → card-in-card, plus a line around every nested block and spacer.
+2. **Loose `Text` + `Spacer` + `Text`** as separate children of a card `SectionView` (connect-to-desktop name + version) → a line after the text and after the spacer.
+3. **`SectionDividerSpaced()` as a middle child** (Appearance, migration) → on a card screen this is a 30 dp `Spacer`, so it gets a line above *and* below = a double line bracketing a gap.
+
+This is the same bug class as `2026-05-25-fix-e2e-encryption-section-divider.md` (#7012); #6777 reintroduced further instances that earlier fix did not cover.
+
+## Fix
+
+`apps/multiplatform/common/...`, layout-only, matching the reference sibling pattern already used by `DetailedSMPStatsLayout`:
+
+- **`ServersSummaryView.kt`** — `SMPServerSummaryLayout` / `XFTPServerSummaryLayout`: stop wrapping everything in one outer `SectionView`; make the address its own card and each sub-section a top-level sibling separated by `SectionDividerSpaced()` placed *between* them. `SMPSubscriptionsSection`'s rows are wrapped in their own `SectionView` so they keep card chrome.
+- **`ConnectDesktopView.kt`** — wrap each device-name + version block in a single `Column` (4 states), so the card sees one child and draws no internal divider.
+- **`Appearance.kt`** / **`MigrateFromDevice.kt`** — delete the in-card `SectionDividerSpaced()`; the auto-divider between the two now-adjacent rows already separates them (the #6777 precedent for in-card spacers).
+
+## Risk
+
+- Layout-only: no logic, state, side-effect, or click-handler change.
+- iOS is a separate codebase (native grouped lists) and is unaffected.
+- Verified: `:common:compileKotlinDesktop` and the full desktop AppImage build succeed, and the running app renders the screens correctly. Independent adversarial review confirmed every conditional branch and separator is preserved across all stats/subs/sessions combinations.
+- Deliberately out of scope: `SectionTextFooter`-inside-card instances (NetworkAndServers, Migrate*) — these render as a single normal row-separator above an in-card caption, not the stray-line bug; a separate #6777-style cleanup.
+- Rollback: `git revert` the fix commit.
diff --git a/plans/2026-06-22-roster-catchup-subscribers.md b/plans/2026-06-22-roster-catchup-subscribers.md
new file mode 100644
index 0000000000..fd1979cda0
--- /dev/null
+++ b/plans/2026-06-22-roster-catchup-subscribers.md
@@ -0,0 +1,83 @@
+# Roster catch-up for channel subscribers
+
+Continues the public-groups roster work (privileged roster, member keys, `VersionRoster` monotonic gate, task-047's `Maybe VersionRoster` on `XGrpMemRole`/`XGrpMemDel`).
+
+## Problem
+
+A channel subscriber learns the full roster only on join and on resume (`serveRoster`, Subscriber.hs:1174/1269), then tracks it via forwarded `XGrpMemRole`/`XGrpMemDel` deltas, each carrying an incrementing `VersionRoster`. The gate (`applyAtRosterVersion`, Subscriber.hs:3248) accepts any delta at `v >= cur` and advances to `v`.
+
+If the subscriber misses intermediate deltas and then receives one at a version more than one above its known version, it advances to `v` and applies that one change — but the roster changes carried by the skipped versions (other members' roles, removals, keys) are lost until the next resume. The subscriber can then reject a freshly-promoted member's signed action (`RGEMsgBadSignature`) for a key it never learned.
+
+Catch-up: on detecting a gap, the subscriber asks the relay that forwarded the delta to re-serve the full roster, which carries the complete set and keys.
+
+## Design
+
+Four pieces. No schema change, no new store function.
+
+### 1. Owner sends the roster before the delta (the enabler)
+
+Today the owner sends `XGrpMemRole`/`XGrpMemDel` first, then `broadcastRoster` (Commands.hs:2754/2885). The relay forwards the delta to subscribers *before* its own roster-blob transfer completes, so for the whole transfer its stored `roster_blob` lags its `roster_version`. A catch-up request in that window serves a stale blob the subscriber rejects (`notBelowRoster`) — which is the common case, not an edge.
+
+Fix: in `APIMembersRole` / `APIRemoveMembers`, reorder to **apply the change to the owner's members → `broadcastRoster v` → send the delta**. This restructures `changeRoleCurrentMems` / `deleteMemsSend` to separate "apply to owner DB" from "send delta to relays" (the roster is still built after the change, so it reflects the new roles / excludes the removed member).
+
+Effect, relying on FIFO order of the owner→relay connection (a guarantee the roster design already assumes): the relay applies and stores the blob at `v` (`setGroupLiveRoster`) before it processes and forwards the delta at `v`. So a relay's `roster_version` always reflects its stored blob, and any request triggered by a forwarded delta finds a current blob. The now-redundant delta hits the existing no-op suppression (`fromRole == memRole`, Subscriber.hs:3298, added in task-047) and is still forwarded to subscribers — no new relay logic, subscribers still see the delta.
+
+Behavioral change to core delivery (all relays/subscribers) → its own commit. Implementation must confirm FIFO holds owner→relay (the test will expose a violation). Residual: a failed roster send (rare; already `catchAllErrors`) leaves that relay's gate briefly above its blob until the next change — heals on resume.
+
+### 2. New event `XGrpRosterRequest VersionRoster` (Protocol.hs)
+
+A directed subscriber→relay control message carrying the subscriber's pre-gap version, so the relay can skip serving when it holds nothing newer.
+
+```haskell
+XGrpRosterRequest :: VersionRoster -> ChatMsgEvent 'Json
+```
+
+Wire plumbing (standard single-`VersionRoster` `'Json` event): GADT constructor; `CMEventTag` `XGrpRosterRequest_`; `strEncode` `"x.grp.roster.request"`; `strP` case; `toCMEventTag`; `appJsonToCM` (`XGrpRosterRequest <$> p "version"`); `chatToAppMessage` (`o ["version" .= v]`). NOT in `isForwardedGroupMsg` (point-to-point). NOT in `requiresSignature` (subscribers/observers have no key).
+
+### 3. Subscriber detects the gap and requests (Subscriber.hs, `applyAtRosterVersion`)
+
+`applyAtRosterVersion` already reads `cur`, compares `v >= cur`, advances the gate — the one path shared by `xGrpMemRole` and `xGrpMemDel`. In its accepting branch, when the receiver is a subscriber (`not (isUserGrpFwdRelay gInfo)`) and `cur = Just c` with `v > c + 1`, send `XGrpRosterRequest c` to the relay that forwarded the delta, then run the action unchanged (the delta is still applied; the roster heals `c+1 .. v-1`).
+
+To target the forwarding relay, thread it as `Maybe GroupMember` through `xGrpMemRole` / `xGrpMemDel` / `applyAtRosterVersion`: `Just m` on the forwarded path (`m` in scope in `processForwardedMsg`, Subscriber.hs:3804/3806), `Nothing` on the direct path (1092/1096; the receiver there is a relay and never requests). Send via `sendGroupMessage' user gInfo [relay] (XGrpRosterRequest c)`.
+
+One forwarding relay only, not all relays: avoids N² requests under concurrent multi-relay gaps, and the owner-signed roster needs no cross-relay verification. The gate advances to `v` on the first gap in a batch, so later `+1` deltas aren't gaps — normally one request per batch.
+
+### 4. Relay serves on request (Subscriber.hs, `processEvent` + new `xGrpRosterRequest`)
+
+The request arrives on the direct member connection, dispatched in `processEvent` (alongside other direct group events, ~Subscriber.hs:1103):
+
+```haskell
+XGrpRosterRequest reqVer -> Nothing <$ xGrpRosterRequest gInfo' m'' reqVer
+```
+
+```haskell
+xGrpRosterRequest :: GroupInfo -> GroupMember -> VersionRoster -> CM ()
+xGrpRosterRequest gInfo m reqVer =
+ when (isUserGrpFwdRelay gInfo) $ do
+ cur <- withStore' $ \db -> getGroupRosterVersion db gInfo
+ when (maybe True (> reqVer) cur) $ serveRoster user gInfo m
+```
+
+Reuses `serveRoster` unchanged (signed header + inline blob chunks to the one requester — the join/resume path). The version check serves only when the relay holds something newer than the requester, rate-limiting same-version spam. With piece 1, the served blob is current, so the subscriber accepts it (`notBelowRoster`) and `rosterCompletion` heals the skipped set and keys. `serveRoster` is a no-op without a stored roster.
+
+## Files touched
+
+- `src/Simplex/Chat/Library/Commands.hs` — reorder owner sends in `APIMembersRole`/`APIRemoveMembers` (restructure `changeRoleCurrentMems`/`deleteMemsSend`).
+- `src/Simplex/Chat/Protocol.hs` — new event, end to end.
+- `src/Simplex/Chat/Library/Subscriber.hs` — gap detection + request in `applyAtRosterVersion`; thread forwarding relay through `xGrpMemRole`/`xGrpMemDel`; new `xGrpRosterRequest`; one `processEvent` dispatch line.
+- No schema change, no new store fn (reuses `getGroupRosterVersion`, `getGroupRelayMembers`, `getGroupRoster`, `serveRoster`).
+- `tests/ChatTests/` — one channel catch-up test.
+
+## Tests
+
+A `channels` test asserting a subscriber that observes a version gap recovers the skipped set. The hard part is staging a deterministic gap (FIFO forwarding doesn't drop deltas). Candidate: two relays where an intermediate delta reaches only one path, so the subscriber receives a later delta at a jumped version; assert it emits exactly one `XGrpRosterRequest`, the relay re-serves, and a member promoted in the skipped interval is afterwards known (its signed action accepted, no `RGEMsgBadSignature`). Confirm the gap is reliably reproducible before finalizing; fall back to asserting "a forwarded delta at a jumped version triggers one request + re-serve" if the two-relay setup is flaky. Iterate with `-m "channels"`.
+
+## Commits
+
+1. Reorder owner sends (roster before delta) — relay blob is current before it forwards deltas.
+2. Protocol: add `XGrpRosterRequest`.
+3. Relay: `xGrpRosterRequest` + `processEvent` dispatch.
+4. Subscriber: gap detection + request to the forwarding relay.
+5. Test + schema/plan regen.
+
+Build and run `-m "channels"` after each.
diff --git a/plans/2026-06-23-fix-windows-msi-update-running-app.md b/plans/2026-06-23-fix-windows-msi-update-running-app.md
new file mode 100644
index 0000000000..d276dbfe6f
--- /dev/null
+++ b/plans/2026-06-23-fix-windows-msi-update-running-app.md
@@ -0,0 +1,83 @@
+# Fix: Windows desktop fails to launch after in-app MSI update
+
+Issue: https://github.com/simplex-chat/simplex-chat/issues/7105
+
+## Symptom
+
+After updating SimpleX Desktop on Windows via the in-app updater (MSI), the MSI reports
+success but `SimpleX.exe` never launches afterwards — no window, no process in Task Manager,
+and it persists across a reboot. No application crash is logged. Reported on Windows 11
+(6.5.4 → 7.0.0), and the reporter saw it on a prior update too.
+
+Event Viewer shows the cause: RestartManager 10010 (`SimpleX.exe … cannot be restarted -
+Application SID does not match Conductor SID`) followed by MsiInstaller 1038
+(`requires a system restart … Reason for Restart: 1` = files in use).
+
+## Root cause
+
+The Windows branch of `installAppUpdate` (`AppUpdater.kt`) ran the MSI **while the app was
+still running** and waited for it (`Runtime.getRuntime().exec("msiexec /i …").onExit().join()`).
+The desktop MSI is a per-machine major upgrade (`desktop/build.gradle.kts`:
+`perUserInstall = false`, fixed `upgradeUuid`), so it must replace `SimpleX.exe`, the bundled
+JRE and the app DLLs in `C:\Program Files\SimpleX`. The running JVM holds those files open, so
+the installer cannot replace them: Restart Manager can't close the app across the
+user/elevated security boundary (the "SID does not match" event), the locked files are
+deferred to `PendingFileRenameOperations`, and a reboot is requested. At reboot the deferred
+uninstall-then-install operations leave the install directory inconsistent, so the executable
+never starts.
+
+macOS and Linux are unaffected because those kernels allow a running executable's file to be
+replaced by inode; Windows locks open files, so the app must release its locks before the MSI
+replaces them.
+
+## Fix
+
+Launch the installer and **exit the app immediately** instead of waiting, so the files are
+unlocked before the MSI reaches its file-replacement phase (which happens only after UAC
+elevation and the installer's costing phase — well after the JVM is gone). With no running
+instance there are no locked files, no reboot deferral and no Restart Manager conflict.
+
+Two small changes, both confined to the Windows path:
+
+1. `installAppUpdate` Windows branch: replace the `msiexec … .onExit().join()` + result
+ handling with `Runtime.getRuntime().exec(arrayOf("msiexec", "/i", file.absolutePath))`
+ followed by `exitProcess(0)`. The array form also fixes a latent bug where a space in the
+ path broke the single-string `exec`.
+2. `downloadAsset`: before downloading, `if (desktopPlatform.isWindows()) File(tmpDir,
+ asset.name).delete()`. Because the app now exits before it can delete the installer, a
+ leftover MSI is removed at the next download instead of accumulating in the temp dir.
+
+The user reopens the updated app from the Start Menu (the MSI recreates the shortcut) — the
+same hand-off the updater already uses for the `.deb` path and all failure branches.
+
+## Alternatives considered
+
+- **Helper script that waits for exit, installs, then relaunches** — adds a generated batch
+ with PID-polling, relaunch and self-delete; its only benefit over exiting is auto-relaunch,
+ which is not worth the complexity and platform-specific fragility.
+- **Register the app with Restart Manager** so the elevated MSI can close/restart it —
+ jpackage apps don't register RM, the SID mismatch shows RM can't manage the process across
+ the elevation boundary anyway, and it is far more code.
+- **Keep the app running with `REBOOT=ReallySuppress` / repair flags** — does not address the
+ lock; in-use files still defer to a reboot.
+
+## Scope / out of scope
+
+- In scope: the Windows branch of `installAppUpdate` and a Windows-guarded cleanup in
+ `downloadAsset`. macOS, Linux AppImage and `.deb` paths are unchanged.
+- Trade-off accepted: the app no longer shows its own "installed successfully" dialog (it has
+ exited); msiexec shows its own progress UI and the relaunched app is the success signal.
+- Out of scope (separate follow-ups): the macOS install branch ignores `renameTo` results;
+ download failures are only logged with no user-facing error; no signature/SHA verification
+ of the downloaded artifact.
+
+## Test plan (Windows VM)
+
+1. Install a per-machine MSI built at a version below the latest release.
+2. Settings → Check for updates → download + Install the newer MSI.
+3. Before the fix: RestartManager 10010 + MsiInstaller 1038 (Reason 1) appear and the app
+ fails to launch after reboot (reproduces #7105).
+4. After the fix: the app exits, the MSI installs with no reboot request, and the new version
+ launches normally from the Start Menu; `C:\Program Files\SimpleX` is a complete install
+ with no queued `PendingFileRenameOperations`.
+5. Re-run with a user profile path containing a space to confirm the array-form `exec` fix.
diff --git a/plans/2026-06-23-wide-image-crash.md b/plans/2026-06-23-wide-image-crash.md
new file mode 100644
index 0000000000..b409befda2
--- /dev/null
+++ b/plans/2026-06-23-wide-image-crash.md
@@ -0,0 +1,108 @@
+# Fix crash on opening a chat containing an extremely wide image
+
+## Problem
+
+Sending/receiving an image with an extreme aspect ratio (reproduced with a
+**4000×1** image) makes the chat **unopenable**: every render of the chat throws
+
+```
+java.lang.IllegalArgumentException: Can't represent a width of 4660000 and height of 1165 in Constraints
+ at androidx.compose.foundation.layout.AspectRatioNode.measure(AspectRatio.kt:117)
+ ...
+ at chat.simplex.common.views.chat.item.FramedItemViewKt$PriorityLayout$1$1.measure(FramedItemView.kt:482)
+```
+
+Because the exception fires during measurement on every frame, the chat cannot
+be opened again without clearing it. Affects **Android and desktop** (the Compose
+`apps/multiplatform` UI). iOS is unaffected (see below).
+
+## Cause
+
+The framed image preview Box sizes itself with `Modifier.aspectRatio(...)` driven
+by the image's real proportions
+(`apps/multiplatform/.../chat/item/CIImageView.kt`):
+
+```kotlin
+// before
+Modifier.width(w).aspectRatio((previewBitmap.width.toFloat() / previewBitmap.height.toFloat()).coerceAtLeast(1f / 2.33f))
+```
+
+The ratio was clamped only on the **low** side (`coerceAtLeast(1f / 2.33f)`,
+added in #6959 to stop very *tall* previews overflowing the caption). The **high**
+side was left unbounded. For a 4000×1 image the ratio is `4000`.
+
+During Compose's intrinsic-measurement pass, `AspectRatioNode` derives a fixed
+`width = height × ratio`. Compose `Constraints` pack each dimension into at most
+18 bits, so the maximum representable value is **262142 px**. With the observed
+intrinsic height of 1165 px, `1165 × 4000 = 4,660,000` — ~18× over the limit —
+and `Constraints.fixed(...)` throws. Any ratio above roughly `262142 / height`
+(≈ 225 at this height) overflows; tall images never hit this because the existing
+lower bound already caps their ratio.
+
+The bitmap decoders (`Images.android.kt`, `Images.desktop.kt`) only made this
+reachable: they reject pathologically *tall* images
+(`outHeight > outWidth * 256`) and any dimension `> 4320`, but have **no
+symmetric wide guard**, so a 4000×1 image (width 4000 ≤ 4320, not tall) decodes
+and reaches the unbounded `aspectRatio`.
+
+## Fix
+
+An initial fix (already merged) added a symmetric upper bound to the ratio,
+`coerceIn(1f / 2.33f, 2.33f)`. That stops the crash but reshapes every image
+wider than 2.33:1 — including legitimate panoramas — to 2.33:1. This change
+**supersedes** it: stop routing the box height through `aspectRatio` and compute
+it **directly**, so the dangerous `width = height × ratio` derivation never
+happens. The wide side is then left at its **natural ratio** (no upper clamp);
+only the tall side is capped at `2.33`, exactly as before. This mirrors what the
+iOS app already does (`height = w × heightRatio`, `heightRatio = min(h / w, 2.33)`):
+
+```kotlin
+// before (merged interim fix)
+Modifier.width(w).aspectRatio((previewBitmap.width.toFloat() / previewBitmap.height.toFloat()).coerceIn(1f / 2.33f, 2.33f))
+// after
+Modifier.width(w).height(w * (previewBitmap.height.toFloat() / previewBitmap.width.toFloat()).coerceAtMost(2.33f))
+```
+
+With this form the box width is pinned (`≤ DEFAULT_MAX_IMAGE_WIDTH = 500.dp`) and
+the height is `w × min(h / w, 2.33)`, which is always in `(0, w × 2.33]` — at most
+`≈ 1165.dp`. Both dimensions are therefore always far inside the 262142 px
+`Constraints` limit **at any aspect ratio and any screen density**, so the crash
+is structurally impossible rather than merely bounded. A very wide image renders
+at its true proportions (a thin strip) instead of being reshaped to 2.33:1.
+
+This does not disturb the framed item's text-width adaptation: that uses
+`.width(IntrinsicSize.Max)` (`FramedItemView.kt`), which reads the image box's
+intrinsic **width** — still pinned to `w` — so only the wide side's height
+derivation changes.
+
+## Why compute height directly (vs clamping the ratio)
+
+The earlier candidate fix clamped the ratio (`coerceIn(1f / 2.33f, 2.33f)`). That
+is safe, but it reshapes every image wider than 2.33:1 — including legitimate
+panoramas — to 2.33:1, because `ContentScale.FillWidth` cannot fill the
+over-tall box and the image letterboxes. Computing the height directly removes
+the overflow-prone code path entirely *and* preserves the natural shape of wide
+images, so there is no display trade-off to accept. It also makes the Compose and
+iOS image-sizing logic parallel.
+
+## Scope / non-goals
+
+- Only the `!smallView` framed Box derived its size from the image ratio; it now
+ computes height directly. The chat-list `smallView` preview is locked to a fixed
+ `36.sp` square, and all other image/video/link paths size with `.width(...)` +
+ `ContentScale` (no `aspectRatio`), so none of them can hit this overflow.
+- One follow-up was identified but intentionally left out to keep the diff
+ minimal: a **symmetric wide guard** in the bitmap decoders
+ (`outWidth > outHeight * 256`, mirroring the existing tall guard in
+ `Images.android.kt` / `Images.desktop.kt`) for defense-in-depth, so any future
+ consumer rendering a decoded bitmap is protected at the source.
+
+## iOS
+
+iOS is **not** affected by the crash, and the fix above brings the two platforms
+into alignment. iOS already sizes the preview by computing the height directly —
+`height = w × heightRatio`, `heightRatio = min(size.height / size.width, 2.33)`
+(`apps/ios/SimpleXChat/ImageUtils.swift`) — which is exactly the form now used on
+Android/desktop. (Even before, SwiftUI lays out with `CGFloat` frames and has no
+`Constraints` packing limit, so a 4000×1 image yielded a valid sub-pixel-height
+frame rather than throwing.) No iOS change is required.
diff --git a/plans/2026-06-25-name-resolution.md b/plans/2026-06-25-name-resolution.md
new file mode 100644
index 0000000000..737de7fe99
--- /dev/null
+++ b/plans/2026-06-25-name-resolution.md
@@ -0,0 +1,506 @@
+# SimpleX names — simplification plan
+
+Status: design agreed while reviewing branch `sh/namespace`. This supersedes the
+name handling currently on that branch. Line refs are to the working tree at
+review time; re-check before editing.
+
+## 1. Goal
+
+Reduce the feature to the minimum coherent, secure shape:
+
+- **One** name per entity, on the **profile** (the entity's claimed identity),
+ typed `Maybe SimplexNameInfo`. No second "locally-known" copy on the entity row.
+- A local **verification status** as a 3-state `Maybe Bool` (not a timestamp):
+ not-attempted / failed / verified. A failed check never blocks connecting.
+- Connect-by-name requires the entity to claim the name, and the result is created as verified.
+- The **proof** (address-key signature, context-bound) is **in scope for link
+ contexts** — connect-by-name, 1-time invitations, contact addresses, channel
+ join links — so those names are verifiable in this release. Only a name with
+ **no link context** (a group member, or a name on an `XInfo` profile over an
+ established connection) is deferred: stored, but not shown until that gap closes.
+
+Removed from the current branch: the `*.simplex_name` entity columns (the
+"locally-known/ct" copy), the `connections.simplex_name` carrier, the four
+partial UNIQUE indexes + "newer-claim-wins" clearing, and the `_verified_at`
+timestamps.
+
+## 2. Why (trust model)
+
+A name resolves to a link via the agent (`resolveSimplexName`); a `NameRecord`
+has **lists** of links (`nrSimplexContact`, `nrSimplexChannel`), so
+verification matches against **any** of them. "Match any" is safe **only because
+the namespace is an on-chain, ENS-style registry**: `nrOwner`/`nrResolver` are
+Ethereum addresses (`Names/Record.hs:22-23,36`), so each name has a **single
+owner** who sets all its links. An attacker can register *their* name → your
+address (the offensive-name case, handled by the claim check below) but **cannot
+add a link to your name** — on-chain ownership blocks impersonation. Everything
+here depends on that; if names were not single-owner, "match any" would be exploitable.
+
+The registrant of a name controls what it points to, with no proof that the
+target address agreed to it — anyone can publish `@offensive → your address` or
+`#offensive → your channel`. Therefore:
+
+- One-directional verification ("does `resolve(name)` equal a stored link") is
+ insufficient: it confirms the registrant's assertion, not the address owner's.
+- A profile **claiming** a name (and even a link) proves nothing — anyone can
+ copy a link into a profile. **Control of a link is proven only by an actual
+ connection/join through it.**
+- Sound verification is the intersection: `resolve(name) → link`, **and** the
+ entity advertises that name in its profile (it claims the name), **and** that link is one
+ we connected/joined through (control-proven).
+- Verifying a name without having connected through its link needs a **signature
+ by the address key over the name, bound to the presentation context** (§4.8).
+ This is **in scope** for link contexts: a 1-time invitation includes such a proof
+ bound to the invite, so resolving the name → address → address key verifies it.
+
+Consequence: names are verifiable in this release for **channels** (join link),
+**contacts connected via their address/name** (the link connected through), and
+**1-time-invite contacts** (the in-scope address-key proof). The only case still
+deferred is a name with **no link context at all** — a group member, or a name on
+an `XInfo` profile over an established connection — which stays stored-but-not-shown.
+
+## 3. Current branch state (to be changed)
+
+Migration `M20260603_simplex_name` currently adds, on both SQLite and Postgres:
+
+- `contacts.simplex_name`, `contacts.simplex_name_verified_at`
+- `groups.simplex_name`, `groups.simplex_name_verified_at`
+- `connections.simplex_name`
+- `contact_profiles.simplex_name`, `group_profiles.simplex_name`
+- UNIQUE indexes `idx_contacts_simplex_name`, `idx_groups_simplex_name`,
+ `idx_contact_profiles_simplex_name`, `idx_group_profiles_simplex_name`
+- `server_operators.smp_role_names` (= 1 for `'simplex'`)
+
+…and threads two names per entity through the types: `Contact.simplexName` /
+`GroupInfo.simplexName` (from `*.simplex_name`, "locally known"), and
+`LocalProfile.simplexName` (from `*_profiles.simplex_name`, "peer claim"), plus
+a `verified_at` timestamp on the entity. `apiVerifySimplexName` verifies the
+entity (ct) name against the **profile's self-asserted `contactLink`** for
+contacts (wrong link), and against `preparedGroup.connLinkToConnect` for groups
+(correct). The `connections.simplex_name` carrier is plumbed through
+`createConnection_` but **never written** (all callers pass `Nothing`).
+
+## 4. Target design
+
+### 4.1 Name type and JSON encoding
+
+The name type is **`SimplexNameInfo`** (simplexmq `Simplex/Messaging/SimplexName.hs:37`),
+which has:
+
+- `StrEncoding` (`SimplexName.hs:89`) — canonical `simplex:/name@…` / `#…` string,
+- a text `ToField` (`SimplexName.hs:146`) — stores as TEXT,
+- a JSON **object** instance: `$(J.deriveJSON defaultJSON ''SimplexNameInfo)`
+ (`SimplexName.hs:154`) → `{nameType, nameDomain}`.
+
+**Keep the object JSON** — the UI/API needs the structured form (it reads the name
+off `LocalProfile`, `CRSimplexNameVerified`, …). The conflict is only on the
+**wire**: `PublicGroupAccess.groupDomain` is a **released** field typed
+`Maybe Text` (a JSON string), so the wire form of the name must stay a string.
+
+Resolve by wrapping **only the wire fields** with simplexmq's generic newtype
+`StrJSON` (`Simplex/Messaging/Encoding/String.hs:265`), whose `ToJSON`/`FromJSON`
+go through `StrEncoding` → a JSON string (`String.hs:267–272`; idiom
+`deriving (ToJSON, FromJSON) via (StrJSON "X" T)`):
+
+- wire (`Profile`, `GroupProfile`/`PublicGroupAccess`):
+ `Maybe (StrJSON "SimplexName" SimplexNameInfo)` → JSON **string**, byte-identical
+ on the wire to the released `Maybe Text`.
+- local/UI (`LocalProfile`): `Maybe SimplexNameInfo`, **unwrapped** → JSON **object**.
+
+Wrap/unwrap at the `Profile` ⇄ `LocalProfile` boundary (`toLocalProfile` /
+`fromLocalProfile`). `SimplexNameInfo`'s own JSON instance is untouched, so
+`CRSimplexNameVerified` and any other UI-facing use stay object.
+
+Inherent asymmetry: there is no `LocalGroupProfile`, so the channel name reaches
+the UI as a **string** (via `GroupProfile`, which is `StrJSON`), while the contact
+name reaches it as an **object** (via `LocalProfile`). If the UI needs the channel
+name as an object too, add a decoded field on `GroupInfo` (follow-up). The bot-API
+binding generator must render `StrJSON`-wrapped fields as `string`.
+
+DB stays TEXT: `ToField` (`SimplexName.hs:146`) on write; on read a **hard**
+`FromField SimplexNameInfo` (add it — `SimplexName.hs:141-145` says to define it
+"when a consumer requires the row-fail behaviour"), so an invalid stored name fails the
+row — matching the wire, where a name that won't `strDecode` fails the profile. **No
+soft-decode** (`decodeSimplexName` dropped for the name columns).
+
+### 4.2 Types (field changes)
+
+- `Profile.contactDomain :: Maybe (StrJSON "SimplexName" SimplexNameInfo)` — NEW;
+ JSON string (§4.1). The entity's advertised contact name. (Replaces the branch's
+ `Profile.simplexName`.)
+- `Profile.contactDomainProof :: Maybe ClaimProof` — NEW; a flat sibling of
+ `contactDomain`/`contactLink`, a **wire profile field like `Profile.badge`**. The
+ **stored** own profile (`contact_profiles`) has the name but **no proof**; the
+ proof is generated and **added to the outgoing profile at send/save** (§4.8), exactly
+ as the badge is. `PHSimplexLink` (verifiable) when the profile is saved to a contact
+ address / 1-time invite; `PHTest` over an established connection (the gap).
+- `LocalProfile.contactDomain :: Maybe SimplexNameInfo` (unwrapped → object JSON)
+ and `LocalProfile.contactDomainVerification :: Maybe Bool` — local status, **not**
+ on wire `Profile`. `toLocalProfile` unwraps the `StrJSON`; `fromLocalProfile`
+ re-wraps `contactDomain` and drops the status (mirrors how `localBadge`'s status
+ is dropped).
+- `PublicGroupAccess.groupDomain :: Maybe (StrJSON "SimplexName" SimplexNameInfo)`
+ — RETYPE from `Maybe Text` (`Types.hs:857`); JSON string, wire-identical to the
+ released text (§4.1). Owner-set, broadcast in `XGrpInfo`. **Only public, relay-backed
+ groups** (`groups.use_relays`) can have a name — they have a channel join link to
+ resolve to and an owner key (`groups.member_priv_key`, `chat_schema.sql:193`) to sign
+ with; p2p groups have neither. (`contactDomain` on a member is a contact attribute, unaffected.)
+- `GroupInfo.groupDomainVerification :: Maybe Bool` — local status, read from the
+ `groups` table (there is no `LocalGroupProfile`, and `GroupProfile` is the wire
+ type, so the status cannot be sent with the profile).
+- DROP `Contact.simplexName`, `GroupInfo.simplexName`, `Connection.simplexName`,
+ and both `*VerifiedAt` timestamps.
+
+Asymmetry, intentional: contact name + status both live on `contact_profiles`
+(exposed via `LocalProfile`); the group name lives on `group_profiles`
+(exposed via `GroupProfile`/`PublicGroupAccess`) but its status lives on
+`groups` (exposed via `GroupInfo`). This is forced — `group_profiles` is the
+shared wire profile with no local columns, while `contact_profiles` already
+holds local state (`local_alias`).
+
+### 4.3 Schema — rewrite `M20260603_simplex_name` (branch unreleased)
+
+Add:
+- `contact_profiles`: `contact_domain TEXT`, `contact_domain_verification`
+ (nullable `INTEGER` SQLite / `SMALLINT` Postgres).
+- `groups`: `group_domain_verification` (nullable `INTEGER`/`SMALLINT`).
+- `server_operators.smp_role_names` (= 1 for `'simplex'`) — keep.
+- `user_contact_links`: the contact-address **root signing key** (BLOB, mirroring
+ `groups.root_priv_key`) — captured from the 2-step short-link creation — so the
+ contact-address / 1-time-invite proof can be signed chat-side. (Not present today.)
+
+No DB change for `group_profiles.group_domain` — it already exists (from
+`M20260515_public_group_access`); only the Haskell type and JSON change.
+
+Remove (vs the current branch migration): `contacts.simplex_name`,
+`contacts.simplex_name_verified_at`, `groups.simplex_name`,
+`groups.simplex_name_verified_at`, `connections.simplex_name`,
+`contact_profiles.simplex_name`, `group_profiles.simplex_name`, and all four
+UNIQUE indexes. No name uniqueness is enforced at the DB level — identity comes
+from verification, not a constraint.
+
+Verification column decode: `Maybe BoolInt → Maybe Bool` (`NULL` = not attempted,
+`0` = failed, `1` = verified).
+
+### 4.4 Storage functions (`Store/Shared.hs`, `Store/Direct.hs`, `Store/Groups.hs`)
+
+- Read the name columns as `Maybe SimplexNameInfo` via the **hard** `FromField`
+ (§4.1) — an invalid name fails the row; no soft `decodeSimplexName`.
+- `toContact` / `toGroupInfo`: read `contact_domain` → `LocalProfile.contactDomain`
+ and `contact_domain_verification` → `LocalProfile.contactDomainVerification`;
+ `group_profiles.group_domain` → `PublicGroupAccess.groupDomain` and
+ `groups.group_domain_verification` → `GroupInfo.groupDomainVerification`. Delete
+ the ct/cp split and the entity-`simplex_name` reads.
+- `createContact_` / `createGroup_` / `createPreparedContact` / `createPreparedGroup`:
+ set the name on the **profile** columns only; drop the entity-`simplex_name`
+ argument and the `connections.simplex_name` carrier param on `createConnection_`.
+- `updateContactProfile` / `updateGroupProfile`: write `contact_domain` /
+ `group_domain` from the received profile. Reset the verification to `NULL`
+ (not-attempted) **only when the name changes**; an XInfo/XGrpInfo with the
+ **same** name keeps the existing status (a verified name stays verified), exactly as
+ a badge does. No conflict clearing (no UNIQUE index).
+- `getContactBySimplexName` / `getGroupIdBySimplexName`: look up by the **verified**
+ profile name (the name column joined with verification = `Just True`); on a miss
+ or unverified, fall through to resolve-and-connect. Consistent with the existing
+ by-address lookup `getContactViaShortLinkToConnect` (`Direct.hs:963`), which
+ matches the link with no verification check — a link is the identity, a name is a
+ claim that only becomes a usable pointer once verified.
+
+### 4.5 Redaction (`Library/Internal.hs:1246`)
+
+```haskell
+redactedMemberProfile :: GroupInfo -> GroupMember -> Profile -> Profile
+redactedMemberProfile g m Profile {…, contactLink, contactDomain} =
+ let allowDirect = groupFeatureMemberAllowed SGFDirectMessages m g
+ allowSimplexLinks = groupFeatureMemberAllowed SGFSimplexLinks m g && allowDirect
+ in Profile { …
+ , shortDescr = removeSimplexLink =<< shortDescr -- via allowSimplexLinks
+ , contactLink = if allowSimplexLinks then contactLink else Nothing
+ , contactDomain = if allowDirect then contactDomain else Nothing
+ , contactDomainProof = Nothing } -- member profiles are contextless; never include a proof
+```
+
+- `allowDirect` is the single primitive (the `DirectMessages` permission); it
+ controls the name and is reused inside `allowSimplexLinks`. No `allowName` flag,
+ no second lookup.
+- **Behavior changes vs current:** `contactLink` flips from unconditionally
+ dropped to controlled by `allowSimplexLinks` (a member's contact address becomes
+ visible whenever links+DMs are allowed — the meaning of "links allowed"); the
+ name follows the looser `allowDirect`. Rationale: a link is one-tap-to-connect
+ (low friction), a name only resolves if the recipient deliberately looks it up
+ (higher friction), so a group can forbid links yet allow name discovery, with
+ "DMs allowed" the floor for both.
+- Signature takes `(GroupInfo, GroupMember)` and derives both flags inside, so
+ the rule lives in one place. Callers pass `(g, m)`; the own-profile path passes
+ `(g, membership g)` — behavior-preserving because
+ `groupFeatureUserAllowed f g ≡ groupFeatureMemberAllowed f (membership g) g`
+ (both reduce to `groupFeatureMemberAllowed' f (memberRole (membership g))
+ (fullGroupPreferences g)`, `Types.hs:646–652`).
+- Collapses `groupUserAllowSimplexLinks` (`Types.hs:656`) and the pre-computed
+ `allowSimplexLinks` wiring at the call sites (`Internal.hs:1244`,
+ `Subscriber.hs:842,2817,3239`, `Commands.hs:3748,4057`). `Commands.hs:3748`
+ has `Maybe GroupInfo` → "no group ⇒ no redaction" at the call site.
+
+### 4.6 Resolution + verification (`Library/Commands.hs`)
+
+Two cases that differ in whether verification can *fail*:
+
+**Connect-by-name** (`connectPlanName` / `dispatchResolvedRecord`) — verification is
+a **precondition** of connecting. After decoding the resolved short link's embedded
+profile, **add the claim check**: require that profile's `contactDomain` /
+`groupDomain` to equal the resolved name, else fail with `CESimplexNameNotFound`
+("name unknown") and **do not connect**. (The current branch decodes the profile but
+never compares the name — this is the missing check.) On success the prepared
+contact/group is created with the name on the profile, `connLinkToConnect` = the
+resolved link, verification = `Just True` (**created as verified**). There is no "failed"
+outcome here — failing to resolve or to claim the name just means no connection.
+
+**Connected NOT by name** (via an address link or a 1-time link) — the peer's profile
+may *claim* a name; it starts **unverified** (`Nothing`). Verification is **post-hoc
+and non-blocking**: keep `apiVerifySimplexName` (`/_verify simplex name`).
+ - **Contacts** verify by a **single path** — check `contactDomainProof` (§4.8):
+ resolve the claimed name → its link, validate the owner chain and **select the key by
+ the proof's `linkOwnerId`** (that owner's `ownerKey`, or the root key if `Nothing` —
+ the usual contact-address case), check the `ClaimProof` signature over
+ `name <> presHeader`, and check the proof's `presHeader` link ==
+ `preparedContact.connLinkToConnect` (**not** `profile.contactLink` — the branch bug).
+ Contact addresses and 1-time invites both include the proof.
+ - **Channels** verify by **presence / link-match**: `resolve(#name)` includes
+ `preparedGroup.connLinkToConnect` (the join link), whose owner-signed data already
+ has `groupDomain` (no `ClaimProof` — §4.8).
+ Result is `Just True` (holds) or `Just False` (fails) — and **`Just False` must NOT
+ prevent the connection**, exactly as a failed *badge* verification doesn't. **This is
+ why the status must be 3-state** (`Nothing` not attempted / `Just False` failed /
+ `Just True` verified). Names that stay `Nothing` have **no proof/link context** —
+ group members, and names on an `XInfo` profile over an established connection.
+
+Open option: **auto-verify on connect** (run the same non-blocking check
+automatically when connecting via address/1-time link), instead of only on demand.
+Either way the status stays 3-state — auto-verification can fail without blocking.
+
+Keep the pure helpers `firstNameLink` (per-type link pick, cross-type rejection) and
+`linksMatch` (scheme-normalized compare).
+
+### 4.7 Display (`View.hs`)
+
+A name is shown **when there is a proof to verify**, together with its status —
+verified, failed, or not-yet-verified. All three states are shown (a failed or
+pending check still shows the name, flagged), so the user sees the name and its
+trust level rather than a silent omission. Rendering those three states is **out of
+scope for this PR** (UI work), but the core stores the data — the 3-state status and
+the proof — to drive it. A name with **no proof to verify** — a group member, or a
+name on an `XInfo` profile over an established connection — is **not shown**.
+
+### 4.8 Proof — a flat profile field, signed by the address key, context-bound
+
+A name resolves to a **contact address** (the persistent identity link). The proof
+asserts "the owner of that address asserts this name", so it is **signed by the
+address's key** (the resolved address's own key) — **not** by the
+per-connection or 1-time-link key. Every proof is **tied to the link it's shown
+through**, so a proof made for one link can't be reused on another; these are
+distinct proofs. Store the link in a presentation header:
+**rename `BadgePresHeader` (`Badges.hs:212`) → `ProofPresHeader`** (now shared by
+badge and name proofs) and add a **`PHSimplexLink AConnShortLink`** constructor.
+`AConnShortLink` (`Agent.Protocol.hs:1536`,
+`forall m. ConnectionModeI m => ACSL (SConnectionMode m) (ConnShortLink m)`) is the
+existing existential, so the context is either a 1-time invitation or a contact
+address. The signed payload includes this header, and the **verifier compares the
+header's link against the link the proof is presented through** (the current
+invite/address) — that comparison is what makes a proof non-replayable across
+links. The tag enum (`Badges.hs:200`), the `StrEncoding` (`:216`), and
+`badgePresHeaderAccepted` (`:226`, → `proofPresHeaderAccepted`) each gain the new
+variant.
+
+**Type & wire** — a JSON object like `BadgeProof` (`Badges.hs:393`):
+
+ data ClaimProof = ClaimProof
+ { linkOwnerId :: Maybe OwnerId, -- which owner signed; Nothing = root key (see below)
+ presHeader :: ProofPresHeader, -- context: PHSimplexLink | PHTest
+ signature :: C.Signature 'C.Ed25519 -- by that owner's key, over: smpEncode name <> smpEncode presHeader
+ }
+
+The signature is by the key of the signer's **owner identity** in the link's owner
+chain (`OwnerAuth`, `Agent/Protocol.hs:1829`); `ClaimProof` has
+**`linkOwnerId :: Maybe OwnerId`** (`OwnerId`, `:1827`) to name it, so the verifier
+checks exactly that key (no iterating the owner list):
+
+- **Channels** (which can have owners other than the address) sign with the user's **owner key**,
+ `linkOwnerId = Just oid` — **not** the root key — `groups.member_priv_key`
+ (`chat_schema.sql:193`).
+- A **contact address** has a single owner = its creator, so it signs with the **root
+ key**, `linkOwnerId = Nothing`.
+
+The root key (`ShortLinkCreds.linkPrivSigKey`/`linkRootSigKey`, `:1482-83`) otherwise
+only *authorizes* owners (`validateOwners`/`validateLinkOwners`, `:1846–1859`);
+`Nothing` (root) is **allowed at validation**. Both keys live **chat-side** so signing
+is in the chat layer — **but only channels store theirs today** (`groups`); a contact
+address (`user_contact_links`, `:386`) has **no key column**, so we must add one
+(mirroring `groups.root_priv_key`), captured from the 2-step short-link creation, to
+sign the contact-address / 1-time-invite proofs. Signed payload =
+`smpEncode name <> smpEncode presHeader` (`name` from the profile's `contactDomain`).
+`presHeader` serialises as its `StrEncoding` string, `signature` base64url.
+
+Per presentation context:
+
+- **Contact address** (the name's own resolved link): presence in the address link's
+ owner-signed data already proves the name — but we **include the explicit `ClaimProof`
+ here too** (bound to the address) so contact verification is
+ one uniform path (always check the proof) rather than presence-for-addresses /
+ proof-for-invites. The address can also serve as the **badge** proof's context.
+- **1-time invitation**: include a proof **signed by the address key, bound to the
+ 1-time link** as context. Feasible **now** — the 1-time link is a unique,
+ single-use context; no general mechanism required. This is what makes
+ a 1-time-invite contact verifiable.
+- **`XInfo` over an established connection**: no link context → the step that adds the proof sets
+ `PHTest` (unbound) → unverifiable → not shown. Left for later, same as the badge's
+ `PHTest`. (For **group members** the proof is dropped entirely by redaction, §4.5.)
+
+Home: **inside the profile** — `Profile.contactDomainProof :: Maybe ClaimProof`, a flat
+sibling of `contactDomain`/`contactLink`, exactly like `Profile.badge`. It is **not**
+stored on the own profile; like the badge, it is **generated fresh and added to the
+outgoing profile at send/save** — when the profile is sent to a peer (`XInfo`) or saved
+to a link — by signing `name <> presHeader` with the address root key and setting the
+**destination as the `presHeader` context**. Because `presentUserBadge`
+(`Internal.hs:2037`) already adds the badge proof to the outgoing profile at *both*
+peer-sends and link-data writes, the name-proof step belongs in the **same
+function**. The context decides whether a proof is useful: saving to a contact address /
+1-time invite sets `PHSimplexLink(that link)` (verifiable — the in-scope cases); an
+established-connection peer-send sets `PHTest` (unbound — left for later, same as the
+badge). The receiver verifies and stores the 3-state status on
+`LocalProfile.contactDomainVerification`, as `localBadge` holds the badge status.
+Connect-by-name is **created as verified**.
+
+**Scope:** the **useful** (`PHSimplexLink`) proofs — set when the profile is saved to
+a contact address or 1-time invite — are in this change; the verifier resolves the name →
+address → address key → checks the signature and the `presHeader` link. Channels use
+presence (below). The contextless established-connection case (a `PHTest` name proof) and
+group members are left for later.
+
+Badges stay **in the profile** — person-scoped, presented per connection
+(`presentUserBadge`, `Internal.hs:2037`), including over established connections via
+`XInfo`. They share the presentation-header context type with name proofs but sign
+with the **badge credential key**, not the address key. Two scopes, two homes.
+
+The shared step sets **both** proof kinds the same way: `PHSimplexLink(link)`
+when the destination is a link (contact address, 1-time invite — verifiable), `PHTest`
+over an established connection (unbound — the gap). So name proofs and badges both use
+`PHTest` only for the contextless established-connection case.
+
+No group proof field: a channel is always joined via its **join link** (its own
+address), whose owner-signed data already has `groupDomain`, and there is no
+"advertised link ≠ resolved address" case for channels — so channels verify by
+presence/link-match and need no `ClaimProof`. (If full symmetry is wanted later, add
+`GroupProfile.groupDomainProof` the same way.)
+
+### 4.9 Set-name API (in scope — currently missing)
+
+Names are **pre-registered out of band** — the app does **not** call RNAME. The API
+only **verifies** the name and **adds it to the profile**. The user must be able to
+add/change/remove their own name from the UI; the branch has no command for the
+**contact** name.
+
+- **Contact name** — add `APISetUserName :: Maybe SimplexNameInfo -> ChatCommand`
+ (`Nothing` clears). On set:
+ 1. Require an **address** — fail if none (the UI won't offer the action without one).
+ 2. Require it to be a **short link** — if only a long link exists, create the short
+ link (the name resolves to a short link, and the check below is short-link-based).
+ 3. Ensure that short link is **in the profile** (`contactLink`) — add it if missing.
+ 4. **Verify**: resolve the name and compare the short link it points to against the
+ profile's `contactLink`; fail if they don't match (name not preregistered to this
+ address).
+ 5. Set `LocalProfile.contactDomain` and **re-publish the contact-address link data**.
+ The `ClaimProof` is added when the profile is saved to that link (the send/save
+ proof-adding step, §4.8) — **not** produced by the API itself. (Steps 1–4 are the verify;
+ this step is set + re-publish.)
+ Needs a `ChatCommand` constructor + parser + handler.
+- **Channel name** (public, relay-backed groups only) — a **separate**
+ `APISetPublicGroupName`, parallel to the contact one (not folded into
+ `SetPublicGroupAccess`): same require-address / require-short-link
+ / link-in-profile / verify / set-`groupDomain` flow against the channel's **join
+ link**. Rationale: it mirrors the contact API, and the name's fail-able verify +
+ preconditions don't mix cleanly with the plain `web=`/`embed=`/`domain_page=` writes.
+ **Drop `domain=` from `SetPublicGroupAccess`** (`Commands.hs:5461`) so there's a single
+ verified path; factor out the shared `GroupProfile`-update + `XGrpInfo` broadcast so
+ both commands reuse it. Verify is **TLD-dependent**: resolve+compare for `TLDSimplex`,
+ a different/no check for `TLDWeb` (web domains don't resolve through the namespace).
+- The own name has **no stored verification status** — the verify step checks it at
+ add time; the 3-state status is only for peers' names. No RNAME wiring (out of scope).
+
+## 5. Removal checklist (from the current branch)
+
+- `Contact.simplexName`, `GroupInfo.simplexName`, `Connection.simplexName`.
+- `*VerifiedAt` timestamps (→ `Maybe Bool` status fields).
+- `connections.simplex_name` column + the `createConnection_` carrier param + the
+ `XInfo` carrier consumption in `Subscriber.hs`.
+- `contacts.simplex_name`, `groups.simplex_name` columns.
+- The four partial UNIQUE indexes + `clearConflictingContactProfileSimplexName_`
+ / `clearConflictingGroupProfileSimplexName_` + their call sites.
+- `getContactBySimplexName` / `getGroupIdBySimplexName` against entity columns
+ (re-point or remove per 6.b).
+
+## 6. Resolved decisions
+
+a. **Wire-string encoding (§4.1):** `SimplexNameInfo` keeps object JSON; wire
+ fields are wrapped in `StrJSON` (string), `LocalProfile` stays unwrapped
+ (object). Channel name reaches the UI as a **string** (via `GroupProfile`) and
+ that is fine — no decoded-object field on `GroupInfo` (no reason to re-connect
+ to a channel you're in; channel names are only shown verified). The object form
+ matters for **contacts** (connect-from-groups, sharing), which `LocalProfile`
+ provides. Residual chore: teach the bot-API binding generator to emit `string`
+ for `StrJSON` fields and pick the `StrJSON` `name` Symbol.
+b. **Lookup (§4.4):** re-point `getContactBySimplexName` (its one caller is
+ connect-by-name, `Commands.hs:4241`) to the **verified** `contact_profiles.
+ contact_domain`; miss/unverified ⇒ resolve-and-connect. Keeps the no-network
+ shortcut for already-known contacts. (`getGroupIdBySimplexName` has no external
+ caller — drop it.)
+c. **Proof (§4.8):** a flat **`Profile.contactDomainProof :: Maybe ClaimProof`**, a wire
+ profile field like `Profile.badge`. Not stored on the own profile; **generated fresh and
+ added to the outgoing profile at send/save** (peer `XInfo` or save-to-link) by the
+ **same function** as the badge (`presentUserBadge`, which already runs at
+ peer-sends *and* link-data writes). Signed by the signer's **owner-identity key** — a
+ channel's **owner key** (`groups.member_priv_key`, `linkOwnerId = Just oid`)
+ or a contact address's **root key** (sole owner, `linkOwnerId = Nothing`) — over
+ `name <> presHeader`; `linkOwnerId` selects the verification key (`Nothing` = root,
+ allowed at validation). `PHSimplexLink` for address/invite saves, `PHTest` over
+ established connections (the gap). Verify checks the signature **and `presHeader`'s link
+ == the link actually used** (`connLinkToConnect`). Channels use presence (owner-signed
+ link data). **Gap:** the contact-address key isn't stored chat-side today
+ (`user_contact_links` has no key column) — add one to sign chat-side. Receiver status
+ on `LocalProfile.contactDomainVerification`.
+d. **`redactedMemberProfile` contactLink exposure (§4.5):** intended — a member's
+ contact address becomes group-visible when links + DMs are allowed.
+e. **Verify command + status (§4.6):** keep `apiVerifySimplexName` — required to
+ verify a claimed name for entities connected **not** by name (address / 1-time
+ link). Status is **3-state** because a failed name (or badge) verification must
+ **not** block the connection; connect-by-name is the only created-as-verified path
+ (and there a failure to resolve or to claim the name means no connection, not a failed state).
+ **Auto-verify on connect** (vs. on-demand only) is left open; it doesn't change
+ the 3-state requirement.
+
+## 7. Rollout & scope
+
+The **claim check** (§4.6) — a name resolves only if the **resolved link's own
+data claims it** — is the anti-stray-names protection and **must ship regardless**:
+a name someone registers against a real address must not "work" without that
+address owner's agreement. It needs no signature (the address-case presence suffices),
+so it lands with the core change.
+
+The signed proof (§4.8) can ship in the **same** release (add + verify together) or
+be **staged** — implemented at the core level with the user-facing name-addition
+hidden in the UI until ready. Either way it stays a *core* change.
+
+The `ProofPresHeader` rename + `PHSimplexLink` + letting badges opt into the link
+context ripples through the badge code — accepted, and bounded:
+
+- `Badges.hs`: `BadgePresHeader` → `ProofPresHeader`, `BadgePresHeaderTag` →
+ `ProofPresHeaderTag`, `badgePresHeaderAccepted` → `proofPresHeaderAccepted`
+ (`:200, :212, :216, :226`); add the `PHSimplexLink AConnShortLink`
+ tag/constructor/`StrEncoding`/accepted-case; `badgeProof` (`:314`) takes the
+ renamed type.
+- `presentUserBadge` (`Internal.hs:2037`) + its ~15 call sites — the **shared point that adds
+ proofs to the outgoing profile** (already runs at peer-sends *and* link-data writes): generalize it
+ to set **both** the badge proof and the name `ClaimProof` onto the outgoing profile,
+ using `PHSimplexLink link` where the destination is a link, `PHTest` otherwise.
+
+The pure rename can land as a **standalone prep commit** ahead of the proof; the
+`PHSimplexLink` wiring + name proof land with the proof work.
diff --git a/plans/2026-06-27-namespace-ui-display-set.md b/plans/2026-06-27-namespace-ui-display-set.md
new file mode 100644
index 0000000000..1f01cc4311
--- /dev/null
+++ b/plans/2026-06-27-namespace-ui-display-set.md
@@ -0,0 +1,243 @@
+# SimpleX name UI: display + verify + set (iOS + Android/desktop)
+
+Branch: `sh/namespace-ui` (rebased onto core `fc0582cf0` — the finalized verify API). This pass adds
+displaying a contact's / channel's SimpleX name with verification state, verifying names (manual + auto),
+and two screens for setting the user's own name and a channel's name.
+
+**Upstream sync (2026-06-27):** core `sh/namespace` is at `5008b4e62` ("refactor setting user name" +
+test/comment cleanup, on top of the verify-API split `fc0582cf0`). UI branch rebased onto it (backup tag
+`backup-namespace-ui-pre-rebase5`); pure-frontend, rebase clean. All dep-touching changes across these
+syncs were **wire-neutral**: cosmetic StrJSON label on `Profile.contactDomain`; `APISetUserName` handler
+refactor (constructor `{userId, simplexName}`, `/_set_name` parser, `CRUserProfileUpdated`/`NoChange`
+response unchanged); `Internal.hs` record-field reordering in bot profiles; store/view/test cleanup.
+`Types.hs` model fields/JSON, verify/set commands, responses, `NameVerifyOutcome`, `NameClaimProof`, and
+`SimplexNameInfo` are unchanged. **No UI code change required.**
+
+## Scope
+
+Ships (both iOS and Android/desktop):
+- Models: decode name / proof / verification fields, add `NameClaimProof` + `SimplexNameInfo` helpers.
+- Name display + 3-state verification indicator on contact info and channel info.
+- Verify API calls + new response handling.
+- "Verify SimpleX names" privacy toggle (default ON).
+- Two "Set SimpleX name" screens (own name; channel name).
+
+Out: no change to the core verify algorithm — the UI only triggers it and renders the result.
+
+## Decisions
+
+Single source of truth. The UX walkthrough shows the visuals; the implementation sections give file:line.
+
+### Product / UX (confirmed)
+- **A. Title** — rename to "SimpleX address and name".
+- **B. Screen body copy** — placeholders for now (final copy TBD):
+ - Own: *"Set a SimpleX name so people can connect to you using @yourname instead of a link. The name
+ must already be registered to your address."*
+ - Channel: *"Set a SimpleX name so people can find this channel as #name. The name must be registered
+ to this channel's address."*
+- **C. Own name read-only** — No; the current own name appears only inside the set screen.
+- **D. Rename scope** — rename the shared string everywhere (settings-menu row + screen title).
+- **E. Auto-verify trigger** — with the toggle ON, auto-verify on open only if stored state is `null`;
+ verified/failed shows the stored result, and tapping the indicator re-verifies.
+- **F. Failure reason** — shown on tap of the red cross (alert); an inconclusive result shows a brief
+ alert on completion. Not shown inline.
+
+### Technical approach
+- **T1. Show the name only when a proof exists** (`contactDomainProof` / `groupDomainProof` != nil).
+- **T2. One formatter + one parser.** `SimplexNameInfo.shortName` (display, mirrors `shortNameInfoStr`),
+ `editDomain` (prefix-less, prefills set fields), `SimplexNameInfo(parsing:)` (decode the encoded
+ `groupDomain` string). Contact display uses the decoded object; channel display parses `groupDomain`.
+- **T3. Set screens send a name string; UI fixes only the type prefix.** `strP` reads `@`->contact /
+ `#`->group first, so the UI prepends `@` (own) / `#` (channel); the backend canonicalises the domain.
+ Empty input clears.
+- **T4. Channel uses a raw `APIUpdateGroupProfile`** (documented at the call site): core has
+ `APISetUserName` but no `APISetGroupName`, so the channel name is set by re-sending the cloned
+ `GroupProfile` with `publicGroup.publicGroupAccess.groupDomain` updated.
+- **T5. Gating.** Channel "Set SimpleX name" only when `useRelays && isOwner && publicGroup?.publicGroupAccess != nil`;
+ own "Set SimpleX name" lives in the existing-address branch (inherently requires an address).
+
+Minor defaults (flag if wrong): iOS toggle in the first "Chats" Section (PrivacySettings.swift:85);
+spinner delay ~300ms; channel name cleared via empty input; set-name fields rely on backend rejection
+for validation (+ helper text).
+
+## UX walkthrough
+
+Same on both platforms. Nothing existing moves.
+
+### Name + verification indicator (contact info / channel info)
+
+A new line under the name, above the description, shown per T1.
+
+```
+ Contact info Channel info
+ +------------------+ +------------------+
+ | [ photo ] | | [ photo ] |
+ | Alice | | My Team |
+ | @alice.simplex v| <- new | #myteam Verify | <- new
+ | "description..."| | "description..."|
+ +------------------+ +------------------+
+ (v = check) (Verify = action)
+```
+
+Name on the left, indicator on the right; the indicator depends on state:
+
+| State (`*Verification`) | Name style | Indicator |
+|---|---|---|
+| Verified (`true`) | accent color | check mark in regular color |
+| Failed (`false`) | code style | cross mark in red (tap -> failure reason, per F) |
+| Not verified (`null`), toggle OFF | code style | "Verify name" action (accent) |
+| Not verified (`null`), toggle ON | code style | auto-verify on open (per E) -> spinner -> result |
+| Verifying (in-flight) | code style | delayed spinner (~300ms, so a fast result doesn't flash) |
+
+### Set screens (2 new buttons -> 2 new screens)
+
+1. **Own name** — on the "SimpleX address and name" screen, a new "Set SimpleX name" button just above
+ the "Or to share privately" section:
+ ```
+ [ QR code ]
+ Share address
+ Business address (toggle)
+ Address settings
+ ------------------
+ Set SimpleX name -> <- new
+ ------------------
+ Or to share privately
+ Create 1-time link
+ ```
+2. **Channel name** — on channel info, in the existing "Advanced options" section (owners only):
+ ```
+ Advanced options
+ Web access
+ Set SimpleX name -> <- new
+ ```
+
+Each opens the same view (parameterised by prefix / body text / save action): explanation + a text field
+with a fixed prefix adornment (`@` own -> user types `alice.simplex`; `#` channel -> user types `myteam`)
++ Save. Empty + Save clears the name.
+
+### Settings toggle
+"Verify SimpleX names" toggle, default ON, in the privacy settings "Chats" section (iOS:
+PrivacySettings.swift:85, no `MorePrivacyView`; Kotlin: `MorePrivacyView` Chats section, PrivacySettings.kt:118).
+
+## Backend reference (core @ fc0582cf0)
+
+Single source for wire/JSON facts.
+
+- Display: `shortNameInfoStr` (simplexmq Protocol.hs:1594) — public group on default `.simplex` TLD with
+ empty subdomain -> `#myteam`; else prefix (`@`/`#`) + full domain (`@alice.simplex`, `#myteam.testing`).
+- Encoded form: `strEncode SimplexNameInfo = "simplex:/name" <> ("@"|"#") <> fullDomain` (Protocol.hs:1565).
+- JSON shapes: `LocalProfile.contactDomain :: Maybe SimplexNameInfo` -> JSON **object**;
+ `PublicGroupAccess.groupDomain :: Maybe (StrJSON SimplexNameInfo)` -> JSON **string** (encoded form).
+- Verification: `LocalProfile.contactDomainVerification` / `GroupInfo.groupDomainVerification :: Maybe Bool`
+ -> JSON `true`/`false`/absent (decodes as Swift `Bool?` / Kotlin `Boolean?`); null=not attempted,
+ false=failed, true=verified.
+- Proof: `LocalProfile.contactDomainProof` / `PublicGroupAccess.groupDomainProof :: Maybe NameClaimProof`
+ -> JSON object `{linkOwnerId?: string, presHeader: string, signature: string}` (all strings).
+- Verify commands (manual; network/resolver errors are retryable `ChatErrorAgent`):
+ - `APIVerifyContactName {contactId}` -> `/_verify name @`.
+ - `APIVerifyPublicGroupName {groupId}` -> `/_verify name #`.
+ - Outcome `NVOVerified | NVOFailed Text | NVOInconclusive Text` -> persists `Just True` / `Just False` /
+ leaves unchanged. Responses `CRContactNameVerified {user, contact, verificationResult :: Maybe Text}` /
+ `CRGroupNameVerified {user, groupInfo, verificationResult :: Maybe Text}` return the **updated** entity
+ plus `Nothing`=verified / `Just reason`=failure-or-inconclusive text.
+- Set own name: `APISetUserName userId (Maybe SimplexNameInfo)` -> `/_set_name
save your recovery phrase"] + A --> B["Step 2: Register the name
connect wallet, search, choose years"] + B --> C["On Create your profile, paste your link into
SimpleX contact (@name) or SimpleX channel (#name)"] + C --> H["Confirm: two transactions,
60 seconds apart"] + H --> I["Step 3: search or type your name
shows 'Unconfirmed name'"] + I --> D{"A contact or a channel?"} + D -->|"@name (contact)"| J1["Step 4: set Your SimpleX name
in your SimpleX address"] + D -->|"#name (channel)"| J2["Step 4: set SimpleX name
in the channel"] + J1 --> K["Step 5: from another device,
search or type the name"] + J2 --> K + K --> Z([Connected. Name verified.]) + + classDef start fill:#f4ecf7,stroke:#8e44ad,color:#4a235a; + classDef step fill:#eaf2fb,stroke:#2e86de,color:#1b3a5b; + classDef ok fill:#d5f5e3,stroke:#27ae60,color:#145a32; + class S start; + class Z ok; + class A,B,C,H,I,J1,J2,K step; diff --git a/docs/guide/diagrams/simplex-name-steps.svg b/docs/guide/diagrams/simplex-name-steps.svg new file mode 100644 index 0000000000..4d062ec1c2 --- /dev/null +++ b/docs/guide/diagrams/simplex-name-steps.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/guide/images/before-we-start.png b/docs/guide/images/before-we-start.png new file mode 100644 index 0000000000..eb853fcd96 Binary files /dev/null and b/docs/guide/images/before-we-start.png differ diff --git a/docs/guide/images/create-your-profile.png b/docs/guide/images/create-your-profile.png new file mode 100644 index 0000000000..2d5e96d9ee Binary files /dev/null and b/docs/guide/images/create-your-profile.png differ diff --git a/docs/guide/images/register-name.png b/docs/guide/images/register-name.png new file mode 100644 index 0000000000..94584f54df Binary files /dev/null and b/docs/guide/images/register-name.png differ diff --git a/docs/guide/register-simplex-name.md b/docs/guide/register-simplex-name.md new file mode 100644 index 0000000000..366661b7e5 --- /dev/null +++ b/docs/guide/register-simplex-name.md @@ -0,0 +1,123 @@ +--- +title: Registering a SimpleX name +--- + +# Registering a SimpleX name + +A SimpleX name lets people reach you by typing a short `@name` instead of pasting +a long link. You register the name on a website and add your SimpleX link to it, +then claim the name in the app, to connect it with your SimpleX address or +channel name. + +> Names currently run on a testing network. The registration page is +> [testing-names.simplex.chat](https://testing-names.simplex.chat) and names end +> in `.testing`. The steps stay the same when the main names launch. + +## What you need + +- A crypto wallet such as MetaMask. +- The SimpleX app. +- A link for the name to open: your **contact address** (for one-to-one chats), + your **channel link** (to join a channel), or both. + +## How it works + +Setting up a name takes two parts. On the website you register the name and add +your link, so people can find your link by name. In the app you set the same name +on your profile - to prevent any other names from opening your profile or channel. + + + +## Step 1. Create a wallet + +Install MetaMask (browser extension or mobile app) and create a wallet. Write +down your recovery phrase somewhere safe and offline, as anyone with that phrase +controls your names. + +On the testing network you need a small amount of test ETH to pay network fees. + +## Step 2. Register the name and add your link + +Open the registration page and tap **Connect** to link your wallet. Type the +name you want in **Search for a name** and open it. Choose how many years to +register for, then tap **Next**. Names are currently 6 characters or more, and +some names are reserved. + + + +On **Create your profile**, paste your SimpleX link into the matching field: + + + +- **SimpleX contact** for one-to-one chats. Copy your address from the app + (**Create SimpleX address**) and paste it here. People reach it with `@name`. +- **SimpleX channel** for a channel. Copy your **Channel link** and paste it here. + People join it with `#name`. +- **Advanced usage:** fill both to use one name for your chat (`@name`) and your + channel (`#name`). + +Then tap **Next**. + +Finally, tap **Begin** and complete the three steps the site shows: + +> Before we start. Registering your name takes three steps: +> 1. Complete a transaction to begin the timer. +> 2. Wait 60 seconds for the timer to complete. +> 3. Complete a second transaction to secure your name. + +These two transactions protect the name you are registering. The first records +only a secret code for the name, not the name itself, so nobody watching the +blockchain can see which name you want. The wait lets that first transaction +settle, and the second transaction then reveals and claims the name. Without this +two-step process, someone could see your registration in progress and grab the +name before you. + + + +## Step 3. Check what the app sees + +Copy your `#name.testing` (or `@name.testing`). Paste the name into the search bar, or simply type it. + +The app reports that the name is registered but not yet added to your profile: + +> Unconfirmed name. The SimpleX name is registered, but not added to profile. +> Please add it to your address or channel profile, if you are the owner. + +This is expected, and confirms the name points at your link. The next step +finishes the setup. + +## Step 4. Claim the name in the app + +Set the name on the same profile the record points at. + +- For your **contact address**, open your SimpleX address, tap **Get SimpleX + name**, enter the name, and save. +- For your **channel**, open the channel information, tap **Get SimpleX name** (under + **Channel link**), enter the name, and save. + +This proves to people who connect to you that `#name.testing` (or `@name.testing`) is your name. + +## Step 5. Connect by name + +On another device, copy `#name.testing` (or `@name.testing`). Paste the name into the search bar, or simply type it. This time the app connects, and the name +shows a check mark next to it. + +You can paste the name in your own device too - the app will warn you that it is your own name. + +Anyone can now reach you by name, and their app confirms it is really you. + +## If something doesn't work + +| Message | Meaning | Fix | +|---|---|---| +| Unconfirmed name | The name points at a link, but the link's profile does not claim the name yet. | Do step 4: set the name on the profile it points at. | +| Name not found | No name is registered. | Check the spelling, or register it (step 2). | +| No valid link | The name has no contact or channel link. | Add a link to the name on the website, on its **Records** tab. | +| Error saving name | You tried to claim a name that has no matching link on the website. | Add your contact address or channel link to the name, then set the name again. | +| None of your servers are set to resolve SimpleX names | No server in the app is set to resolve names. | In server settings, turn on **To resolve names** for a server. | + +## See also + +- [Making connections](./making-connections.md) +- [Chat profiles](./chat-profiles.md) +- [Channel webpage](./channel-webpage.md) diff --git a/docs/lang/fr/TRANSLATIONS.md b/docs/lang/fr/TRANSLATIONS.md index 1e216900e7..cb7de707ff 100644 --- a/docs/lang/fr/TRANSLATIONS.md +++ b/docs/lang/fr/TRANSLATIONS.md @@ -26,7 +26,7 @@ Ce document est créé pour accélérer ce processus, et partager quelques astuc 2. Certaines des chaînes n'ont pas besoin d'être traduites, mais elles doivent quand même être copiées - il y a un bouton dans l'interface weblate pour cela : -
+
3. Weblate propose également des suggestions automatiques qui peuvent accélérer le processus. Parfois, elles peuvent être utilisées telles quelles, parfois elles nécessitent quelques retouches - cliquez pour les utiliser dans les traductions.
@@ -34,7 +34,7 @@ Ce document est créé pour accélérer ce processus, et partager quelques astuc
5. Quand vous traduisez [l'app iOS](https://hosted.weblate.org/projects/simplex-chat/ios/), la plupart des chaînes de caractères sont identiques, elles peuvent être copiées en un clic dans la section Glossaire. L'indice visuel que cela est possible est que la chaîne source entière est surlignée en jaune. De nombreuses autres chaînes sont très similaires, elles ne diffèrent que par la syntaxe d'interpolation ou la façon dont la police en gras est utilisée - elles ne nécessitent qu'une édition minimale. Certaines chaînes sont propres à la plate-forme iOS. Elles doivent être traduites séparément.
-
+
## Une fois la traduction terminée
diff --git a/docs/lang/pl/SERVER.md b/docs/lang/pl/SERVER.md
index f4bffc1bcc..e3ffe40c16 100644
--- a/docs/lang/pl/SERVER.md
+++ b/docs/lang/pl/SERVER.md
@@ -482,4 +482,4 @@ Możliwe jest również udostępnienie adresu swojego serwera znajomym, pozwalaj
_Uwaga_: Do obsługi haseł wymagany jest serwer SMP w wersji 4.0. Jeśli już posiadasz serwer, możesz dodać hasło do niego poprzez wpisanie hasła do pliku INI serwera.
-
+
diff --git a/docs/lang/pl/TRANSLATIONS.md b/docs/lang/pl/TRANSLATIONS.md
index 36daa5a148..531177dba5 100644
--- a/docs/lang/pl/TRANSLATIONS.md
+++ b/docs/lang/pl/TRANSLATIONS.md
@@ -39,7 +39,7 @@ Kroki są następujące:
2. Niektóre ciągi nie wymagają tłumaczenia, ale nadal trzeba je skopiować - w interfejsie użytkownika weblate znajduje się odpowiedni przycisk:
-
+
3. Weblate posiada również automatyczne sugestie, które mogą przyspieszyć ten proces. Czasami mogą być używane w niezmienionej formie, a czasami wymagają edycji - kliknij, aby użyć ich w tłumaczeniach.
@@ -68,7 +68,7 @@ My wtedy:
Serdecznie dziękujemy! To ogromny wysiłek i wielka pomoc dla rozwoju sieci SimpleX.
-
+
## Częste błędy w tłumaczeniu
diff --git a/docs/lang/pl/WEBRTC.md b/docs/lang/pl/WEBRTC.md
index d279491fb8..e291d887b5 100644
--- a/docs/lang/pl/WEBRTC.md
+++ b/docs/lang/pl/WEBRTC.md
@@ -139,7 +139,7 @@ To tyle - teraz możesz wykonywać połączenia audio i wideo za pośrednictwem
2. W sekcji **Build up ICE Server List** dodaj:
-
+
- `STUN: stun:
+
4. W sekcji **Results** powinieneś zobaczyć coś takiego:
-
+
Jeśli wyniki pokazują `srflx` i `relay`, wszystko jest skonfigurowane poprawnie!
diff --git a/docs/protocol/channels-overview.md b/docs/protocol/channels-overview.md
index d4cd2d2965..7a55f8b6e5 100644
--- a/docs/protocol/channels-overview.md
+++ b/docs/protocol/channels-overview.md
@@ -182,7 +182,7 @@ The low-level protocol supports multiple owners from the initial release. The ap
- **Subscribers** connect to relays and receive content. They cannot send messages by default, but can be given posting rights.
-Additional roles (moderator, admin, member, author) exist in the hierarchy and are inherited from the group protocol.
+Additional roles (moderator, admin, member, author) exist in the hierarchy and are inherited from the group protocol. The owner-signed roster tracks the promoted set - members, moderators, and admins; subscribers are observers until an owner promotes them.
For protocol-level detail - wire formats, message types, signing and verification mechanics, delivery pipeline - see [SimpleX Channels Protocol](./channels-protocol.md).
@@ -242,6 +242,7 @@ This threat model assumes the [SimpleX network threat model](https://github.com/
- Undetectably substitute content - subscribers on honest relays receive the original.
- Alter the channel's authoritative state on the owner's device.
- Substitute the channel profile or impersonate an owner - these require valid signatures.
+- Replay an old roster or role change to re-elevate a removed or demoted member for existing subscribers - they reject anything older than the roster version they applied (a new joiner with no prior roster can still be served an old one, until it syncs from another relay).
- Redirect subscribers to a different channel - the entity ID is validated across link and profile.
- Determine subscriber identity or network address - inherited from SMP transport.
- Correlate subscriber participation across channels - each connection uses independent SMP queues. The subscriber chooses their SMP router independently, so collusion between a relay and the relay's SMP router does not compromise connections through a different router.
diff --git a/docs/protocol/names-overview.md b/docs/protocol/names-overview.md
new file mode 100644
index 0000000000..e9fe33a791
--- /dev/null
+++ b/docs/protocol/names-overview.md
@@ -0,0 +1,271 @@
+Revision 1, 2026-07-14
+
+# SimpleX Public Names for Channels and Businesses
+
+## Table of contents
+
+- [Introduction](#introduction)
+ - [Names](#names)
+ - [Use cases](#use-cases)
+ - [On-chain registry](#on-chain-registry)
+ - [Privacy considerations](#privacy-considerations)
+- [Architecture](#architecture)
+ - [Names and records](#names-and-records)
+ - [Resolution](#resolution)
+ - [Private decentralized RPC layer](#private-decentralized-rpc-layer)
+ - [Claiming and verification](#claiming-and-verification)
+- [Differences from ENS](#differences-from-ens)
+- [Security](#security)
+ - [Design objectives](#design-objectives)
+ - [Threat model](#threat-model)
+ - [Current gaps](#current-gaps)
+- [Future work](#future-work)
+- [Conclusion](#conclusion)
+
+
+## Introduction
+
+The SimpleX network provides communication without user identifiers - people connect by exchanging links out of band. This protects private communication, but public entities - channels and businesses - need to be discoverable. Today this requires distributing a long link, which is impossible to remember and can be deleted by the router that hosts it. SimpleX public names provide memorability and ease of connection without adding user identifiers.
+
+### Names
+
+A SimpleX name is a human-readable name, registered on a public blockchain, that resolves to SimpleX links: `#example.simplex` opens a channel (for the `.simplex` namespace, the short variant `#example` can also be used for channel names) and `@example.simplex` connects to a contact or business address. One name can include both links - a business can publish `@example.simplex` for customer conversations and `#example.simplex` for its announcement channel from a single registration. Names support subnames (`support.example.simplex`). A separate test namespace (`.testing`) is deployed for early adopters before the main namespace launches.
+
+A name is not an account and not an identity. It is a record that maps a human-readable string to the links a channel or business already has, controlled by a cryptographic key that only its owner holds. The network does not use or require names; they are a discovery layer on top of it, described in this document.
+
+This document covers the naming layer built for [SimpleX Channels](./channels-overview.md) and the [SimpleX network](https://github.com/simplex-chat/simplexmq/blob/master/protocol/overview-tjr.md). For the user-facing registration steps see [Registering a SimpleX name](../guide/register-simplex-name.md); for protocol-level details see the resolver commands in the [SMP protocol](https://github.com/simplex-chat/simplexmq/blob/stable/protocol/simplex-messaging.md).
+
+### Use cases
+
+Names are intended for entities that are already public:
+
+- **Channels.** A channel reachable as `#example` can be easily shared in many ways - conversation, print, social media, and messages. If the channel's link is removed or blocked, the owner can point the name to a new link, and the channel remains reachable via the same name.
+
+- **Businesses and organizations.** A business address reachable as `@example.simplex` gives customers a way to start a conversation without scanning a QR code or trusting a link from a search result.
+
+- **Creators and public figures.** Anyone publishing to an audience can be reachable by name while their audience remains private.
+
+Names are opt-in and are only useful for public entities. Private users do not need them. Even when an entity uses a name, the network cannot track who connects to it - the communication graph remains private.
+
+### On-chain registry
+
+Names must be globally unique, so they require a shared registry. Every conventional registry design places names under an operator's control:
+
+- **A platform registry** (usernames in messaging apps) is owned by the operator: names can be revoked, impersonated, or reassigned, and the platform sees who looks up whom.
+
+- **DNS** is subject to domain seizure at the registrar and registry level, and requires registrant records.
+
+A record on a public blockchain has no operator: only the holder of the registration key can change what a name points to, and no authority can delete it. This mitigates censorship at these levels:
+
+- **SMP routers.** The router that hosts a link can delete it, and the link stops working for everyone who saved it. A name is not affected: the owner points it to a new link on a different router, and clients connect via the same name as before.
+
+- **Centralized registries.** An on-chain record cannot be revoked, because there is no intermediary.
+
+### Privacy considerations
+
+Names do not:
+
+- **Identify users.** There is no user directory, no requirement to register a name, and nothing links a name to the people who connect to it.
+
+- **Put communication on the chain.** The blockchain stores only the mapping from a name to links and optional public profile fields. Messages, membership, and channel content are never stored on the blockchain.
+
+- **Certify identity.** A verified name proves that the name's owner controls the address it points to - not who the owner is. It is the same trust model as a domain name.
+
+- **Replace links.** Links remain the primary and the more private connection mechanism, since resolving a name reveals interest in it to one resolver operator. Names are for public entities that choose to be contactable more easily.
+
+
+## Architecture
+
+### Names and records
+
+Names are lowercase labels of ASCII letters, digits, and single hyphens, forming domains under the `.simplex` top-level name (`example.simplex`, `my-channel.simplex`), with `.simplex` implied when omitted for channels: `#example` is interpreted as `#example.simplex`. The restricted alphabet prevents homograph attacks: visually identical names from mixed scripts cannot exist as distinct records.
+
+A name's on-chain record stores:
+
+- **Channel links and contact links** - each an ordered list, primary first. Multiple links give redundancy across SMP routers: clients try them in order, so the name remains usable if one router becomes unavailable. Client support for this redundancy is planned for the `.simplex` namespace launch.
+- **Optional profile fields** - a display name, website, location.
+- **Optional donation addresses** (Monero, Bitcoin, Ethereum, etc.) that apps can show to channel subscribers.
+
+Registration is a two-transaction commit-reveal process from the owner's wallet: the first transaction records only a hash, so an observer of the pending registration cannot see the name and front-run it; the second transaction reveals the name and completes the registration. The name is held as an ordinary token in the owner's wallet and is renewable and transferable. Subnames are created by the name's owner, are transferred together with the name, and cannot be separately sold - the same ownership model as DNS subdomains.
+
+### Resolution
+
+Connecting by name is two independent resolutions:
+
+1. **Name to link.** The client queries the on-chain record through the SimpleX network (next section) and obtains the channel or contact link.
+
+2. **Link to connection.** The link resolves through the existing SimpleX short-link protocol: the client retrieves the link's immutable data - cryptographically bound to the link's owner keys - and the entity's profile, and connects.
+
+The second step is unchanged from connecting by link. A name adds discoverability on top of the link protocol; it does not weaken the link's own verification, and everything a client checks when joining by link is still checked when joining by name.
+
+### Private decentralized RPC layer
+
+Reading blockchain state normally requires querying an RPC service, and in practice almost all applications - including wallets and name services - use a handful of centralized API providers. Those providers see every query, the account it concerns, and the querier's IP address, and can censor or falsify responses. Resolving names through such a provider would reveal every lookup and the client's IP address to a third party.
+
+SimpleX resolves names through the network itself. Operators can enable a *names role* on their SMP routers: a names router runs its own resolver process and its own Ethereum node, holding a full copy of the relevant chain state - operators must not share this backend with other operators. The lookup is a protocol command sent as ordinary SimpleX traffic:
+
+1. The client selects a names router among its configured servers and sends the lookup *through an SMP proxy operated by a different operator*, encrypted so the proxy cannot read it.
+2. The proxy forwards the lookup without access to its content; the names router responds from its local chain state.
+
+```mermaid
+sequenceDiagram
+ participant C as Client
+ participant P as SMP proxy(operator A) + participant N as Names router
(operator B) + participant E as Ethereum node
(operator B, local) + + C->>P: lookup, encrypted for the names router + note over P: sees the client,
not the name + P->>N: forwarded lookup + note over N: sees the name,
not the client + N->>E: read name record (eth_call) + E-->>N: name record + N-->>P: response, encrypted for the client + P-->>C: name record: channel and contact links +``` + +The result is a knowledge split with no single observer: the proxy sees which client communicates with a names router, but not the name; the names router sees the name, but not which client sent the query - no client address, session, or identity. A passive network observer sees fixed-size encrypted blocks indistinguishable from other traffic. Clients also keep the set of parties that see a lookup minimal: a query is sent to one names router, and after an authoritative response the client does not repeat the name to other servers. + +This layer is not specific to names. Private access to blockchain state via independent operators is a network capability that can be used in other contexts in the future. + +### Claiming and verification + +A name is trustworthy when: + +1. **The on-chain record points to the link.** Only the name owner's wallet key can set this. +2. **The link's profile claims the name.** Only the link owner's keys can publish this, and the claim is signed by the link's owner key, binding it to that specific link. + +For name resolution to succeed, SimpleX clients require both to be true. This mutual binding prevents abuse, such as: + +- Registering a name that points to someone else's address. The profile does not claim the name, so clients refuse to connect to it. +- Claiming a name in a profile without owning it. The on-chain record does not point to that profile's address, so the claim fails verification. + +Apps display the outcome next to the name - verified (the record and the claim match), failed, or not yet verified - and can re-verify on demand or automatically. Verification is a fresh resolution through the private RPC layer, so it reflects the current on-chain state. + +Names are used only to establish connections, not to deliver messages. Once connected, a contact or channel subscription is an ordinary SimpleX connection, independent of the name. A name expiring or being transferred affects future connections only; existing conversations and subscriptions are not affected. + + +## Differences from ENS + +The on-chain layer is the SimpleX Name Service (SNS), a fork of the [Ethereum Name Service](https://ens.domains) (ENS). ENS is the most widely used decentralized naming system, and SNS retains its core design: the registry and resolver contracts, commit-reveal registration, and expiry-based ownership. + +Each top-level name (`.testing`, `.simplex`) is an independent deployment of the same contracts: + +```mermaid +flowchart TD + CT["Controller
commit-reveal registration"] + RG["Registrar
name tokens, on-chain name index"] + PR["Resolver
simplex.contact / simplex.channel records"] + R["Registry
owner and resolver of every name"] + MR["Metadata renderer
token metadata as on-chain JSON + SVG"] + SR["Subname registrar
creates and indexes subnames"] + + CT -->|registers names| RG + CT -->|writes records| PR + RG -->|sets name ownership| R + RG -->|renders tokens| MR + SR -->|owns subname nodes| R +``` + +ENS, however, is not fully decentralized in use. Its applications depend on two off-chain services: an indexer (the subgraph) for queries such as listing the names held by an address (without it the ENS app is unusable), and a hosted metadata service to render name tokens in wallets. SNS removes both dependencies, and simplifies the ownership model: + +1. **No indexer.** The SNS contracts index names on-chain: reverse lookup from an address to the names it holds, from a token to its plaintext label, and from a name to its subnames are all direct contract reads. Every view in the SNS web app (currently, the app for test names is https://testing-names.simplex.chat) - the list of owned names, their subnames, and each name's records - is served by plain `eth_call`s against an Ethereum RPC. + +2. **Fully on-chain tokens.** A name's token metadata and image are generated by the contract as inline JSON and SVG. There is no metadata server; wallets render the name from chain data alone. + +3. **No name wrapper, no separate subname ownership.** ENS's wrapper system lets subnames be split off and owned independently, at the cost of a second token standard and a complex permission system. SNS subnames are owned together with the name and are transferred with it (the DNS model), removing the need for the wrapper. + +Resolution also differs. ENS names are resolved by applications through their RPC providers, so lookups are as centralized and observable as the provider. SNS records are read through the private RPC layer described above: many independent operators hold the chain state, and no single party sees who resolves which name. + +The result is a naming system with no off-chain services: registration, ownership, enumeration, rendering, and resolution are all either on-chain or served by the SimpleX network itself. + +The current implementation uses a web app for registration, which accesses the chain via a centralized RPC provider. We plan to add name purchases to the SimpleX apps, using the same decentralized blockchain access that is already used for name resolution. + + +## Security + +### Design objectives + +1. **Non-custodial.** Only the holder of the name's key can change or transfer the record; there is no registrar, operator, or intermediary with override authority. +2. **No infrastructure censorship.** A name does not depend on any single router: the links it points to can be replaced without changing the name, and resolution uses chain state held by many independent operators. +3. **Impersonation resistance.** A name is shown as verified only when the on-chain record and the signed claim in the link's profile match. +4. **Lookup privacy.** No single party observes both the user and the name being resolved. +5. **Availability.** A record can list multiple links across routers, and any names-capable router of the user's choosing can respond to a lookup. + +### Threat model + +This threat model assumes the [SimpleX network threat model](https://github.com/simplex-chat/simplexmq/blob/stable/protocol/security.md) and the [channels threat model](./channels-overview.md#threat-model), and addresses the naming layer. + +**A compromised names router (or its chain backend)** + +*can:* + +- Deny that a name exists, or serve a stale record, to the clients that query it. Detectable by resolving through a different operator's router. +- Serve a false record - effective only against a client that queries this router *and* only if the false record's target cooperates by claiming the name, since the claim check runs against the attacker-supplied record. Resolver agreement across operators ([future work](#future-work)) makes this require collusion of the queried operators. +- Observe which names are looked up, and how often. + +*cannot:* + +- Learn who is looking up a name - it never sees the client's address, session, or identity. +- Alter the on-chain record, or affect clients resolving through other routers. +- Affect existing connections - they do not depend on names. + +**An SMP proxy forwarding lookups** + +*can:* + +- See that a client communicates with a names router (which is an ordinary SMP router). + +*cannot:* + +- See that a request forwarded to a destination router is a name resolution request. +- See the name being looked up, or the response - both are encrypted between client and names router. + +**An impersonator** + +*can:* + +- Register a confusingly similar name. The restricted alphabet keeps such names visibly different - homographs are not possible. + +*cannot:* + +- Register a visually identical variant of an existing name using other scripts or invisible characters. +- Achieve verified status for a name pointing to someone else's address, or for an address whose name points elsewhere. + +**Compromise of the owner's wallet key** + +An attacker holding the registration key can repoint or transfer the name. New lookups then resolve to the attacker's links; the owner's profile claim no longer matches the record, so clients verifying the owner's profile see a failure. Existing connections are unaffected. Protecting the registration key is the owner's responsibility, the same as protecting the channel's own keys. An expired name that is not renewed can also be registered by someone else, so the key must be backed up and the name renewed on time. + +**A passive network observer** + +*can:* + +- See SimpleX traffic between clients and routers. + +*cannot:* + +- Distinguish name lookups from any other traffic, or learn which names anyone resolves. Inherited from SMP transport. + +### Current gaps + +1. **Single-resolver lookups.** A client currently accepts the response of one names router per lookup. Cross-checking two operators' resolvers is designed but not implemented - see below. +2. **No state proofs.** The names router is trusted to report chain state correctly; responses do not yet include proofs verifiable against a chain header. +3. **Self-hosted routers.** All pre-configured routers support name resolution, but most self-hosted routers do not support it yet. Name resolution requires at least one configured server with the names role. + + +## Future work + +- **Two-resolver agreement.** Resolve each name through two independent operators via two different proxies and compare the responses: a match is trusted; a mismatch is shown as a warning and the record is not used. This removes the single-resolver trust noted above and makes record substitution require cross-operator collusion. + +- **State proofs.** Responses including Merkle proofs of Ethereum state, verified by the client - removing the need to trust the resolver, with or without agreement. + +- **Main namespace launch.** The `.testing` namespace is deployed for early adopters; the `.simplex` namespace launches after the testing period. + +- **Registration via an app.** Registration currently requires an on-chain transaction from a wallet. + +- **DNS-based names.** The client already parses arbitrary domains (`example.com`) as web links. In the future, it will be possible to register owned domains in the SNS contract to use them as channel and contact names (`#example.com` and `@example.com`). + + +## Conclusion + +SimpleX names give channels and businesses memorable addresses that do not depend on any single server and cannot be revoked by a platform or registrar. Resolution runs through the SimpleX network, so no party observes who looks up which name. The naming system is fully decentralized on-chain, with no indexer or metadata service, and access to it is private, with no RPC provider observing requests. Names are optional and used only by public entities; private communication in SimpleX remains identifier-free. diff --git a/docs/rfcs/2026-08-05-markdown-hyperlink-connect.md b/docs/rfcs/2026-08-05-markdown-hyperlink-connect.md new file mode 100644 index 0000000000..2fe40755e8 --- /dev/null +++ b/docs/rfcs/2026-08-05-markdown-hyperlink-connect.md @@ -0,0 +1,33 @@ +# Connecting via a SimpleX link written as a markdown hyperlink + +## Problem + +Pasting a short SimpleX link written as a markdown hyperlink — `[label](https://smp6.simplex.im/a#...)` — into the chat list search, the new chat sheet search, or "Tap to paste link" fails with "Invalid connection link" instead of connecting. + +## Cause + +`markdownP` parses such a link into a single fragment whose `format` is `SimplexLink` but whose `text` is the whole markdown source: + +``` +[{"format":{"type":"simplexLink","showText":"label","linkType":"contact", + "simplexUri":"simplex:/a#...?h=smp6.simplex.im","smpHosts":["smp6.simplex.im"]}, + "text":"[label](https://smp6.simplex.im/a#...)"}] +``` + +`strConnectTarget` returns that `text` as the string to connect with. For a bare link `text` is the link, so it works; for a hyperlink it is `[label](link)`, which the core rejects as `InvalidConnReq`. + +## Design + +Use `simplexUri` — the link the parser already resolved — when the fragment came from the hyperlink parser, and keep using `text` otherwise: + +``` +text = if showText != null then simplexUri else text +``` + +`showText` is an exact discriminator, not a heuristic: `simplexUriFormat` is called with `Just t` only from `sowLinkP` (the hyperlink parser) and with `Nothing` from `wordMD` (bare link). Gating on it leaves every bare-link path unchanged. + +This also matches how the chat item renderer already resolves the same format — `TextItemView.kt` takes `simplexUri`, never the fragment `text`, when `showText` is set. `strConnectTarget` was the outlier. + +## Scope + +Short links only. `sowLinkP` rejects a full link inside a hyperlink (`fail "full SimpleX link in hyperlink"`), so `[label](full-link)` yields no formatting at all and never reaches this code — it stays treated as search text, as before. Bare full links are unaffected. diff --git a/images/github-banner.jpg b/images/github-banner.jpg new file mode 100644 index 0000000000..ef3cb5e6f5 Binary files /dev/null and b/images/github-banner.jpg differ diff --git a/packages/simplex-chat-client/types/typescript/package.json b/packages/simplex-chat-client/types/typescript/package.json index 756e181307..01d88ab770 100644 --- a/packages/simplex-chat-client/types/typescript/package.json +++ b/packages/simplex-chat-client/types/typescript/package.json @@ -1,6 +1,6 @@ { "name": "@simplex-chat/types", - "version": "0.9.0", + "version": "0.10.3", "description": "TypeScript types for SimpleX Chat bot libraries", "main": "dist/index.js", "types": "dist/index.d.ts", diff --git a/packages/simplex-chat-client/types/typescript/src/commands.ts b/packages/simplex-chat-client/types/typescript/src/commands.ts index d1b89ffe27..3f4e3ad7ee 100644 --- a/packages/simplex-chat-client/types/typescript/src/commands.ts +++ b/packages/simplex-chat-client/types/typescript/src/commands.ts @@ -89,6 +89,7 @@ export interface APISendMessages { sendRef: T.ChatRef liveMessage: boolean ttl?: number // int + signMessages: boolean composedMessages: T.ComposedMessage[] // non-empty } @@ -96,7 +97,7 @@ export namespace APISendMessages { export type Response = CR.NewChatItems | CR.ChatCmdError export function cmdString(self: APISendMessages): string { - return '/_send ' + T.ChatRef.cmdString(self.sendRef) + (self.liveMessage ? ' live=on' : '') + (self.ttl ? ' ttl=' + self.ttl : '') + ' json ' + JSON.stringify(self.composedMessages) + return '/_send ' + T.ChatRef.cmdString(self.sendRef) + (self.liveMessage ? ' live=on' : '') + (self.ttl ? ' ttl=' + self.ttl : '') + (self.signMessages ? ' sign=on' : '') + ' json ' + JSON.stringify(self.composedMessages) } } @@ -495,12 +496,12 @@ export namespace APIAddContact { } } -// Determine SimpleX link type and if the bot is already connected via this link. +// Determine SimpleX link type and if the bot is already connected via this link or name. // Network usage: interactive. export interface APIConnectPlan { userId: number // int64 - connectionLink?: string - resolveKnown: boolean + connectTarget?: string + resolveMode: T.PlanResolveMode linkOwnerSig?: T.LinkOwnerSig } @@ -508,7 +509,7 @@ export namespace APIConnectPlan { export type Response = CR.ConnectionPlan | CR.ChatCmdError export function cmdString(self: APIConnectPlan): string { - return '/_connect plan ' + self.userId + ' ' + self.connectionLink + return '/_connect plan ' + self.userId + ' ' + self.connectTarget } } @@ -528,18 +529,18 @@ export namespace APIConnect { } } -// Connect via SimpleX link as string in the active user profile. +// Connect via SimpleX link or name as string in the active user profile. // Network usage: interactive. export interface Connect { incognito: boolean - connLink_?: string + connTarget_?: string } export namespace Connect { export type Response = CR.SentConfirmation | CR.ContactAlreadyExists | CR.SentInvitation | CR.ChatCmdError export function cmdString(self: Connect): string { - return '/connect' + (self.connLink_ ? ' ' + self.connLink_ : '') + return '/connect' + (self.connTarget_ ? ' ' + self.connTarget_ : '') } } diff --git a/packages/simplex-chat-client/types/typescript/src/responses.ts b/packages/simplex-chat-client/types/typescript/src/responses.ts index 0fcf0e6eca..f54acfbeb1 100644 --- a/packages/simplex-chat-client/types/typescript/src/responses.ts +++ b/packages/simplex-chat-client/types/typescript/src/responses.ts @@ -186,6 +186,8 @@ export namespace CR { type: "connectionPlan" user: T.User connLink: T.CreatedConnLink + planSimplexName?: T.SimplexNameInfo + otherSimplexName?: T.SimplexNameInfo connectionPlan: T.ConnectionPlan } diff --git a/packages/simplex-chat-client/types/typescript/src/types.ts b/packages/simplex-chat-client/types/typescript/src/types.ts index 883728f943..e2e30d43bc 100644 --- a/packages/simplex-chat-client/types/typescript/src/types.ts +++ b/packages/simplex-chat-client/types/typescript/src/types.ts @@ -66,6 +66,7 @@ export type AgentErrorType = | AgentErrorType.NTF | AgentErrorType.XFTP | AgentErrorType.FILE + | AgentErrorType.NO_NAME_SERVERS | AgentErrorType.PROXY | AgentErrorType.RCP | AgentErrorType.BROKER @@ -84,6 +85,7 @@ export namespace AgentErrorType { | "NTF" | "XFTP" | "FILE" + | "NO_NAME_SERVERS" | "PROXY" | "RCP" | "BROKER" @@ -136,6 +138,10 @@ export namespace AgentErrorType { fileErr: FileErrorType } + export interface NO_NAME_SERVERS extends Interface { + type: "NO_NAME_SERVERS" + } + export interface PROXY extends Interface { type: "PROXY" proxyServer: string @@ -283,6 +289,7 @@ export interface BusinessChatInfo { chatType: BusinessChatType businessId: string customerId: string + businessDomain?: SimplexDomainClaim } export enum BusinessChatType { @@ -835,7 +842,7 @@ export interface CIMeta { editable: boolean forwardedByMember?: number // int64 showGroupAsSender: boolean - msgSigned?: MsgSigStatus + msgVerified?: MsgVerified createdAt: string // ISO-8601 timestamp updatedAt: string // ISO-8601 timestamp } @@ -1021,7 +1028,6 @@ export type ChatErrorType = | ChatErrorType.NoSndFileUser | ChatErrorType.NoRcvFileUser | ChatErrorType.UserUnknown - | ChatErrorType.ActiveUserExists | ChatErrorType.UserExists | ChatErrorType.ChatRelayExists | ChatErrorType.DifferentActiveUser @@ -1037,6 +1043,8 @@ export type ChatErrorType = | ChatErrorType.ChatNotStopped | ChatErrorType.ChatStoreChanged | ChatErrorType.InvalidConnReq + | ChatErrorType.SimplexDomainNotReady + | ChatErrorType.NotResolvedLocally | ChatErrorType.UnsupportedConnReq | ChatErrorType.ConnReqMessageProhibited | ChatErrorType.ContactNotReady @@ -1099,7 +1107,6 @@ export namespace ChatErrorType { | "noSndFileUser" | "noRcvFileUser" | "userUnknown" - | "activeUserExists" | "userExists" | "chatRelayExists" | "differentActiveUser" @@ -1115,6 +1122,8 @@ export namespace ChatErrorType { | "chatNotStopped" | "chatStoreChanged" | "invalidConnReq" + | "simplexDomainNotReady" + | "notResolvedLocally" | "unsupportedConnReq" | "connReqMessageProhibited" | "contactNotReady" @@ -1197,10 +1206,6 @@ export namespace ChatErrorType { type: "userUnknown" } - export interface ActiveUserExists extends Interface { - type: "activeUserExists" - } - export interface UserExists extends Interface { type: "userExists" contactName: string @@ -1273,6 +1278,16 @@ export namespace ChatErrorType { type: "invalidConnReq" } + export interface SimplexDomainNotReady extends Interface { + type: "simplexDomainNotReady" + simplexDomain: SimplexDomain + simplexDomainError: SimplexDomainError + } + + export interface NotResolvedLocally extends Interface { + type: "notResolvedLocally" + } + export interface UnsupportedConnReq extends Interface { type: "unsupportedConnReq" } @@ -2163,6 +2178,7 @@ export type ErrorType = | ErrorType.LARGE_MSG | ErrorType.EXPIRED | ErrorType.INTERNAL + | ErrorType.NAME | ErrorType.DUPLICATE_ export namespace ErrorType { @@ -2181,6 +2197,7 @@ export namespace ErrorType { | "LARGE_MSG" | "EXPIRED" | "INTERNAL" + | "NAME" | "DUPLICATE_" interface Interface { @@ -2247,6 +2264,11 @@ export namespace ErrorType { type: "INTERNAL" } + export interface NAME extends Interface { + type: "NAME" + nameErr: NameErrorType + } + export interface DUPLICATE_ extends Interface { type: "DUPLICATE_" } @@ -2375,6 +2397,11 @@ export interface FileTransferMeta { cancelled: boolean } +export enum FileType { + Normal = "normal", + Roster = "roster", +} + export type Format = | Format.Bold | Format.Italic @@ -2503,6 +2530,7 @@ export interface FullGroupPreferences { support: SupportGroupPreference sessions: RoleGroupPreference comments: CommentsGroupPreference + signMessages: GroupPreference commands: ChatBotCommand[] } @@ -2577,6 +2605,7 @@ export enum GroupFeature { Support = "support", Sessions = "sessions", Comments = "comments", + SignMessages = "signMessages", } export enum GroupFeatureEnabled { @@ -2605,9 +2634,11 @@ export interface GroupInfo { uiThemes?: UIThemeEntityOverrides customData?: object groupSummary: GroupSummary + rosterVersion?: number // int64 membersRequireAttention: number // int viaGroupLinkUri?: string groupKeys?: GroupKeys + groupDomainVerified?: boolean } export interface GroupKeys { @@ -2716,6 +2747,7 @@ export interface GroupMember { supportChat?: GroupSupportChat memberPubKey?: string relayLink?: string + memberVerifiedCode?: SecurityCode } export interface GroupMemberAdmission { @@ -2784,6 +2816,7 @@ export interface GroupPreferences { support?: SupportGroupPreference sessions?: RoleGroupPreference comments?: CommentsGroupPreference + signMessages?: GroupPreference commands?: ChatBotCommand[] } @@ -2978,12 +3011,15 @@ export interface LocalProfile { displayName: string fullName: string shortDescr?: string + description?: string image?: string contactLink?: string preferences?: Preferences peerType?: ChatPeerType localBadge?: LocalBadge localAlias: string + contactDomain?: SimplexDomainClaim + contactDomainVerified?: boolean } export enum MemberCriteria { @@ -3177,6 +3213,48 @@ export enum MsgSigStatus { SignedNoKey = "signedNoKey", } +export type MsgVerified = MsgVerified.Signed | MsgVerified.SigMissing + +export namespace MsgVerified { + export type Tag = "signed" | "sigMissing" + + interface Interface { + type: Tag + } + + export interface Signed extends Interface { + type: "signed" + sigStatus: MsgSigStatus + } + + export interface SigMissing extends Interface { + type: "sigMissing" + } +} + +export type NameErrorType = NameErrorType.NO_RESOLVER | NameErrorType.NOT_FOUND | NameErrorType.RESOLVER + +export namespace NameErrorType { + export type Tag = "NO_RESOLVER" | "NOT_FOUND" | "RESOLVER" + + interface Interface { + type: Tag + } + + export interface NO_RESOLVER extends Interface { + type: "NO_RESOLVER" + } + + export interface NOT_FOUND extends Interface { + type: "NOT_FOUND" + } + + export interface RESOLVER extends Interface { + type: "RESOLVER" + resolverErr: string + } +} + export type NetworkError = | NetworkError.ConnectError | NetworkError.TLSError @@ -3230,6 +3308,7 @@ export interface NewUser { profile?: Profile pastTimestamp: boolean userChatRelay: boolean + clientService: boolean } export interface NoteFolder { @@ -3294,6 +3373,12 @@ export interface PendingContactConnection { updatedAt: string // ISO-8601 timestamp } +export enum PlanResolveMode { + AllGroups = "allGroups", + Unknown = "unknown", + Never = "never", +} + export interface PrefEnabled { forUser: boolean forContact: boolean @@ -3329,11 +3414,13 @@ export interface Profile { displayName: string fullName: string shortDescr?: string + description?: string image?: string contactLink?: string preferences?: Preferences peerType?: ChatPeerType badge?: BadgeProof + contactDomain?: SimplexDomainClaim } export type ProxyClientError = @@ -3394,7 +3481,7 @@ export namespace ProxyError { export interface PublicGroupAccess { groupWebPage?: string - groupDomain?: string + groupDomainClaim?: SimplexDomainClaim domainWebPage: boolean allowEmbedding: boolean } @@ -3640,6 +3727,7 @@ export interface RcvFileTransfer { xftpRcvFile?: XFTPRcvFile fileInvitation: FileInvitation fileStatus: RcvFileStatus + fileType: FileType rcvFileInline?: InlineFileMode senderDisplayName: string chunkSize: number // int64 @@ -3811,6 +3899,7 @@ export enum RelayStatus { New = "new", Invited = "invited", Accepted = "accepted", + AcknowledgedRoster = "acknowledgedRoster", Active = "active", Inactive = "inactive", Rejected = "rejected", @@ -3895,6 +3984,41 @@ export interface SimplePreference { allow: FeatureAllowed } +export interface SimplexDomain { + nameTLD: SimplexTLD + domain: string + subDomain: string[] +} + +export interface SimplexDomainClaim { + domain: string + proof?: SimplexDomainProof +} + +export type SimplexDomainError = SimplexDomainError.NoValidLink | SimplexDomainError.UnknownDomain + +export namespace SimplexDomainError { + export type Tag = "noValidLink" | "unknownDomain" + + interface Interface { + type: Tag + } + + export interface NoValidLink extends Interface { + type: "noValidLink" + } + + export interface UnknownDomain extends Interface { + type: "unknownDomain" + } +} + +export interface SimplexDomainProof { + linkOwnerId?: string + presHeader: string + signature: string +} + export enum SimplexLinkType { Contact = "contact", Invitation = "invitation", @@ -3903,15 +4027,9 @@ export enum SimplexLinkType { Relay = "relay", } -export interface SimplexNameDomain { - nameTLD: SimplexTLD - domain: string - subDomain: string[] -} - export interface SimplexNameInfo { nameType: SimplexNameType - nameDomain: SimplexNameDomain + nameDomain: SimplexDomain } export enum SimplexNameType { @@ -4879,8 +4997,9 @@ export interface User { sendRcptsSmallGroups: boolean autoAcceptMemberContacts: boolean userMemberProfileUpdatedAt?: string // ISO-8601 timestamp - uiThemes?: UIThemeEntityOverrides userChatRelay: boolean + clientService: boolean + uiThemes?: UIThemeEntityOverrides } export interface UserChatRelay { diff --git a/packages/simplex-chat-client/typescript/src/client.ts b/packages/simplex-chat-client/typescript/src/client.ts index 12fa150fc4..10c4ee0a81 100644 --- a/packages/simplex-chat-client/typescript/src/client.ts +++ b/packages/simplex-chat-client/typescript/src/client.ts @@ -121,7 +121,7 @@ export class ChatClient { async apiSendMessages(chatType: T.ChatType, chatId: number, messages: T.ComposedMessage[]): Promise