7.0.1.0

ntf server: shard push workers per notification token (#1840 )
* ntf server: shard push workers per notification token * ntf server: inline push worker shard calculation
2026-08-30 05:28:22 +00:00 · 2026-07-31 15:20:41 +01:00 · 2026-07-31 15:19:43 +01:00 · 2026-07-30 16:33:27 +01:00 · 2026-07-25 11:58:17 +01:00 · 2026-07-19 18:27:55 +01:00
422 changed files with 68747 additions and 9137 deletions
@@ -0,0 +1,44 @@
+name: 'Set Swap Space'
+description: 'Add moar swap'
+branding:
+  icon: 'crop'
+  color: 'orange'
+inputs:
+  swap-size-gb:
+    description: 'Swap space to create, in Gigabytes.'
+    required: false
+    default: '10'
+runs:
+  using: "composite"
+  steps:
+    - name: Swap space report before modification
+      shell: bash
+      run: |
+        echo "Memory and swap:"
+        free -h
+        echo
+        swapon --show
+        echo
+    - name: Set Swap
+      shell: bash
+      run: |
+          export SWAP_FILE=$(swapon --show=NAME | tail -n 1)
+          echo "Swap file: $SWAP_FILE"
+          if [ -z "$SWAP_FILE" ]; then
+            SWAP_FILE=/opt/swapfile
+          else
+            sudo swapoff $SWAP_FILE
+            sudo rm $SWAP_FILE
+          fi
+          sudo fallocate -l ${{ inputs.swap-size-gb }}G $SWAP_FILE
+          sudo chmod 600 $SWAP_FILE
+          sudo mkswap $SWAP_FILE
+          sudo swapon $SWAP_FILE
+    - name: Swap space report after modification
+      shell: bash
+      run: |
+        echo "Memory and swap:"
+        free -h
+        echo
+        swapon --show
+        echo
@@ -10,11 +10,61 @@ on:
  pull_request:

 jobs:
+
+# =============================
+#       Create release
+# =============================
+
+# Create release, but only if it's triggered by tag push.
+# On pull requests/commits push, this job will always complete.
+
+  maybe-release:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Clone project
+        if: startsWith(github.ref, 'refs/tags/v')
+        uses: actions/checkout@v3
+        with:
+          submodules: recursive
+
+      - name: Build changelog
+        id: build_changelog
+        if: startsWith(github.ref, 'refs/tags/v')
+        uses: simplex-chat/release-changelog-builder-action@v5
+        with:
+          configuration: .github/changelog_conf.json
+          failOnError: true
+          ignorePreReleases: true
+          commitMode: true
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Create release
+        if: startsWith(github.ref, 'refs/tags/v')
+        uses: simplex-chat/action-gh-release@v2
+        with:
+          body: |
+            See full changelog [here](https://github.com/simplex-chat/simplexmq/blob/master/CHANGELOG.md).
+
+            Commits:
+            ${{ steps.build_changelog.outputs.changelog }}
+          prerelease: true
+          files: |
+            LICENSE
+          fail_on_unmatched_files: true
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+# =============================
+#        Main build job
+# =============================
+
  build:
-    name: "Ubuntu: ${{ matrix.os }}, GHC: ${{ matrix.ghc }}"
+    name: "ubuntu-${{ matrix.os }}-${{ matrix.arch }}, GHC: ${{ matrix.ghc }}"
+    needs: maybe-release
    env:
      apps: "smp-server xftp-server ntf-server xftp"
-    runs-on: ubuntu-${{ matrix.os }}
+    runs-on: ${{ matrix.runner }}
    services:
      postgres:
        image: postgres:15
@@ -33,82 +83,151 @@ jobs:
      matrix:
        include:
          - os: 22.04
+            os_underscore: 22_04
+            arch: x86-64
+            runner: "ubuntu-22.04"
            ghc: "8.10.7"
-            platform_name: 22_04-8.10.7
+            should_run: ${{ !(github.ref == 'refs/heads/stable' || startsWith(github.ref, 'refs/tags/v')) }}
          - os: 22.04
+            os_underscore: 22_04
+            arch: x86-64
+            runner: "ubuntu-22.04"
            ghc: "9.6.3"
-            platform_name: 22_04-x86-64
+            should_run: true
          - os: 24.04
+            os_underscore: 24_04
+            arch: x86-64
+            runner: "ubuntu-24.04"
            ghc: "9.6.3"
-            platform_name: 24_04-x86-64
+            should_run: true
+          - os: 22.04
+            os_underscore: 22_04
+            arch: aarch64
+            runner: "ubuntu-22.04-arm"
+            ghc: "9.6.3"
+            should_run: true
+          - os: 24.04
+            os_underscore: 24_04
+            arch: aarch64
+            runner: "ubuntu-24.04-arm"
+            ghc: "9.6.3"
+            should_run: true
    steps:
      - name: Clone project
+        if: matrix.should_run == true
        uses: actions/checkout@v3
+        with:
+          submodules: recursive

      - name: Set up Docker Buildx
-        uses: docker/setup-buildx-action@v3
+        if: matrix.should_run == true
+        uses: simplex-chat/docker-setup-buildx-action@v3
+
+      - name: Setup swap
+        if: matrix.ghc == '8.10.7' && matrix.should_run == true
+        uses: ./.github/actions/swap
+        with:
+          swap-size-gb: 20
+
+      - name: Install PostgreSQL 15 client tools
+        if: matrix.os == '22.04' && matrix.should_run == true
+        shell: bash
+        run: |
+          # Import the repository signing key
+          sudo install -d /usr/share/postgresql-common/pgdg
+          sudo curl -o /usr/share/postgresql-common/pgdg/apt.postgresql.org.asc --fail https://www.postgresql.org/media/keys/ACCC4CF8.asc
+          # Add the PostgreSQL APT repository
+          sudo sh -c 'echo "deb [signed-by=/usr/share/postgresql-common/pgdg/apt.postgresql.org.asc] https://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
+          # Update repository and install postgresql tools
+          sudo apt update
+          sudo apt -y install postgresql-client-15

      - name: Build and cache Docker image
-        uses: docker/build-push-action@v6
+        if: matrix.should_run == true
+        uses: simplex-chat/docker-build-push-action@v6
        with:
          context: .
          load: true
          file: Dockerfile.build
-          tags: build/${{ matrix.platform_name }}:latest
-          cache-from: |
-            type=gha
-            type=gha,scope=master
-          cache-to: type=gha,mode=max
+          tags: build/${{ matrix.os }}:latest
          build-args: |
            TAG=${{ matrix.os }}
            GHC=${{ matrix.ghc }}

      - name: Cache dependencies
+        if: matrix.should_run == true
        uses: actions/cache@v4
        with:
          path: |
            ~/.cabal/store
            dist-newstyle
-          key: ${{ matrix.os }}-${{ hashFiles('cabal.project', 'simplexmq.cabal') }}
+          key: ubuntu-${{ matrix.os }}-${{ matrix.arch }}-ghc${{ matrix.ghc }}-${{ hashFiles('cabal.project', 'simplexmq.cabal') }}

      - name: Start container
+        if: matrix.should_run == true
        shell: bash
        run: |
          docker run -t -d \
+            --device /dev/fuse \
+            --cap-add SYS_ADMIN \
+            --security-opt apparmor:unconfined \
            --name builder \
            -v ~/.cabal:/root/.cabal \
            -v /home/runner/work/_temp:/home/runner/work/_temp \
            -v ${{ github.workspace }}:/project \
-            build/${{ matrix.platform_name }}:latest
+            build/${{ matrix.os }}:latest

-      - name: Build smp-server (postgresql) and tests
-        shell: docker exec -t builder sh {0}
+      - name: Build smp-server, xftp-server (postgresql) and tests
+        if: matrix.should_run == true
+        shell: docker exec -t builder sh -eu {0}
        run: |
+          chmod -fR 777 ~/.cabal ./dist-newstyle || :; git config --global --add safe.directory '*'
+          cabal clean
          cabal update
-          cabal build --enable-tests -fserver_postgres
+          cabal build --jobs=$(nproc) --enable-tests -fserver_postgres
          mkdir -p /out
-          for i in smp-server simplexmq-test; do
+          for i in smp-server xftp-server simplexmq-test; do
            bin=$(find /project/dist-newstyle -name "$i" -type f -executable)
            chmod +x "$bin"
            mv "$bin" /out/
          done
-          strip /out/smp-server
+          strip /out/smp-server /out/xftp-server

      - name: Copy simplexmq-test from container
+        if: matrix.should_run == true
        shell: bash
        run: |
          docker cp builder:/out/simplexmq-test .

-      - name: Copy smp-server (postgresql) from container and prepare it
-        if: startsWith(github.ref, 'refs/tags/v')
+      - name: Copy smp-server, xftp-server (postgresql) from container and prepare it
+        if: startsWith(github.ref, 'refs/tags/v') && matrix.should_run == true
+        id: prepare-postgres
        shell: bash
        run: |
-          docker cp builder:/out/smp-server ./smp-server-postgres-ubuntu-${{ matrix.platform_name }}
+          printf 'bins<<EOF\n' > bins.output
+          printf 'hashes<<EOF\n' > hashes.output
+
+          for i in smp-server xftp-server; do
+            name="${i}-postgres-ubuntu-${{ matrix.os_underscore }}-${{ matrix.arch }}"
+            docker cp builder:/out/$i $name
+
+            path="${{ github.workspace }}/$name"
+            hash="SHA2-256($name)= $(openssl sha256 $path | cut -d' ' -f 2)"
+
+            printf '%s\n' "$path" >> bins.output
+            printf '%s\n\n' "$hash" >> hashes.output
+          done
+          printf 'EOF\n' >> bins.output
+          printf 'EOF\n' >> hashes.output
+
+          cat bins.output >> "$GITHUB_OUTPUT"
+          cat hashes.output >> "$GITHUB_OUTPUT"

      - name: Build everything else (standard)
-        shell: docker exec -t builder sh {0}
+        if: matrix.should_run == true
+        shell: docker exec -t builder sh -eu {0}
        run: |
-          cabal build
+          cabal build --jobs=$(nproc)
          mkdir -p /out
          for i in ${{ env.apps }}; do
            bin=$(find /project/dist-newstyle -name "$i" -type f -executable)
@@ -118,48 +237,67 @@ jobs:
          done

      - name: Copy binaries from container and prepare them
-        if: startsWith(github.ref, 'refs/tags/v')
+        id: prepare-regular
+        if: startsWith(github.ref, 'refs/tags/v') && matrix.should_run == true
        shell: bash
        run: |
          docker cp builder:/out .
-          for i in ${{ env.apps }}; do mv ./out/$i ./$i-ubuntu-${{ matrix.platform_name }}; done

-      - name: Build changelog
-        if: startsWith(github.ref, 'refs/tags/v')
-        id: build_changelog
-        uses: mikepenz/release-changelog-builder-action@v5
+          printf 'bins<<EOF\n' > bins.output
+          printf 'hashes<<EOF\n' > hashes.output
+          for i in ${{ env.apps }}; do
+            name="$i-ubuntu-${{ matrix.os_underscore }}-${{ matrix.arch }}"
+
+            mv ./out/$i ./$name
+
+            path="${{ github.workspace }}/$name"
+            hash="SHA2-256($name)= $(openssl sha256 $path | cut -d' ' -f 2)"
+
+            printf '%s\n' "$path" >> bins.output
+            printf '%s\n\n' "$hash" >> hashes.output
+          done
+          printf 'EOF\n' >> bins.output
+          printf 'EOF\n' >> hashes.output
+
+          cat bins.output >> "$GITHUB_OUTPUT"
+          cat hashes.output >> "$GITHUB_OUTPUT"
+
+      - name: Upload binaries
+        if: startsWith(github.ref, 'refs/tags/v') && matrix.should_run == true
+        uses: simplex-chat/action-gh-release@v2
        with:
-          configuration: .github/changelog_conf.json
-          failOnError: true
-          ignorePreReleases: true
-          commitMode: true
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-
-      - name: Create release
-        if: startsWith(github.ref, 'refs/tags/v') && matrix.ghc != '8.10.7'
-        uses: softprops/action-gh-release@v2
-        with:
-          body: |
-            See full changelog [here](https://github.com/simplex-chat/simplexmq/blob/master/CHANGELOG.md).
-
-            Commits:
-            ${{ steps.build_changelog.outputs.changelog }}
+          append_body: true
          prerelease: true
-          files: |
-            LICENSE
-            smp-server-ubuntu-${{ matrix.platform_name }}
-            smp-server-postgres-ubuntu-${{ matrix.platform_name }}
-            ntf-server-ubuntu-${{ matrix.platform_name }}
-            xftp-server-ubuntu-${{ matrix.platform_name }}
-            xftp-ubuntu-${{ matrix.platform_name }}
          fail_on_unmatched_files: true
+          body: |
+            ${{ steps.prepare-regular.outputs.hashes }}
+            ${{ steps.prepare-postgres.outputs.hashes }}
+          files: |
+            ${{ steps.prepare-regular.outputs.bins }}
+            ${{ steps.prepare-postgres.outputs.bins }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Test
+        if: matrix.should_run == true && matrix.arch == 'x86-64'
+        timeout-minutes: 120
        shell: bash
        env:
          PGHOST: localhost
        run: |
-          ./simplexmq-test
+          i=1
+          attempts=1
+          ${{ (github.ref == 'refs/heads/stable' || startsWith(github.ref, 'refs/tags/v')) }} && attempts=3
+          while [ "$i" -le "$attempts" ]; do
+            if ./simplexmq-test; then
+              break
+            else
+              echo "Attempt $i failed, retrying..."
+              i=$((i + 1))
+              sleep 1
+            fi
+          done
+          if [ "$i" -gt "$attempts" ]; then
+            echo "All "$attempts" attempts failed."
+            exit 1
+          fi
@@ -20,16 +20,18 @@ jobs:
    steps:
      - name: Clone project
        uses: actions/checkout@v4
+        with:
+          submodules: recursive

      - name: Log in to Docker Hub
-        uses: docker/login-action@v3
+        uses: simplex-chat/docker-login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_PASSWORD }}

      - name: Extract metadata for Docker image
        id: meta
-        uses: docker/metadata-action@v5
+        uses: simplex-chat/docker-metadata-action@v5
        with:
          images: ${{ secrets.DOCKERHUB_USERNAME }}/${{ matrix.app }}
          flavor: |
@@ -39,9 +41,17 @@ jobs:
            type=semver,pattern=v{{major}}.{{minor}}
            type=semver,pattern=v{{major}}

+      - name: Set up QEMU
+        uses: docker/setup-qemu-action@v3
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+
      - name: Build and push Docker image
-        uses: docker/build-push-action@v6
+        uses: simplex-chat/docker-build-push-action@v6
        with:
+          context: .
+          platforms: linux/amd64,linux/arm64
          push: true
          build-args: |
            APP=${{ matrix.app }}
@@ -0,0 +1,47 @@
+name: Reproduce latest release
+
+on:
+  workflow_dispatch:
+  schedule:
+    - cron: '0 2 * * *' # every day at 02:00 night
+
+jobs:
+  reproduce:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v3
+        with:
+          submodules: recursive
+
+      - name: Get latest release
+        shell: bash
+        run: |
+          curl --proto '=https' \
+               --tlsv1.2 \
+               -sSf -L \
+               'https://api.github.com/repos/simplex-chat/simplexmq/releases/latest' \
+               2>/dev/null | \
+          grep -i "tag_name" | \
+          awk -F \" '{print "TAG="$4}' >> $GITHUB_ENV
+
+      - name: Execute reproduce script
+        run: |
+          ${GITHUB_WORKSPACE}/scripts/simplexmq-reproduce-builds.sh "$TAG" || :
+
+      - name: Check if build has been reproduced
+        env:
+          url: ${{ secrets.STATUS_SIMPLEX_WEBHOOK_URL }}
+          user: ${{ secrets.STATUS_SIMPLEX_WEBHOOK_USER }}
+          pass: ${{ secrets.STATUS_SIMPLEX_WEBHOOK_PASS }}
+        run: |
+          if [ -f "${GITHUB_WORKSPACE}/${TAG}-simplexmq/_sha256sums" ]; then
+            exit 0
+          else
+            curl --proto '=https' --tlsv1.2 -sSf \
+              -u "${user}:${pass}" \
+              -H 'Content-Type: application/json' \
+              -d '{"title": "👾 GitHub: Runner", "description": "⛔️ '"$TAG"' did not reproduce."}' \
+              "$url"
+            exit 1
+          fi
@@ -11,3 +11,4 @@ cabal.project.local~
 .hpc/
 *.tix
 .coverage
+
@@ -0,0 +1,6 @@
+[submodule "cbits/libbbs"]
+	path = cbits/libbbs
+	url = https://github.com/simplex-chat/libbbs.git
+[submodule "cbits/blst"]
+	path = cbits/blst
+	url = https://github.com/supranational/blst.git
@@ -0,0 +1,53 @@
+# XFTPClientAgent Pattern
+
+## TOC
+1. Executive Summary
+2. Changes: client.ts
+3. Changes: agent.ts
+4. Changes: test/browser.test.ts
+5. Verification
+
+## Executive Summary
+
+Add `XFTPClientAgent` — a per-server connection pool matching the Haskell pattern. The agent caches `XFTPClient` instances by server URL. All orchestration functions (`uploadFile`, `downloadFile`, `deleteFile`) take `agent` as first parameter and use `getXFTPServerClient(agent, server)` instead of calling `connectXFTP` directly. Connections stay open on success; the caller creates and closes the agent.
+
+`connectXFTP` and `closeXFTP` stay exported (used by `XFTPWebTests.hs` Haskell tests). The `browserClients` hack, per-function `connections: Map`, and `getOrConnect` are deleted.
+
+## Changes: client.ts
+
+**Add** after types section: `XFTPClientAgent` interface, `newXFTPAgent`, `getXFTPServerClient`, `closeXFTPServerClient`, `closeXFTPAgent`.
+
+**Delete**: `browserClients` Map and all `isNode` browser-cache checks in `connectXFTP` and `closeXFTP`.
+
+**Revert `closeXFTP`** to unconditional `c.transport.close()` (browser transport.close() is already a no-op).
+
+`connectXFTP` stays exported (backward compat) but becomes a raw low-level function — no caching.
+
+## Changes: agent.ts
+
+**Imports**: replace `connectXFTP`/`closeXFTP` with `getXFTPServerClient`/`closeXFTPAgent` etc.
+
+**Re-export** from agent.ts: `newXFTPAgent`, `closeXFTPAgent`, `XFTPClientAgent`.
+
+**`uploadFile`**: add `agent: XFTPClientAgent` as first param. Replace `connectXFTP` → `getXFTPServerClient`. Remove `finally { closeXFTP }`. Pass `agent` to `uploadRedirectDescription`.
+
+**`uploadRedirectDescription`**: change from `(client, server, innerFd)` to `(agent, server, innerFd)`. Get client via `getXFTPServerClient`.
+
+**`downloadFile`**: add `agent` param. Delete local `connections: Map`. Replace `getOrConnect` → `getXFTPServerClient`. Remove finally cleanup. Pass `agent` to `downloadWithRedirect`.
+
+**`downloadWithRedirect`**: add `agent` param. Same replacements. Remove try/catch cleanup. Recursive call passes `agent`.
+
+**`deleteFile`**: add `agent` param. Same pattern.
+
+**Delete**: `getOrConnect` function entirely.
+
+## Changes: test/browser.test.ts
+
+Create agent before operations, pass to upload/download, close in finally.
+
+## Verification
+
+1. `npx vitest --run` — browser round-trip test passes
+2. No remaining `browserClients`, `getOrConnect`, or per-function `connections: Map` locals
+3. `connectXFTP` and `closeXFTP` still exported (XFTPWebTests.hs compat)
+4. All orchestration functions take `agent` as first param
@@ -1,3 +1,139 @@
+# 6.5.1
+
+Version 6.5.1.0
+
+XFTP client:
+- backwards compatible file header decoding.
+
+# 6.5.0
+
+Version 6.5.0.17
+
+SMP agent:
+- improve subscriptions
+  - reduce memory usage and retries during initial subscription (#1758)
+  - fix race resulting in pending subscriptions never subscribed (#1756)
+  - batch processing of subscription results and errors (#1652)
+  - reduce memory usage of active subscriptions.
+- drop message after N reception attempts (#1762)
+- fix possible deadlocks of queue overloading when processing messages (#1713)
+- improved APIs for short link management and creation.
+- support multiple link owners in link data (#1701)
+
+SMP server:
+- store messages in PostgreSQL (#1622).
+- reduce memory usage with PostgreSQL database - do not use queue cache (#1637)
+- fix in-memory server not restoring queue/service associations after 2+ restarts (#1618)
+
+XFTP server:
+- support PostgreSQL database.
+- add server page.
+- support uploads from web clients.
+
+Servers:
+- better socket leak prevention during TLS handshake, NetworkError type to bette diagnose connection errors (#1619)
+- use "=" as default INI key-value separator (#1767)
+
+# 6.4.4
+
+Servers:
+- fix server pages when source code is not specified.
+- include commit SHA in printed version and in web page (#1608).
+
+SMP server:
+- support short SimpleX addresses in server information page (#1600).
+- wrap all queries in transactions (#1603).
+
+SMP agent:
+- chat relay address type for short links (#1602).
+- extend xrcp certificate validity 1 hour in the past, to allow out of sync clocks (#1601).
+
+# 6.4.3
+
+SMP agent:
+- fix some connection errors by updating contact request server hosts to match server in short link (#1597).
+
+SMP server:
+- support short link URI as queue identifier in control port commands (#1596).
+
+# 6.4.2
+
+SMP server:
+- fix memory leak when connection interrupts straight after client connects.
+- do not include repeated queue blocking into stats/quota.
+
+XFTP server:
+- prometheus metrics
+
+# 6.4.1
+
+SMP protocol:
+- create notification credentials via NEW command that creates the queue (#1586)
+
+SMP server:
+- control port session improvements (#1591)
+- additional stat counter for ntf credentials created together with the queue (#1589)
+
+# 6.4.0
+
+SMP protocol (server/client):
+- support associated queue data and short connection links (see [RFC](./rfcs/2025-03-16-smp-queues.md)).
+- service certificates to optimize subscriptions.
+
+SMP agent:
+- support retries for interactive connection handshakes.
+- use web port 443 by default for preset servers.
+- use static RNG function to avoid creating dynamic C stubs when generating sntrup keys (it was detected as Dynamic Code Loading in GrapheneOS).
+- different timeouts for interactive and background operations.
+
+Ntf server:
+- PostgreSQL storage.
+- Prometheus metrics.
+- use service certificates.
+- fix repeat token registration.
+
+# 6.3.2
+
+Servers:
+- enable store log by default (#1501).
+
+SMP server:
+- reduce memory usage (#1498)
+
+SMP agent:
+- handle client/agent version downgrades after connection was established (#1508).
+
+# 6.3.1
+
+Servers:
+- handle ECONNABORTED error on client connections.
+- reproducible builds.
+- blocking records for content moderation.
+- update script (simplex-servers-update) downloads scripts from the specified or the latest stable tag.
+
+SMP server:
+- support for PostgreSQL database for queue records for higher traffic servers.
+- fix old clients sending messages to new servers (#1443)
+- remove empty journals when opening message queues and expiring idle queues (#1456, #1458).
+- additional start options (#1465):
+  - `maintenance` to run all start/stop operations without starting server.
+  - `skip-warnings` to ignore the last corrupted line in store log (can happen on abnormal termination).
+
+Ntf server:
+- record date of last token activity, to allow expiring inactive tokens.
+- additional token invalidation reasons in logs.
+
+SMP agent:
+- store message sent to multiple connections only once, to reduce storage when sending to groups (#1453).
+- encrypt messages on delivery, to reduce database writes (#1446).
+- don't block method calls on congested sockets for better concurrency (#1454).
+- check notification token status on client connection.
+- option to skip SQLite vacuum on migrations.
+
+# 6.3.0
+
+SMP agent: fix joining connection after failure by using the same ratchet.
+
 # 6.2.2

 SMP server:
@@ -32,7 +168,7 @@ Servers: more reliable restoring of state.

 SMP server: reduced memory usage and faster start.

-Notifications: compensate for iOS notifications being droppted by Apple while device is offline (#1378):
+Notifications: compensate for iOS notifications being dropped by Apple while device is offline (#1378):
 - Ntf server: send multiple SMP notifications in one iOS notification.
 - Agent: get multiple messages for one iOS notification.

@@ -1,6 +1,6 @@
 # SimpleXMQ

-[![GitHub build](https://github.com/simplex-chat/simplexmq/workflows/build/badge.svg)](https://github.com/simplex-chat/simplexmq/actions?query=workflow%3Abuild)
+[![GitHub build](https://github.com/simplex-chat/simplexmq/actions/workflows/build.yml/badge.svg)](https://github.com/simplex-chat/simplexmq/actions/workflows/build.yml)
 [![GitHub release](https://img.shields.io/github/v/release/simplex-chat/simplexmq)](https://github.com/simplex-chat/simplexmq/releases)

 📢 SimpleXMQ v1 is released - with many security, privacy and efficiency improvements, new functionality - see [release notes](https://github.com/simplex-chat/simplexmq/releases/tag/v1.0.0).
@@ -33,7 +33,7 @@ To initialize the server use `smp-server init -n <fqdn>` (or `smp-server init --

 SMP server uses in-memory persistence with an optional append-only log of created queues that allows to re-start the server without losing the connections. This log is compacted on every server restart, permanently removing suspended and removed queues.

-To enable store log, initialize server using `smp-server -l` command, or modify `smp-server.ini` created during initialization (uncomment `enable: on` option in the store log section). Use `smp-server --help` for other usage tips.
+To enable store log, initialize server using `smp-server -l` command, or modify `smp-server.ini` created during initialization (uncomment `enable = on` option in the store log section). Use `smp-server --help` for other usage tips.

 Starting from version 2.3.0, when store log is enabled, the server would also enable saving undelivered messages on exit and restoring them on start. This can be disabled via a separate setting `restore_messages` in `smp-server.ini` file. Saving messages would only work if the server is stopped with SIGINT signal (keyboard interrupt), if it is stopped with SIGTERM signal the messages would not be saved.

@@ -116,7 +116,7 @@ On Linux, you can deploy smp and xftp server using Docker. This will download im
 2. Run your Docker container.

   - `smp-server`
-   
+
     You must change **your_ip_or_domain**. `-e "pass=password"` is optional variable to password-protect your `smp` server:
     ```sh
     docker run -d \
@@ -129,7 +129,7 @@ On Linux, you can deploy smp and xftp server using Docker. This will download im
     ```

   - `xftp-server`
-   
+
     You must change **your_ip_or_domain** and **maximum_storage**.
     ```sh
     docker run -d \
@@ -187,7 +187,7 @@ On Linux, you can build smp server using Docker.
 3. Run your Docker container.

   - `smp-server`
-   
+
     You must change **your_ip_or_domain**. `-e "pass=password"` is optional variable to password-protect your `smp` server:
     ```sh
     docker run -d \
@@ -200,7 +200,7 @@ On Linux, you can build smp server using Docker.
     ```

   - `xftp-server`
-   
+
     You must change **your_ip_or_domain** and **maximum_storage**.
     ```sh
     docker run -d \
@@ -247,7 +247,7 @@ On Linux, you can build smp server using Docker.

   `xftp-server`
   ```sh
-   cabal list-bin exe:xftp-server 
+   cabal list-bin exe:xftp-server
   ```

 - Initialize SMP server with `smp-server init [-l] -n <fqdn>` or `smp-server init [-l] --ip <ip>` - depending on how you initialize it, either FQDN or IP will be used for server's address.
@@ -0,0 +1,15 @@
+{-# LANGUAGE TemplateHaskell #-}
+
+module Web.Embedded where
+
+import Data.FileEmbed (embedDir, embedFile)
+import Simplex.Messaging.Server.Web (EmbeddedContent (..))
+
+embeddedContent :: EmbeddedContent
+embeddedContent =
+  EmbeddedContent
+    { indexHtml = $(embedFile "apps/common/Web/static/index.html"),
+      linkHtml = $(embedFile "apps/common/Web/static/link.html"),
+      mediaContent = $(embedDir "apps/common/Web/static/media/"),
+      wellKnown = $(embedDir "apps/common/Web/static/.well-known/")
+    }
@@ -0,0 +1,49 @@
+{
+  "applinks": {
+    "details": [
+      {
+        "appIDs": [
+          "5NN7GUYB6T.chat.simplex.app"
+        ],
+        "components": [
+          {
+            "/": "/contact/*"
+          },
+          {
+            "/": "/contact"
+          },
+          {
+            "/": "/invitation/*"
+          },
+          {
+            "/": "/invitation"
+          },
+          {
+            "/": "/a/*"
+          },
+          {
+            "/": "/a"
+          },
+          {
+            "/": "/c/*"
+          },
+          {
+            "/": "/c"
+          },
+          {
+            "/": "/g/*"
+          },
+          {
+            "/": "/g"
+          },
+          {
+            "/": "/i/*"
+          },
+          {
+            "/": "/i"
+          }
+        ]
+      }
+    ]
+  }
+}
@@ -0,0 +1,16 @@
+[
+    {
+        "relation": [
+            "delegate_permission/common.handle_all_urls"
+        ],
+        "target": {
+            "namespace": "android_app",
+            "package_name": "chat.simplex.app",
+            "sha256_cert_fingerprints": [
+                "5E:3E:DC:C2:00:FB:A8:D5:F4:88:F3:CA:4C:32:5B:05:78:C5:6A:9C:03:A1:CC:B5:92:9C:D7:5C:7E:57:E2:4D",
+                "3C:52:C4:FD:3C:AD:1C:07:C9:B0:0A:70:80:E3:58:FA:B9:FE:FC:B8:AF:5A:EC:14:77:65:F1:6D:0F:21:AD:85",
+                "AE:C1:95:DC:FD:46:14:BD:3A:91:EC:26:D1:D5:14:C8:75:71:C5:CC:8D:CF:48:08:3F:92:83:14:3C:A2:B9:A6"
+            ]
+        }
+    }
+]
@@ -105,6 +105,13 @@
                    class="text-[16px] leading-[26px] tracking-[0.01em] nav-link-text text-black dark:text-white before:bg-black dark:before:bg-white">Server
                    information</span></a>
              </li>
+              <!-- <x-xftpConfig>
+              <li class="nav-link relative"><a href="/file"
+                  class="flex items-center justify-between gap-2 lg:py-5 whitespace-nowrap"><span
+                    class="text-[16px] leading-[26px] tracking-[0.01em] nav-link-text text-black dark:text-white before:bg-black dark:before:bg-white">File
+                    transfer</span></a>
+              </li>
+              </x-xftpConfig> -->
            </ul><a target="_blank" href="https://github.com/simplex-chat/simplex-chat#help-us-with-donations"
              class="whitespace-nowrap flex items-center gap-1 self-center text-white dark:text-black text-[16px] font-medium tracking-[0.02em] rounded-[34px] bg-primary-light dark:bg-primary-dark py-3 lg:py-2 px-20 lg:px-5 mb-16 lg:mb-0">Donate</a>
          </div>
@@ -223,11 +230,14 @@
            <table id="public-info">
              <tr class="text-grey-black dark:text-white text-base">
                <td>Server version:</td>
-                <td>${version}</td>
+                <td>${version}<x-commit> / <a href="${commitSourceCode}/commit/${commit}" target="_blank">${shortCommit}</a></x-commit></td>
              </tr>
              <tr class="text-grey-black dark:text-white text-base">
                <td>Source code:</td>
-                <td><a href="${sourceCode}" target="_blank">${sourceCode}</a></td>
+                <td>
+                  <x-sourceCode><a href="${sourceCode}" target="_blank">${sourceCode}</a></x-sourceCode>
+                  <x-noSourceCode>add to ${iniFileName} (required by <a href="https://github.com/simplex-chat/simplexmq/blob/stable/LICENSE" target="_blank">AGPLv3</a>)</x-noSourceCode>
+                </td>
              </tr>
              <x-website>
                <tr class="text-grey-black dark:text-white text-base">
@@ -314,6 +324,7 @@
            <h2 class="text-[30px] mb-[20px] leading-[28px] text-[#606C71] dark:text-white font-bold max-w-[475px]">
              Configuration</h2>
            <table id="config">
+              <x-smpConfig>
              <tr class="text-grey-black dark:text-white text-base">
                <td>Persistence:</td>
                <td>${persistence}</td>
@@ -334,6 +345,25 @@
                <td>Basic auth enabled:</td>
                <td>${basicAuthEnabled}</td>
              </tr>
+              </x-smpConfig>
+              <x-xftpConfig>
+              <tr class="text-grey-black dark:text-white text-base">
+                <td>File expiration:</td>
+                <td>${fileExpiration}</td>
+              </tr>
+              <tr class="text-grey-black dark:text-white text-base">
+                <td>Stats enabled:</td>
+                <td>${statsEnabled}</td>
+              </tr>
+              <tr class="text-grey-black dark:text-white text-base">
+                <td>New uploads allowed:</td>
+                <td>${newUploadsAllowed}</td>
+              </tr>
+              <tr class="text-grey-black dark:text-white text-base">
+                <td>Basic auth enabled:</td>
+                <td>${basicAuthEnabled}</td>
+              </tr>
+              </x-xftpConfig>
            </table>
          </div>
        </div>
@@ -142,8 +142,7 @@
    class="hidden xl:block h-screen pt-[66px] bg-white dark:bg-gradient-radial-mobile dark:lg:bg-gradient-radial">
    <div class="container m-auto h-full flex items-center justify-between px-5">
      <div class="flex flex-col items-start justify-center w-full">
-        <h1 class="text-[38px] leading-[43px] font-bold max-w-[500px] mb-[30px] primary-header-contact">You received a
-          1-time link to connect on SimpleX Chat</h1>
+        <h1 class="text-[38px] leading-[43px] font-bold max-w-[500px] mb-[30px] primary-header-contact">This is a one-time link of the SimpleX&nbsp;network user</h1>
        <h2
          class="text-[20px] leading-[28px] text-[#606C71] dark:text-white font-bold max-w-[475px] mb-[80px] secondary-header-contact">
          Scan the QR code with the SimpleX Chat app on your phone or tablet.</h2>
@@ -184,10 +183,8 @@
    class="block xl:hidden pt-[106px] py-[90px] bg-white dark:bg-gradient-radial-mobile dark:lg:bg-gradient-radial">
    <div class="container m-auto px-5">
      <div class="flex flex-col items-center">
-        <h1 class="text-[28px] font-bold text-center max-w-[602px] mb-[40px] primary-header-contact">You received a
-          1-time link to connect on SimpleX Chat</h1>
-        <p class="text-[20px] leading-[28px] text-grey-black dark:text-white font-medium mb-[30px]">To make a
-          connection:</p>
+        <h1 class="text-[28px] font-bold text-center max-w-[602px] mb-[40px] primary-header-contact">This is a one-time link of the SimpleX&nbsp;network user</h1>
+        <p class="text-[20px] leading-[28px] text-grey-black dark:text-white font-medium mb-[30px]">To make a connection:</p>
        <div
          class="flex flex-col justify-center items-center p-4 w-full max-w-[468px] min-h-[131px] rounded-[30px] border-[1px] border-[#A8B0B4] dark:border-white border-opacity-60 mb-6 relative">
          <p class="text-xl font-medium text-grey-black dark:text-white mb-4">Install SimpleX app</p>
@@ -506,13 +503,17 @@
    const url = window.location.href
    const messageElements = document.getElementsByClassName('primary-header-contact')

-    if (url.includes('/invitation')) {
-      for (let element of messageElements) {
-        element.textContent = 'You received a 1-time link to connect on SimpleX Chat'
-      }
-    } else {
-      for (let element of messageElements) {
-        element.textContent = 'You received an address to connect on SimpleX Chat'
+    for (let element of messageElements) {
+      if (url.includes('/g') || url.includes('&data=%7B%22groupLinkId%22%3A')) {
+        element.innerHTML = 'This is a public group address on SimpleX&nbsp;network'
+      } else if (url.includes('/a') || url.includes('/contact')) {
+        element.innerHTML = 'This is a public address of the SimpleX&nbsp;network user'
+      } else if (url.includes('/i') || url.includes('/invitation')) {
+        element.innerHTML = 'This is a one-time link of the SimpleX&nbsp;network user'
+      } else if (url.includes('/c')) {
+        element.innerHTML = 'This is a public channel address on SimpleX&nbsp;network'
+      } else if (url.includes('/r')) {
+        element.innerHTML = 'This is a chat relay address on SimpleX&nbsp;network'
      }
    }
  </script>
@@ -20,7 +20,18 @@
    parsedURI.pathname = "/" + action
    connURI = parsedURI.toString()
    console.log("connection URI: ", connURI)
-    mobileConnURIanchor.href = "simplex:" + parsedURI.pathname + parsedURI.hash
+    const hash = parsedURI.hash
+    const hostname = parsedURI.hostname
+    let appURI = "simplex:" + parsedURI.pathname
+    appURI += action.length > 1 // not short link
+              ? hash
+              : !hash.includes("?") // otherwise add server hostname
+              ? hash + "?h=" + hostname // no parameters
+              : !hash.includes("?h=") && !hash.includes("&h=")
+              ? hash + "&h=" + hostname // no "h" parameter
+              : hash.replace(/([?&])h=([^&]+)/, `$1h=${hostname},$2`) // add as the first hostname to "h" parameter
+    mobileConnURIanchor.href = appURI
+    console.log("app URI: ", appURI)
    connURIel.innerText = "/c " + connURI
    for (const connQRCode of connQRCodes) {
      try {
@@ -15,7 +15,6 @@ logCfg = LogConfig {lc_file = Nothing, lc_stderr = True}

 main :: IO ()
 main = do
-  setLogLevel LogInfo
  cfgPath <- getEnvPath "NTF_SERVER_CFG_PATH" defaultCfgPath
  logPath <- getEnvPath "NTF_SERVER_LOG_PATH" defaultLogPath
  withGlobalLogging logCfg $ ntfServerCLI cfgPath logPath
@@ -2,8 +2,9 @@ module Main where

 import Control.Logger.Simple
 import Simplex.Messaging.Server.CLI (getEnvPath)
-import Simplex.Messaging.Server.Main
-import qualified Static
+import Simplex.Messaging.Server.Main (smpServerCLI_)
+import Simplex.Messaging.Server.Web (serveStaticFiles, attachStaticFiles)
+import SMPWeb (smpGenerateSite)

 defaultCfgPath :: FilePath
 defaultCfgPath = "/etc/opt/simplex"
@@ -16,7 +17,6 @@ logCfg = LogConfig {lc_file = Nothing, lc_stderr = True}

 main :: IO ()
 main = do
-  setLogLevel LogDebug
  cfgPath <- getEnvPath "SMP_SERVER_CFG_PATH" defaultCfgPath
  logPath <- getEnvPath "SMP_SERVER_LOG_PATH" defaultLogPath
-  withGlobalLogging logCfg $ smpServerCLI_ Static.generateSite Static.serveStaticFiles Static.attachStaticFiles cfgPath logPath
+  withGlobalLogging logCfg $ smpServerCLI_ smpGenerateSite serveStaticFiles attachStaticFiles cfgPath logPath
@@ -0,0 +1,43 @@
+{-# LANGUAGE NamedFieldPuns #-}
+{-# LANGUAGE OverloadedStrings #-}
+
+module SMPWeb
+  ( smpGenerateSite,
+    serverInformation,
+  ) where
+
+import Data.ByteString (ByteString)
+import Data.String (fromString)
+import Web.Embedded (embeddedContent)
+import Simplex.Messaging.Encoding.String (strEncode)
+import Simplex.Messaging.Server.Information
+import Simplex.Messaging.Server.Main (simplexmqSource)
+import qualified Simplex.Messaging.Server.Web as Web
+import Simplex.Messaging.Server.Web (render, serverInfoSubsts, timedTTLText)
+import Simplex.Messaging.Transport.Client (TransportHost (..))
+
+smpGenerateSite :: ServerInformation -> Maybe TransportHost -> FilePath -> IO ()
+smpGenerateSite si onionHost path =
+  Web.generateSite embeddedContent (serverInformation si onionHost) smpLinkPages path
+
+smpLinkPages :: [String]
+smpLinkPages = ["contact", "invitation", "a", "c", "g", "r", "i"]
+
+serverInformation :: ServerInformation -> Maybe TransportHost -> ByteString
+serverInformation ServerInformation {config, information} onionHost = render (Web.indexHtml embeddedContent) substs
+  where
+    substs = [("smpConfig", Just "y"), ("xftpConfig", Nothing)] <> substConfig <> serverInfoSubsts simplexmqSource information <> [("onionHost", strEncode <$> onionHost), ("iniFileName", Just "smp-server.ini")]
+    substConfig =
+      [ ( "persistence",
+          Just $ case persistence config of
+            SPMMemoryOnly -> "In-memory only"
+            SPMQueues -> "Queues"
+            SPMMessages -> "Queues and messages"
+        ),
+        ("messageExpiration", Just $ maybe "Never" (fromString . timedTTLText) $ messageExpiration config),
+        ("statsEnabled", Just . yesNo $ statsEnabled config),
+        ("newQueuesAllowed", Just . yesNo $ newQueuesAllowed config),
+        ("basicAuthEnabled", Just . yesNo $ basicAuthEnabled config)
+      ]
+    yesNo True = "Yes"
+    yesNo False = "No"
@@ -1 +0,0 @@
-../link.html
@@ -1 +0,0 @@
-../link.html
@@ -1,221 +0,0 @@
-{-# LANGUAGE LambdaCase #-}
-{-# LANGUAGE NamedFieldPuns #-}
-{-# LANGUAGE OverloadedStrings #-}
-
-module Static where
-
-import Control.Logger.Simple
-import Control.Monad
-import Data.ByteString (ByteString)
-import qualified Data.ByteString.Char8 as B
-import Data.Char (toUpper)
-import Data.IORef (readIORef)
-import Data.Maybe (fromMaybe)
-import Data.String (fromString)
-import Data.Text.Encoding (encodeUtf8)
-import Network.Socket (getPeerName)
-import Network.Wai (Application)
-import qualified Network.Wai.Application.Static as S
-import qualified Network.Wai.Handler.Warp as W
-import qualified Network.Wai.Handler.Warp.Internal as WI
-import qualified Network.Wai.Handler.WarpTLS as WT
-import Simplex.Messaging.Encoding.String (strEncode)
-import Simplex.Messaging.Server (AttachHTTP)
-import Simplex.Messaging.Server.Information
-import Simplex.Messaging.Server.Main (EmbeddedWebParams (..), WebHttpsParams (..))
-import Simplex.Messaging.Transport (simplexMQVersion)
-import Simplex.Messaging.Transport.Client (TransportHost (..))
-import Simplex.Messaging.Util (tshow)
-import Static.Embedded as E
-import System.Directory (createDirectoryIfMissing)
-import System.FilePath
-import UnliftIO.Concurrent (forkFinally)
-import UnliftIO.Exception (bracket, finally)
-
-serveStaticFiles :: EmbeddedWebParams -> IO ()
-serveStaticFiles EmbeddedWebParams {webStaticPath, webHttpPort, webHttpsParams} = do
-  forM_ webHttpPort $ \port -> flip forkFinally (\e -> logError $ "HTTP server crashed: " <> tshow e) $ do
-    logInfo $ "Serving static site on port " <> tshow port
-    W.runSettings (mkSettings port) (S.staticApp $ S.defaultFileServerSettings webStaticPath)
-  forM_ webHttpsParams $ \WebHttpsParams {port, cert, key} -> flip forkFinally (\e -> logError $ "HTTPS server crashed: " <> tshow e) $ do
-    logInfo $ "Serving static site on port " <> tshow port <> " (TLS)"
-    WT.runTLS (WT.tlsSettings cert key) (mkSettings port) app
-  where
-    app = staticFiles webStaticPath
-    mkSettings port = W.setPort port warpSettings
-
-- | Prepare context and prepare HTTP handler for TLS connections that already passed TLS.handshake and ALPN check.
-attachStaticFiles :: FilePath -> (AttachHTTP -> IO ()) -> IO ()
-attachStaticFiles path action =
-  -- Initialize global internal state for http server.
-  WI.withII warpSettings $ \ii -> do
-    action $ \socket cxt -> do
-      -- Initialize internal per-connection resources.
-      addr <- getPeerName socket
-      withConnection addr cxt $ \(conn, transport) ->
-        withTimeout ii conn $ \th ->
-          -- Run Warp connection handler to process HTTP requests for static files.
-          WI.serveConnection conn ii th addr transport warpSettings app
-  where
-    app = staticFiles path
-    -- from warp-tls
-    withConnection socket cxt = bracket (WT.attachConn socket cxt) (terminate . fst)
-    -- from warp
-    withTimeout ii conn =
-      bracket
-        (WI.registerKillThread (WI.timeoutManager ii) (WI.connClose conn))
-        WI.cancel
-    -- shared clean up
-    terminate conn = WI.connClose conn `finally` (readIORef (WI.connWriteBuffer conn) >>= WI.bufFree)
-
-warpSettings :: W.Settings
-warpSettings = W.setGracefulShutdownTimeout (Just 1) W.defaultSettings
-
-staticFiles :: FilePath -> Application
-staticFiles root = S.staticApp settings
-  where
-    settings = (S.defaultFileServerSettings root)
-      { S.ssListing = Nothing
-      }
-
-generateSite :: ServerInformation -> Maybe TransportHost -> FilePath -> IO ()
-generateSite si onionHost sitePath = do
-  createDirectoryIfMissing True sitePath
-  B.writeFile (sitePath </> "index.html") $ serverInformation si onionHost
-  createDirectoryIfMissing True $ sitePath </> "media"
-  forM_ E.mediaContent $ \(path, bs) -> B.writeFile (sitePath </> "media" </> path) bs
-  createDirectoryIfMissing True $ sitePath </> "contact"
-  B.writeFile (sitePath </> "contact" </> "index.html") E.linkHtml
-  createDirectoryIfMissing True $ sitePath </> "invitation"
-  B.writeFile (sitePath </> "invitation" </> "index.html") E.linkHtml
-  logInfo $ "Generated static site contents at " <> tshow sitePath
-
-serverInformation :: ServerInformation -> Maybe TransportHost -> ByteString
-serverInformation ServerInformation {config, information} onionHost = render E.indexHtml substs
-  where
-    substs = substConfig <> maybe [] substInfo information <> [("onionHost", strEncode <$> onionHost)]
-    substConfig =
-      [ ( "persistence",
-          Just $ case persistence config of
-            SPMMemoryOnly -> "In-memory only"
-            SPMQueues -> "Queues"
-            SPMMessages -> "Queues and messages"
-        ),
-        ("messageExpiration", Just $ maybe "Never" (fromString . timedTTLText) $ messageExpiration config),
-        ("statsEnabled", Just . yesNo $ statsEnabled config),
-        ("newQueuesAllowed", Just . yesNo $ newQueuesAllowed config),
-        ("basicAuthEnabled", Just . yesNo $ basicAuthEnabled config)
-      ]
-    yesNo True = "Yes"
-    yesNo False = "No"
-    substInfo spi =
-      concat
-        [ basic,
-          maybe [("usageConditions", Nothing), ("usageAmendments", Nothing)] conds (usageConditions spi),
-          maybe [("operator", Nothing)] operatorE (operator spi),
-          maybe [("admin", Nothing)] admin (adminContacts spi),
-          maybe [("complaints", Nothing)] complaints (complaintsContacts spi),
-          maybe [("hosting", Nothing)] hostingE (hosting spi),
-          server
-        ]
-      where
-        basic =
-          [ ("sourceCode", Just . encodeUtf8 $ sourceCode spi),
-            ("version", Just $ B.pack simplexMQVersion),
-            ("website", encodeUtf8 <$> website spi)
-          ]
-        conds ServerConditions {conditions, amendments} =
-          [ ("usageConditions", Just $ encodeUtf8 conditions),
-            ("usageAmendments", encodeUtf8 <$> amendments)
-          ]
-        operatorE Entity {name, country} =
-          [ ("operator", Just ""),
-            ("operatorEntity", Just $ encodeUtf8 name),
-            ("operatorCountry", encodeUtf8 <$> country)
-          ]
-        admin ServerContactAddress {simplex, email, pgp} =
-          [ ("admin", Just ""),
-            ("adminSimplex", strEncode <$> simplex),
-            ("adminEmail", encodeUtf8 <$> email),
-            ("adminPGP", encodeUtf8 . pkURI <$> pgp),
-            ("adminPGPFingerprint", encodeUtf8 . pkFingerprint <$> pgp)
-          ]
-        complaints ServerContactAddress {simplex, email, pgp} =
-          [ ("complaints", Just ""),
-            ("complaintsSimplex", strEncode <$> simplex),
-            ("complaintsEmail", encodeUtf8 <$> email),
-            ("complaintsPGP", encodeUtf8 . pkURI <$> pgp),
-            ("complaintsPGPFingerprint", encodeUtf8 . pkFingerprint <$> pgp)
-          ]
-        hostingE Entity {name, country} =
-          [ ("hosting", Just ""),
-            ("hostingEntity", Just $ encodeUtf8 name),
-            ("hostingCountry", encodeUtf8 <$> country)
-          ]
-        server =
-          [ ("serverCountry", encodeUtf8 <$> serverCountry spi),
-            ("hostingType",  (\s -> maybe s (\(c, rest) -> toUpper c `B.cons` rest) $ B.uncons s) . strEncode <$> hostingType spi)
-          ]
-
-- Copy-pasted from simplex-chat Simplex.Chat.Types.Preferences
-{-# INLINE timedTTLText #-}
-timedTTLText :: (Integral i, Show i) => i -> String
-timedTTLText 0 = "0 sec"
-timedTTLText ttl = do
-  let (m', s) = ttl `quotRem` 60
-      (h', m) = m' `quotRem` 60
-      (d', h) = h' `quotRem` 24
-      (mm, d) = d' `quotRem` 30
-  unwords $
-    [mms mm | mm /= 0]
-      <> [ds d | d /= 0]
-      <> [hs h | h /= 0]
-      <> [ms m | m /= 0]
-      <> [ss s | s /= 0]
-  where
-    ss s = show s <> " sec"
-    ms m = show m <> " min"
-    hs 1 = "1 hour"
-    hs h = show h <> " hours"
-    ds 1 = "1 day"
-    ds 7 = "1 week"
-    ds 14 = "2 weeks"
-    ds d = show d <> " days"
-    mms 1 = "1 month"
-    mms mm = show mm <> " months"
-
-- | Rewrite source with provided substitutions
-render :: ByteString -> [(ByteString, Maybe ByteString)] -> ByteString
-render src = \case
-  [] -> src
-  (label, content') : rest -> render (section_ label content' src) rest
-
-- | Rewrite section content inside @<x-label>...</x-label>@ markers.
-- Markers are always removed when found. Closing marker is mandatory.
-- If content is absent, whole section is removed.
-- Section content is delegated to `item_`. If no sections found, the whole source is delegated.
-section_ :: ByteString -> Maybe ByteString -> ByteString -> ByteString
-section_ label content' src =
-  case B.breakSubstring startMarker src of
-    (_, "") -> item_ label (fromMaybe "" content') src -- no section, just replace items
-    (before, afterStart') ->
-      -- found section start, search for end too
-      case B.breakSubstring endMarker $ B.drop (B.length startMarker) afterStart' of
-        (_, "") -> error $ "missing section end: " <> show endMarker
-        (inside, next') ->
-          let next = B.drop (B.length endMarker) next'
-           in case content' of
-                Nothing -> before <> next -- collapse section
-                Just content -> before <> item_ label content inside <> section_ label content' next
-  where
-    startMarker = "<x-" <> label <> ">"
-    endMarker = "</x-" <> label <> ">"
-
-- | Replace all occurences of @${label}@ with provided content.
-item_ :: ByteString -> ByteString -> ByteString -> ByteString
-item_ label content' src =
-  case B.breakSubstring marker src of
-    (done, "") -> done
-    (before, after') -> before <> content' <> item_ label content' (B.drop (B.length marker) after')
-  where
-    marker = "${" <> label <> "}"
@@ -1,15 +0,0 @@
-{-# LANGUAGE TemplateHaskell #-}
-
-module Static.Embedded where
-
-import Data.FileEmbed (embedDir, embedFile)
-import Data.ByteString (ByteString)
-
-indexHtml :: ByteString
-indexHtml = $(embedFile "apps/smp-server/static/index.html")
-
-linkHtml :: ByteString
-linkHtml = $(embedFile "apps/smp-server/static/link.html")
-
-mediaContent :: [(FilePath, ByteString)]
-mediaContent = $(embedDir "apps/smp-server/static/media/")
@@ -1,8 +1,10 @@
 module Main where

 import Control.Logger.Simple
+import Simplex.FileTransfer.Server.Main (xftpServerCLI_)
 import Simplex.Messaging.Server.CLI (getEnvPath)
-import Simplex.FileTransfer.Server.Main
+import Simplex.Messaging.Server.Web (serveStaticFiles)
+import XFTPWeb (xftpGenerateSite)

 defaultCfgPath :: FilePath
 defaultCfgPath = "/etc/opt/simplex-xftp"
@@ -18,4 +20,4 @@ main = do
  setLogLevel LogDebug -- change to LogError in production
  cfgPath <- getEnvPath "XFTP_SERVER_CFG_PATH" defaultCfgPath
  logPath <- getEnvPath "XFTP_SERVER_LOG_PATH" defaultLogPath
-  withGlobalLogging logCfg $ xftpServerCLI cfgPath logPath
+  withGlobalLogging logCfg $ xftpServerCLI_ xftpGenerateSite serveStaticFiles cfgPath logPath
@@ -0,0 +1,67 @@
+{-# LANGUAGE NamedFieldPuns #-}
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE TemplateHaskell #-}
+
+module XFTPWeb
+  ( xftpGenerateSite,
+    xftpServerInformation,
+  ) where
+
+import Control.Monad (forM_)
+import qualified Data.ByteString.Char8 as B
+import Data.ByteString (ByteString)
+import Data.FileEmbed (embedDir, embedFile)
+import Data.Maybe (isJust)
+import Data.String (fromString)
+import Web.Embedded (embeddedContent)
+import Simplex.FileTransfer.Server.Env (XFTPServerConfig (..))
+import Simplex.Messaging.Encoding.String (strEncode)
+import Simplex.Messaging.Server.Expiration (ExpirationConfig (..))
+import Simplex.Messaging.Server.Information (ServerPublicInfo)
+import Simplex.Messaging.Server.Main (simplexmqSource)
+import qualified Simplex.Messaging.Server.Web as Web
+import Simplex.Messaging.Server.Web (render, serverInfoSubsts, timedTTLText)
+import Simplex.Messaging.Transport.Client (TransportHost (..))
+import System.Directory (createDirectoryIfMissing)
+import System.FilePath ((</>))
+
+xftpWebContent :: [(FilePath, ByteString)]
+xftpWebContent = $(embedDir "apps/xftp-server/static/xftp-web-bundle/")
+
+xftpMediaContent :: [(FilePath, ByteString)]
+xftpMediaContent = $(embedDir "apps/xftp-server/static/media/")
+
+xftpFilePageHtml :: ByteString
+xftpFilePageHtml = $(embedFile "apps/xftp-server/static/file.html")
+
+xftpGenerateSite :: XFTPServerConfig s -> Maybe ServerPublicInfo -> Maybe TransportHost -> FilePath -> IO ()
+xftpGenerateSite cfg info onionHost path = do
+  let substs = xftpSubsts cfg info onionHost
+  Web.generateSite embeddedContent (render (Web.indexHtml embeddedContent) substs) [] path
+  let xftpDir = path </> "xftp-web-bundle"
+      mediaDir = path </> "media"
+      fileDir = path </> "file"
+  filePage xftpDir xftpWebContent
+  filePage mediaDir xftpMediaContent
+  createDirectoryIfMissing True fileDir
+  B.writeFile (fileDir </> "index.html") $ render xftpFilePageHtml substs
+  where
+    filePage dir content_ = do
+      createDirectoryIfMissing True dir
+      forM_ content_ $ \(fp, content) -> B.writeFile (dir </> fp) content
+
+xftpServerInformation :: XFTPServerConfig s -> Maybe ServerPublicInfo -> Maybe TransportHost -> ByteString
+xftpServerInformation cfg info onionHost = render (Web.indexHtml embeddedContent) (xftpSubsts cfg info onionHost)
+
+xftpSubsts :: XFTPServerConfig s -> Maybe ServerPublicInfo -> Maybe TransportHost -> [(ByteString, Maybe ByteString)]
+xftpSubsts XFTPServerConfig {fileExpiration, logStatsInterval, allowNewFiles, newFileBasicAuth} information onionHost =
+  [("smpConfig", Nothing), ("xftpConfig", Just "y")] <> substConfig <> serverInfoSubsts simplexmqSource information <> [("onionHost", strEncode <$> onionHost), ("iniFileName", Just "file-server.ini")]
+  where
+    substConfig =
+      [ ("fileExpiration", Just $ maybe "Never" (fromString . timedTTLText . ttl) fileExpiration),
+        ("statsEnabled", Just . yesNo $ isJust logStatsInterval),
+        ("newUploadsAllowed", Just . yesNo $ allowNewFiles),
+        ("basicAuthEnabled", Just . yesNo $ isJust newFileBasicAuth)
+      ]
+    yesNo True = "Yes"
+    yesNo False = "No"
@@ -0,0 +1,115 @@
+<svg width="440" height="520" viewBox="-20 0 440 520" fill="none" xmlns="http://www.w3.org/2000/svg">
+  <!-- Sender browser -->
+  <rect x="120" y="16" width="160" height="56" rx="10" stroke="#70F0F9" stroke-width="1.5"/>
+  <text x="200" y="40" text-anchor="middle" font-family="system-ui, sans-serif" font-size="13" font-weight="600" fill="#70F0F9">Sender's browser</text>
+  <text x="200" y="56" text-anchor="middle" font-family="system-ui, sans-serif" font-size="11" fill="rgba(112,240,249,0.7)">encrypts file</text>
+
+  <!-- Arrow down from sender to chunks -->
+  <line x1="200" y1="72" x2="200" y2="120" stroke="#70F0F9" stroke-width="1.5" marker-end="url(#arrowC)"/>
+
+  <!-- Chunks row -->
+  <rect x="112" y="120" width="176" height="40" rx="8" fill="none" stroke="#70F0F9" stroke-width="1" stroke-dasharray="4 3"/>
+  <text x="200" y="145" text-anchor="middle" font-family="system-ui, sans-serif" font-size="12" fill="#70F0F9">encrypted chunks</text>
+
+  <!-- Arrows from chunks to routers -->
+  <line x1="152" y1="160" x2="80" y2="220" stroke="#70F0F9" stroke-width="1.5" marker-end="url(#arrowC)"/>
+  <line x1="200" y1="160" x2="200" y2="220" stroke="#70F0F9" stroke-width="1.5" marker-end="url(#arrowC)"/>
+  <line x1="248" y1="160" x2="320" y2="220" stroke="#70F0F9" stroke-width="1.5" marker-end="url(#arrowC)"/>
+
+  <!-- Router 1 (SimpleX) -->
+  <rect x="20" y="220" width="120" height="56" rx="6" fill="none" stroke="#70F0F9" stroke-width="1.5"/>
+  <g transform="translate(28, 227)">
+    <rect width="14" height="4" rx="1" fill="rgba(112,240,249,0.5)"/>
+    <rect y="6" width="14" height="4" rx="1" fill="rgba(112,240,249,0.5)"/>
+    <rect y="12" width="14" height="4" rx="1" fill="rgba(112,240,249,0.5)"/>
+    <circle cx="11" cy="2" r="1" fill="#70F0F9"/>
+    <circle cx="11" cy="8" r="1" fill="#70F0F9"/>
+    <circle cx="11" cy="14" r="1" fill="#70F0F9"/>
+  </g>
+  <text x="80" y="244" text-anchor="middle" font-family="system-ui, sans-serif" font-size="11" font-weight="600" fill="#70F0F9">SimpleX</text>
+  <text x="80" y="258" text-anchor="middle" font-family="system-ui, sans-serif" font-size="9" fill="rgba(112,240,249,0.7)">XFTP router</text>
+
+  <!-- Router 2 (Flux) -->
+  <rect x="155" y="220" width="90" height="56" rx="6" fill="none" stroke="#70F0F9" stroke-width="1.5"/>
+  <g transform="translate(163, 227)">
+    <rect width="14" height="4" rx="1" fill="rgba(112,240,249,0.5)"/>
+    <rect y="6" width="14" height="4" rx="1" fill="rgba(112,240,249,0.5)"/>
+    <rect y="12" width="14" height="4" rx="1" fill="rgba(112,240,249,0.5)"/>
+    <circle cx="11" cy="2" r="1" fill="#70F0F9"/>
+    <circle cx="11" cy="8" r="1" fill="#70F0F9"/>
+    <circle cx="11" cy="14" r="1" fill="#70F0F9"/>
+  </g>
+  <text x="200" y="244" text-anchor="middle" font-family="system-ui, sans-serif" font-size="11" font-weight="600" fill="#70F0F9">Flux</text>
+  <text x="200" y="258" text-anchor="middle" font-family="system-ui, sans-serif" font-size="9" fill="rgba(112,240,249,0.7)">XFTP router</text>
+
+  <!-- Router 3 (SimpleX) -->
+  <rect x="260" y="220" width="120" height="56" rx="6" fill="none" stroke="#70F0F9" stroke-width="1.5"/>
+  <g transform="translate(268, 227)">
+    <rect width="14" height="4" rx="1" fill="rgba(112,240,249,0.5)"/>
+    <rect y="6" width="14" height="4" rx="1" fill="rgba(112,240,249,0.5)"/>
+    <rect y="12" width="14" height="4" rx="1" fill="rgba(112,240,249,0.5)"/>
+    <circle cx="11" cy="2" r="1" fill="#70F0F9"/>
+    <circle cx="11" cy="8" r="1" fill="#70F0F9"/>
+    <circle cx="11" cy="14" r="1" fill="#70F0F9"/>
+  </g>
+  <text x="320" y="244" text-anchor="middle" font-family="system-ui, sans-serif" font-size="11" font-weight="600" fill="#70F0F9">SimpleX</text>
+  <text x="320" y="258" text-anchor="middle" font-family="system-ui, sans-serif" font-size="9" fill="rgba(112,240,249,0.7)">XFTP router</text>
+
+  <!-- Arrows from routers down -->
+  <line x1="80" y1="276" x2="152" y2="336" stroke="#70F0F9" stroke-width="1.5" marker-end="url(#arrowC)"/>
+  <line x1="200" y1="276" x2="200" y2="336" stroke="#70F0F9" stroke-width="1.5" marker-end="url(#arrowC)"/>
+  <line x1="320" y1="276" x2="248" y2="336" stroke="#70F0F9" stroke-width="1.5" marker-end="url(#arrowC)"/>
+
+  <!-- Re-encrypt label -->
+  <text x="330" y="310" text-anchor="start" font-family="system-ui, sans-serif" font-size="10" fill="rgba(112,240,249,0.7)">re-encrypted</text>
+  <text x="330" y="322" text-anchor="start" font-family="system-ui, sans-serif" font-size="10" fill="rgba(112,240,249,0.7)">per recipient</text>
+
+  <!-- Chunks row (download) -->
+  <rect x="112" y="336" width="176" height="40" rx="8" fill="none" stroke="#70F0F9" stroke-width="1" stroke-dasharray="4 3"/>
+  <text x="200" y="361" text-anchor="middle" font-family="system-ui, sans-serif" font-size="12" fill="#70F0F9">encrypted chunks</text>
+
+  <!-- Arrow down to recipient -->
+  <line x1="200" y1="376" x2="200" y2="424" stroke="#70F0F9" stroke-width="1.5" marker-end="url(#arrowC)"/>
+
+  <!-- Recipient browser -->
+  <rect x="120" y="424" width="160" height="56" rx="10" stroke="#70F0F9" stroke-width="1.5"/>
+  <text x="200" y="448" text-anchor="middle" font-family="system-ui, sans-serif" font-size="13" font-weight="600" fill="#70F0F9">Recipient's browser</text>
+  <text x="200" y="464" text-anchor="middle" font-family="system-ui, sans-serif" font-size="11" fill="rgba(112,240,249,0.7)">decrypts file</text>
+
+  <!-- Key path (dashed, side) -->
+  <path d="M120 44 L8 44 L8 452 L120 452" stroke="#70F0F9" stroke-width="1.5" stroke-dasharray="6 4" fill="none" marker-end="url(#arrowC)"/>
+  <text x="-6" y="240" text-anchor="middle" font-family="system-ui, sans-serif" font-size="10" fill="#70F0F9" transform="rotate(-90 -6 240)">key in URL fragment - never sent to page server or data router</text>
+
+
+  <!-- Closed padlock: encryption (between sender and chunks) -->
+  <g transform="translate(192, 88)">
+    <path d="M4,7 V4 C4,1.2 12,1.2 12,4 V7" stroke="#60a5fa" stroke-width="1.5" fill="none" stroke-linecap="round"/>
+    <rect x="2" y="7" width="12" height="9" rx="2" fill="#60a5fa"/>
+    <circle cx="8" cy="12" r="1.2" fill="#0B2A59"/>
+  </g>
+
+  <!-- Open padlock: decryption (between chunks and recipient) -->
+  <g transform="translate(192, 392)">
+    <path d="M4,7 V4 C4,1.2 12,1.2 12,4 V2" stroke="#60a5fa" stroke-width="1.5" fill="none" stroke-linecap="round"/>
+    <rect x="2" y="7" width="12" height="9" rx="2" fill="#60a5fa"/>
+    <circle cx="8" cy="12" r="1.2" fill="#0B2A59"/>
+  </g>
+
+  <!-- Key icon on dashed line -->
+  <g transform="translate(8, 410)">
+    <circle cx="0" cy="0" r="6" stroke="#FBBF24" stroke-width="2" fill="#FBBF24"/>
+    <circle cx="0" cy="0" r="2" fill="#0B2A59"/>
+    <line x1="6" y1="0" x2="16" y2="0" stroke="#FBBF24" stroke-width="2"/>
+    <line x1="14" y1="0" x2="14" y2="4" stroke="#FBBF24" stroke-width="2"/>
+    <line x1="11" y1="0" x2="11" y2="3.5" stroke="#FBBF24" stroke-width="2"/>
+  </g>
+
+  <!-- Annotation: no shared IDs -->
+  <text x="200" y="510" text-anchor="middle" font-family="system-ui, sans-serif" font-size="10" fill="rgba(112,240,249,0.7)">Each file fragment uses unique anonymous credentials - no shared identifiers</text>
+
+  <defs>
+    <marker id="arrowC" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="6" markerHeight="6" orient="auto-start-reverse">
+      <path d="M 0 0 L 10 5 L 0 10 z" fill="#70F0F9"/>
+    </marker>
+  </defs>
+</svg>
@@ -0,0 +1,130 @@
+<svg width="440" height="520" viewBox="-20 0 440 520" fill="none" xmlns="http://www.w3.org/2000/svg">
+  <!-- Sender browser -->
+  <rect x="120" y="16" width="160" height="56" rx="10" fill="url(#gBox)" stroke="#606C71" stroke-width="1.5"/>
+  <text x="200" y="40" text-anchor="middle" font-family="system-ui, sans-serif" font-size="13" font-weight="600" fill="#fff">Sender's browser</text>
+  <text x="200" y="56" text-anchor="middle" font-family="system-ui, sans-serif" font-size="11" fill="rgba(255,255,255,0.8)">encrypts file</text>
+
+  <!-- Arrow down from sender to chunks -->
+  <line x1="200" y1="72" x2="200" y2="120" stroke="#606C71" stroke-width="1.5" marker-end="url(#arrowG)"/>
+
+  <!-- Chunks row -->
+  <rect x="112" y="120" width="176" height="40" rx="8" fill="#f0f7ff" stroke="#0053D0" stroke-width="1" stroke-dasharray="4 3"/>
+  <text x="200" y="145" text-anchor="middle" font-family="system-ui, sans-serif" font-size="12" fill="#0053D0">encrypted chunks</text>
+
+  <!-- Arrows from chunks to routers -->
+  <line x1="152" y1="160" x2="80" y2="220" stroke="#606C71" stroke-width="1.5" marker-end="url(#arrowG)"/>
+  <line x1="200" y1="160" x2="200" y2="220" stroke="#606C71" stroke-width="1.5" marker-end="url(#arrowG)"/>
+  <line x1="248" y1="160" x2="320" y2="220" stroke="#606C71" stroke-width="1.5" marker-end="url(#arrowG)"/>
+
+  <!-- Router 1 (SimpleX) -->
+  <rect x="20" y="220" width="120" height="56" rx="6" fill="#f0f4f8" stroke="#606C71" stroke-width="1.5"/>
+  <g transform="translate(28, 227)">
+    <rect width="14" height="4" rx="1" fill="#606C71"/>
+    <rect y="6" width="14" height="4" rx="1" fill="#606C71"/>
+    <rect y="12" width="14" height="4" rx="1" fill="#606C71"/>
+    <circle cx="11" cy="2" r="1" fill="#53C1FF"/>
+    <circle cx="11" cy="8" r="1" fill="#53C1FF"/>
+    <circle cx="11" cy="14" r="1" fill="#53C1FF"/>
+  </g>
+  <text x="80" y="244" text-anchor="middle" font-family="system-ui, sans-serif" font-size="11" font-weight="600" fill="#3F484B">SimpleX</text>
+  <text x="80" y="258" text-anchor="middle" font-family="system-ui, sans-serif" font-size="9" fill="#606C71">XFTP router</text>
+
+  <!-- Router 2 (Flux) -->
+  <rect x="155" y="220" width="90" height="56" rx="6" fill="#f0f4f8" stroke="#606C71" stroke-width="1.5"/>
+  <g transform="translate(163, 227)">
+    <rect width="14" height="4" rx="1" fill="#606C71"/>
+    <rect y="6" width="14" height="4" rx="1" fill="#606C71"/>
+    <rect y="12" width="14" height="4" rx="1" fill="#606C71"/>
+    <circle cx="11" cy="2" r="1" fill="#53C1FF"/>
+    <circle cx="11" cy="8" r="1" fill="#53C1FF"/>
+    <circle cx="11" cy="14" r="1" fill="#53C1FF"/>
+  </g>
+  <text x="200" y="244" text-anchor="middle" font-family="system-ui, sans-serif" font-size="11" font-weight="600" fill="#3F484B">Flux</text>
+  <text x="200" y="258" text-anchor="middle" font-family="system-ui, sans-serif" font-size="9" fill="#606C71">XFTP router</text>
+
+  <!-- Router 3 (SimpleX) -->
+  <rect x="260" y="220" width="120" height="56" rx="6" fill="#f0f4f8" stroke="#606C71" stroke-width="1.5"/>
+  <g transform="translate(268, 227)">
+    <rect width="14" height="4" rx="1" fill="#606C71"/>
+    <rect y="6" width="14" height="4" rx="1" fill="#606C71"/>
+    <rect y="12" width="14" height="4" rx="1" fill="#606C71"/>
+    <circle cx="11" cy="2" r="1" fill="#53C1FF"/>
+    <circle cx="11" cy="8" r="1" fill="#53C1FF"/>
+    <circle cx="11" cy="14" r="1" fill="#53C1FF"/>
+  </g>
+  <text x="320" y="244" text-anchor="middle" font-family="system-ui, sans-serif" font-size="11" font-weight="600" fill="#3F484B">SimpleX</text>
+  <text x="320" y="258" text-anchor="middle" font-family="system-ui, sans-serif" font-size="9" fill="#606C71">XFTP router</text>
+
+  <!-- Arrows from routers down -->
+  <line x1="80" y1="276" x2="152" y2="336" stroke="#606C71" stroke-width="1.5" marker-end="url(#arrowG)"/>
+  <line x1="200" y1="276" x2="200" y2="336" stroke="#606C71" stroke-width="1.5" marker-end="url(#arrowG)"/>
+  <line x1="320" y1="276" x2="248" y2="336" stroke="#606C71" stroke-width="1.5" marker-end="url(#arrowG)"/>
+
+  <!-- Re-encrypt label -->
+  <text x="330" y="310" text-anchor="start" font-family="system-ui, sans-serif" font-size="10" fill="#606C71">re-encrypted</text>
+  <text x="330" y="322" text-anchor="start" font-family="system-ui, sans-serif" font-size="10" fill="#606C71">per recipient</text>
+
+  <!-- Chunks row (download) -->
+  <rect x="112" y="336" width="176" height="40" rx="8" fill="#f0f7ff" stroke="#0053D0" stroke-width="1" stroke-dasharray="4 3"/>
+  <text x="200" y="361" text-anchor="middle" font-family="system-ui, sans-serif" font-size="12" fill="#0053D0">encrypted chunks</text>
+
+  <!-- Arrow down to recipient -->
+  <line x1="200" y1="376" x2="200" y2="424" stroke="#606C71" stroke-width="1.5" marker-end="url(#arrowG)"/>
+
+  <!-- Recipient browser -->
+  <rect x="120" y="424" width="160" height="56" rx="10" fill="url(#gBox)" stroke="#606C71" stroke-width="1.5"/>
+  <text x="200" y="448" text-anchor="middle" font-family="system-ui, sans-serif" font-size="13" font-weight="600" fill="#fff">Recipient's browser</text>
+  <text x="200" y="464" text-anchor="middle" font-family="system-ui, sans-serif" font-size="11" fill="rgba(255,255,255,0.8)">decrypts file</text>
+
+  <!-- Key path (dashed, side) -->
+  <path d="M120 44 L8 44 L8 452 L120 452" stroke="#0053D0" stroke-width="1.5" stroke-dasharray="6 4" fill="none" marker-end="url(#arrowB)"/>
+  <text x="-6" y="240" text-anchor="middle" font-family="system-ui, sans-serif" font-size="10" fill="#0053D0" transform="rotate(-90 -6 240)">key in URL fragment - never sent to page server or data router</text>
+
+
+  <!-- Closed padlock: encryption (between sender and chunks) -->
+  <g transform="translate(192, 88)">
+    <path d="M4,7 V4 C4,1.2 12,1.2 12,4 V7" stroke="#0053D0" stroke-width="1.5" fill="none" stroke-linecap="round"/>
+    <rect x="2" y="7" width="12" height="9" rx="2" fill="#0053D0"/>
+    <circle cx="8" cy="12" r="1.2" fill="#fff"/>
+  </g>
+
+  <!-- Open padlock: decryption (between chunks and recipient) -->
+  <g transform="translate(192, 392)">
+    <path d="M4,7 V4 C4,1.2 12,1.2 12,4 V2" stroke="#0053D0" stroke-width="1.5" fill="none" stroke-linecap="round"/>
+    <rect x="2" y="7" width="12" height="9" rx="2" fill="#0053D0"/>
+    <circle cx="8" cy="12" r="1.2" fill="#fff"/>
+  </g>
+
+  <!-- Key icon on dashed line -->
+  <g transform="translate(8, 410)">
+    <circle cx="0" cy="0" r="6" stroke="#D97706" stroke-width="2" fill="#D97706"/>
+    <circle cx="0" cy="0" r="2" fill="#fff"/>
+    <line x1="6" y1="0" x2="16" y2="0" stroke="#D97706" stroke-width="2"/>
+    <line x1="14" y1="0" x2="14" y2="4" stroke="#D97706" stroke-width="2"/>
+    <line x1="11" y1="0" x2="11" y2="3.5" stroke="#D97706" stroke-width="2"/>
+  </g>
+
+  <!-- Annotation: no shared IDs -->
+  <text x="200" y="510" text-anchor="middle" font-family="system-ui, sans-serif" font-size="10" fill="#606C71">Each file fragment uses unique anonymous credentials - no shared identifiers</text>
+
+  <defs>
+    <linearGradient id="gBox" x1="120" y1="16" x2="280" y2="72" gradientUnits="userSpaceOnUse">
+      <stop stop-color="#0053D0"/>
+      <stop offset="1" stop-color="#53C1FF"/>
+    </linearGradient>
+    <linearGradient id="gSrv1" x1="20" y1="220" x2="140" y2="276" gradientUnits="userSpaceOnUse">
+      <stop stop-color="#0053D0"/>
+      <stop offset="1" stop-color="#53C1FF"/>
+    </linearGradient>
+    <linearGradient id="gSrv2" x1="155" y1="220" x2="245" y2="276" gradientUnits="userSpaceOnUse">
+      <stop stop-color="#0053D0"/>
+      <stop offset="1" stop-color="#53C1FF"/>
+    </linearGradient>
+    <marker id="arrowG" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="6" markerHeight="6" orient="auto-start-reverse">
+      <path d="M 0 0 L 10 5 L 0 10 z" fill="#606C71"/>
+    </marker>
+    <marker id="arrowB" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="6" markerHeight="6" orient="auto-start-reverse">
+      <path d="M 0 0 L 10 5 L 0 10 z" fill="#0053D0"/>
+    </marker>
+  </defs>
+</svg>
@@ -0,0 +1,145 @@
+#app, [data-xftp-app] {
+  font-family: system-ui, -apple-system, sans-serif;
+  color: #333;
+  width: 100%;
+  max-width: 480px;
+  padding: 16px;
+  box-sizing: border-box;
+  --xftp-ring-fg: #3b82f6;
+}
+
+:is(#app, [data-xftp-app]) .card {
+  background: #fff;
+  border-radius: 12px;
+  padding: 32px 24px;
+  box-shadow: 0 1px 3px rgba(0,0,0,.1);
+  text-align: center;
+}
+
+:is(#app, [data-xftp-app]) h1 {
+  font-size: 1.25rem;
+  font-weight: 600;
+  margin-bottom: 24px;
+}
+
+:is(#app, [data-xftp-app]) .stage { margin-top: 16px; }
+
+/* Drop zone */
+:is(#app, [data-xftp-app]) .drop-zone {
+  border: 2px dashed #ccc;
+  border-radius: 8px;
+  padding: 32px 16px;
+  transition: border-color .15s, background .15s;
+}
+:is(#app, [data-xftp-app]) .drop-zone.drag-over {
+  border-color: #3b82f6;
+  background: #eff6ff;
+}
+
+/* Buttons */
+:is(#app, [data-xftp-app]) .btn {
+  display: inline-block;
+  padding: 10px 24px;
+  border: none;
+  border-radius: 6px;
+  background: #3b82f6;
+  color: #fff;
+  font-size: .9rem;
+  font-weight: 500;
+  cursor: pointer;
+  transition: background .15s;
+}
+:is(#app, [data-xftp-app]) .btn:hover { background: #2563eb; }
+:is(#app, [data-xftp-app]) .btn-secondary { background: #6b7280; }
+:is(#app, [data-xftp-app]) .btn-secondary:hover { background: #4b5563; }
+
+/* Hints */
+:is(#app, [data-xftp-app]) .hint { color: #999; font-size: .85rem; margin-top: 8px; }
+:is(#app, [data-xftp-app]) .expiry { margin-top: 12px; }
+
+/* Progress */
+:is(#app, [data-xftp-app]) .progress-ring { display: block; margin: 0 auto 12px; }
+:is(#app, [data-xftp-app]) #upload-status,
+:is(#app, [data-xftp-app]) #dl-status { font-size: .9rem; color: #666; margin-bottom: 12px; }
+
+/* Share link row */
+:is(#app, [data-xftp-app]) .link-row {
+  display: flex;
+  gap: 8px;
+  margin-top: 12px;
+}
+:is(#app, [data-xftp-app]) .link-row input {
+  flex: 1;
+  padding: 8px 10px;
+  border: 1px solid #ccc;
+  border-radius: 6px;
+  font-size: .85rem;
+  background: #f9fafb;
+}
+
+/* Upload link */
+:is(#app, [data-xftp-app]) .upload-link {
+  margin-top: 12px;
+  color: #3b82f6;
+  font-size: .9rem;
+  text-decoration: none;
+  cursor: pointer;
+}
+:is(#app, [data-xftp-app]) .upload-link:not([hidden]) {
+  display: inline-block;
+}
+:is(#app, [data-xftp-app]) .upload-link:hover { text-decoration: underline; }
+
+/* Messages */
+:is(#app, [data-xftp-app]) .success { color: #16a34a; font-weight: 600; }
+:is(#app, [data-xftp-app]) .error { color: #dc2626; font-weight: 500; margin-bottom: 12px; }
+
+/* Security note */
+:is(#app, [data-xftp-app]) .security-note {
+  margin-top: 20px;
+  padding: 12px;
+  background: #f0fdf4;
+  border-radius: 6px;
+  font-size: .8rem;
+  color: #555;
+  text-align: left;
+}
+:is(#app, [data-xftp-app]) .security-note p + p { margin-top: 6px; }
+:is(#app, [data-xftp-app]) .security-note a { color: #3b82f6; text-decoration: none; }
+:is(#app, [data-xftp-app]) .security-note a:hover { text-decoration: underline; }
+
+/* ── Dark mode ─────────────────────────────────── */
+.dark :is(#app, [data-xftp-app]) {
+  color: #e5e7eb;
+  --xftp-ring-bg: #374151;
+  --xftp-ring-fg: #60a5fa;
+  --xftp-ring-text: #e5e7eb;
+  --xftp-ring-done: #4ade80;
+}
+.dark :is(#app, [data-xftp-app]) .card {
+  background: #1f2937;
+  box-shadow: 0 1px 3px rgba(0,0,0,.4);
+}
+.dark :is(#app, [data-xftp-app]) .drop-zone { border-color: #4b5563; }
+.dark :is(#app, [data-xftp-app]) .drop-zone.drag-over {
+  border-color: #60a5fa;
+  background: rgba(59,130,246,.15);
+}
+.dark :is(#app, [data-xftp-app]) .btn-secondary { background: #4b5563; }
+.dark :is(#app, [data-xftp-app]) .btn-secondary:hover { background: #374151; }
+.dark :is(#app, [data-xftp-app]) .hint { color: #9ca3af; }
+.dark :is(#app, [data-xftp-app]) #upload-status,
+.dark :is(#app, [data-xftp-app]) #dl-status { color: #9ca3af; }
+.dark :is(#app, [data-xftp-app]) .link-row input {
+  background: #374151;
+  border-color: #4b5563;
+  color: #e5e7eb;
+}
+.dark :is(#app, [data-xftp-app]) .success { color: #4ade80; }
+.dark :is(#app, [data-xftp-app]) .error { color: #f87171; }
+.dark :is(#app, [data-xftp-app]) .security-note {
+  background: rgba(34,197,94,.1);
+  color: #d1d5db;
+}
+.dark :is(#app, [data-xftp-app]) .upload-link { color: #60a5fa; }
+.dark :is(#app, [data-xftp-app]) .security-note a { color: #60a5fa; }
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: Apache-2.0
+// getentropy() shim for Windows, where it is absent from the CRT.
+// Follows the POSIX contract: fills `buffer` with `length` random bytes
+// (length must not exceed 256), returns 0 on success or -1 with errno set.
+#ifdef _WIN32
+#include <errno.h>
+#include <stddef.h>
+#include <windows.h>
+#include <bcrypt.h>
+
+int getentropy(void *buffer, size_t length) {
+    if (length > 256) {
+        errno = EIO;
+        return -1;
+    }
+    NTSTATUS status = BCryptGenRandom(NULL, (PUCHAR)buffer, (ULONG)length,
+                                      BCRYPT_USE_SYSTEM_PREFERRED_RNG);
+    if (!BCRYPT_SUCCESS(status)) {
+        errno = EIO;
+        return -1;
+    }
+    return 0;
+}
+#endif
@@ -0,0 +1,104 @@
+# Coding and building
+
+This file provides guidance on coding style and approaches and on building the code.
+
+## Code Security
+
+When designing code and planning implementations:
+- Apply adversarial thinking, and consider what may happen if one of the communicating parties is malicious.
+- Formulate an explicit threat model for each change - who can do which undesirable things and under which circumstances.
+
+## Code Quality Standards
+
+Haskell client and server code serves as system specification, not just implementation — we use type-driven design to reflect the business domain in types. Quality, conciseness, and clarity of Haskell code are critical.
+
+## Code Style, Formatting and Approaches
+
+The project uses **fourmolu** for Haskell code formatting. Configuration is in `fourmolu.yaml`.
+
+**Key formatting rules:**
+- 2-space indentation
+- Trailing function arrows, commas, and import/export style
+- Record brace without space: `{field = value}`
+- Single newline between declarations
+- Never use unicode symbols
+- Inline `let` style with right-aligned `in`
+
+**Format code before committing:**
+
+```bash
+# Format a single file
+fourmolu -i src/Simplex/Messaging/Protocol.hs
+```
+
+Some files that use CPP language extension cannot be formatted as a whole, so individual code fragments need to be formatted.
+
+**Follow existing code patterns:**
+- Match the style of surrounding code
+- Use qualified imports with short aliases (e.g., `import qualified Data.ByteString.Char8 as B`)
+- Use record syntax for types with multiple fields
+- Prefer explicit pattern matching over partial functions
+
+**Comments policy:**
+- Avoid redundant comments that restate what the code already says
+- Only comment on non-obvious design decisions or tricky implementation details
+- Function names and type signatures should be self-documenting
+- Do not add comments like "wire format encoding" (Encoding class is always wire format) or "check if X" when the function name already says that
+- Assume a competent Haskell reader
+
+**Diff and refactoring:**
+- Avoid unnecessary changes and code movements
+- Never do refactoring unless it substantially reduces cost of solving the current problem, including the cost of refactoring
+- Aim to minimize the code changes - do what is minimally required to solve users' problems
+
+**Document and code structure:**
+- **Never move existing code or sections around** - add new content at appropriate locations without reorganizing existing structure.
+- When adding new sections to documents, continue the existing numbering scheme.
+- Minimize diff size - prefer small, targeted changes over reorganization.
+
+**Code analysis and review:**
+- Trace data flows end-to-end: from origin, through storage/parameters, to consumption. Flag values that are discarded and reconstructed from partial data (e.g. extracted from a URI missing original fields) — this is usually a bug.
+- Read implementations of called functions, not just signatures — if duplication involves a called function, check whether decomposing it resolves the duplication.
+- Do not save time on analysis. Read every function in the data flow even when the interface seems clear — wrong assumptions about internals are the main source of missed bugs.
+
+### Haskell Extensions
+- `StrictData` enabled by default
+- Use STM for safe concurrency
+- Assume concurrency in PostgreSQL queries
+- Comprehensive warning flags with strict pattern matching
+
+## Build Commands
+
+```bash
+# Standard build
+cabal build
+
+# Fast build
+cabal build --ghc-options -O0
+
+# Build specific executables
+cabal build exe:smp-server exe:xftp-server exe:ntf-server exe:xftp
+
+# Build with PostgreSQL server support
+cabal build -fserver_postgres
+
+# Client-only library build (no server code)
+cabal build -fclient_library
+
+# Find binary location
+cabal list-bin exe:smp-server
+```
+
+### Cabal Flags
+
+- `swift`: Enable Swift JSON format
+- `client_library`: Build without server code
+- `client_postgres`: Use PostgreSQL instead of SQLite for agent persistence
+- `server_postgres`: PostgreSQL support for server queue/notification store
+
+## External Dependencies
+
+Custom forks specified in `cabal.project`:
+- `aeson`, `hs-socks` (SimpleX forks)
+- `direct-sqlcipher`, `sqlcipher-simple` (encrypted SQLite)
+- `warp`, `warp-tls` (HTTP server)
@@ -0,0 +1,105 @@
+# SimpleXMQ repository
+
+This file provides guidance on the project structure to help working with code in this repository.
+
+## Project Overview
+
+SimpleXMQ is a Haskell message broker implementing unidirectional (simplex) queues for privacy-preserving messaging. 
+
+Key components:
+
+- **SimpleX Messaging Protocol**: SMP protocol definition and encodings ([code](../src/Simplex/Messaging/Protocol.hs), [transport code](../src/Simplex/Messaging/Transport.hs), [spec](../protocol/simplex-messaging.md)).
+- **SMP Server**: Message broker with TLS, in-memory queues, optional persistence ([main code](../src/Simplex/Messaging/Server.hs), [all code files](../src/Simplex/Messaging/Server/), [executable](../apps/smp-server/)). For proxying SMP commands the server uses [lightweight SMP client](../src/Simplex/Messaging/Client/Agent.hs).
+- **SMP Client**: Functional API with STM-based message delivery ([code](../src/Simplex/Messaging/Client.hs)).
+- **SMP Agent**: High-level duplex connections via multiple simplex queues with E2E encryption ([code](../src/Simplex/Messaging/Agent.hs)). Implements Agent-to-agent protocol ([code](../src/Simplex/Messaging/Agent/Protocol.hs), [spec](../protocol/agent-protocol.md)) via intermediary agent client ([code](../src/Simplex/Messaging/Agent/Client.hs)).
+- **XFTP**: SimpleX File Transfer Protocol, server and CLI client ([code](../src/Simplex/FileTransfer/), [spec](../protocol/xftp.md)).
+- **XRCP**: SimpleX Remote Control Protocol ([code](`../src/Simplex/RemoteControl/`), [spec](../protocol/xrcp.md)).
+- **Notifications**: Push notifications server requires PostgreSQL ([code](../src/Simplex/Messaging/Notifications), [executable](../apps/ntf-server/)). Client protocol is used for clients to communicate with the server ([code](../src/Simplex/Messaging/Notifications/Protocol.hs), [spec](../protocol/push-notifications.md)). For subscribing to SMP notifications the server uses [lightweight SMP client](../src/Simplex/Messaging/Client/Agent.hs).
+
+## Architecture
+
+For general overview see `../protocol/overview-tjr.md`.
+
+SMP Protocol Layers:
+
+```
+TLS Transport → SMP Protocol → Agent Protocol → Application protocol
+```
+
+XFTP Protocol Layers:
+
+```
+TLS Transport (HTTP2 encoding) → XFTP Protocol → Out-of-band file descriptions
+```
+
+## Key Patterns
+
+1. **Persistence**: All queue state managed via Software Transactional Memory or via PostgreSQL
+   - `Simplex.Messaging.Server.MsgStore.STM` - in-memory messages
+   - `Simplex.Messaging.Server.QueueStore.STM` - in-memory queue state
+   - `Simplex.Messaging.Server.MsgStore.Postgres` - message storage
+   - `Simplex.Messaging.Server.QueueStore.Postgres` - queue storage
+
+2. **Append-Only Store Log**: Optional persistence via journal for in-memory storage
+   - `Simplex.Messaging.Server.StoreLog` - queue creation log
+   - Compacted on restart
+
+3. **Agent Storage**:
+   - SQLite (default) or PostgreSQL
+   - Migrations in `src/Simplex/Messaging/Agent/Store/{SQLite,Postgres}/Migrations/`
+
+4. **Protocol Versioning**: All layers support version negotiation
+   - `Simplex.Messaging.Version` - version range utilities
+
+5. **Double Ratchet E2E**: Per-connection encryption
+   - `Simplex.Messaging.Crypto.Ratchet`
+   - SNTRUP761 post-quantum KEM (`src/Simplex/Messaging/Crypto/SNTRUP761/`)
+
+## Source Layout
+
+```
+src/Simplex/
+├── Messaging/
+│   ├── Agent.hs          # Main agent (~210KB)
+│   ├── Server.hs         # SMP server (~130KB)
+│   ├── Client.hs         # Client API (~65KB)
+│   ├── Protocol.hs       # Protocol types (~77KB)
+│   ├── Crypto.hs         # E2E encryption (~52KB)
+│   ├── Transport.hs      # Transport encoding over TLS
+│   ├── Agent/Store/      # SQLite/Postgres persistence
+│   ├── Server/           # Server internals (QueueStore, MsgStore, Control)
+│   └── Notifications/    # Push notification system
+├── FileTransfer/         # XFTP implementation for file transfers
+└── RemoteControl/        # XRCP implementation for device discovery & control
+```
+
+## Protocol Documentation
+
+- `protocol/overview-tjr.md`: SMP protocols stack overview
+- `protocol/simplex-messaging.md`: SMP protocol spec (v19)
+- `protocol/agent-protocol.md`: Agent protocol spec (v7)
+- `protocol/xftp.md`: File transfer protocol
+- `protocol/xrcp.md`: Remote control protocol
+- `rfcs/`: Design RFCs for features
+
+## Testing
+
+```bash
+# Run all tests
+cabal test --test-show-details=streaming
+
+# Run specific test group (uses HSpec)
+cabal test --test-option=--match="/Core tests/Encryption tests/"
+
+# Run single test
+cabal test --test-option=--match="/SMP client agent/functional API/"
+```
+
+Tests require PostgreSQL running on `localhost:5432` when using `-fserver_postgres` or `-fclient_postgres`.
+
+Test files are in `tests/` with structure:
+- `Test.hs`: Main runner
+- `AgentTests/`: Agent protocol and connection tests
+- `CoreTests/`: Crypto, encoding, storage tests
+- `ServerTests.hs`: SMP server tests
+- `XFTPServerTests.hs`: File transfer tests
@@ -0,0 +1,23 @@
+# Contributing to SimpleX repositories
+
+## Focus on user problems
+
+We do not make code changes to improve code - any change must address a specific user problem or request.
+
+## Discuss the plans as early as possible
+
+Please discuss the problem you want to solve and your detailed implementation plan with the project team prior to contributing, to avoid wasted time and additional changes. Acceptance of your contribution depends on your willingness and ability to iterate the proposed contribution to achieve the required quality level, coding style, test coverage, and alignment with user requirements as they are understood by the project team.
+
+## Follow project structure, coding style and approaches
+
+./PROJECT.md has information about the structure of this `simplexmq` repository.
+
+./CODE.md has details about general requirements common for `simplexmq` and `simplex-chat` repositories.
+
+This files can be used with LLM prompts, e.g. if you use Claude Code you can create CLAUDE.md file in project root importing content from these files:
+
+```markdown
+@README.md
+@contributing/PROJECT.md
+@contributing/CODE.md
+```
@@ -1,23 +0,0 @@
-common:
-  corrId - random BS, used as CbNonce
-  entityId - p2r tlsUniq
-
-# setup
-s->p: "proxy", uri, auth?
-  # unless connected
-  p->r: "p_handshake"
-  p<-r: "r_key", tls-signed dh pub
-s<-r: "r_key", tls-signed dh pub # reply entityId contains tlsUniq
-
-# working
-s ; generate random dh priv, make shared secret
-s->p: s2r("forward", random dh pub, SEND command blob)
-  p->r: p2r("forward", random dh pub, s2r("forward", ...)))
-    r->c@ "msg", ...
-  p<-r: p2r("r_res", s2r("ok" / "error", error))
-s<-p@ s2r("ok" / "error", error)
-
-# expired
-  p<-r@ p2r("error", "key expired")
-s<-p@ "error", "key expired"
-s ; reconnect
@@ -0,0 +1,472 @@
+# XFTP Server PostgreSQL Backend
+
+## Overview
+
+Add PostgreSQL backend support to xftp-server, following the SMP server pattern. Supports bidirectional migration between STM (in-memory with StoreLog) and PostgreSQL backends.
+
+## Goals
+
+- PostgreSQL-backed file metadata storage as an alternative to STM + StoreLog
+- Polymorphic server code via `FileStoreClass` typeclass with IO-based methods (following `QueueStoreClass` pattern)
+- Bidirectional migration: StoreLog <-> PostgreSQL via CLI commands
+- Shared `server_postgres` cabal flag (same flag enables both SMP and XFTP Postgres support)
+- INI-based backend selection at runtime
+
+## Architecture
+
+### FileStoreClass Typeclass
+
+IO-based typeclass following the `QueueStoreClass` pattern — each method is a self-contained IO action, with the implementation responsible for its own atomicity (STM backend wraps in `atomically`, Postgres backend uses database transactions):
+
+```haskell
+class FileStoreClass s where
+  type FileStoreConfig s
+
+  -- Lifecycle
+  newFileStore :: FileStoreConfig s -> IO s
+  closeFileStore :: s -> IO ()
+
+  -- File operations
+  addFile :: s -> SenderId -> FileInfo -> RoundedFileTime -> ServerEntityStatus -> IO (Either XFTPErrorType ())
+  setFilePath :: s -> SenderId -> FilePath -> IO (Either XFTPErrorType ())
+  addRecipient :: s -> SenderId -> FileRecipient -> IO (Either XFTPErrorType ())
+  getFile :: s -> SFileParty p -> XFTPFileId -> IO (Either XFTPErrorType (FileRec, C.APublicAuthKey))
+  deleteFile :: s -> SenderId -> IO (Either XFTPErrorType ())
+  blockFile :: s -> SenderId -> BlockingInfo -> Bool -> IO (Either XFTPErrorType ())
+  deleteRecipient :: s -> RecipientId -> FileRec -> IO ()
+  ackFile :: s -> RecipientId -> IO (Either XFTPErrorType ())
+
+  -- Expiration (with LIMIT for Postgres; called in a loop until empty)
+  expiredFiles :: s -> Int64 -> Int -> IO [(SenderId, Maybe FilePath, Word32)]
+
+  -- Storage and stats (for init-time computation)
+  getUsedStorage :: s -> IO Int64
+  getFileCount :: s -> IO Int
+```
+
+- STM backend: each method wraps its STM transaction in `atomically` internally.
+- Postgres backend: each method runs its query via `withDB` / database connection internally.
+
+No polymorphic monad or `runStore` dispatcher needed — unlike `MsgStoreClass`, XFTP file operations are individually atomic and don't require grouping multiple operations into backend-dependent transactions.
+
+### PostgresFileStore Data Type
+
+```haskell
+data PostgresFileStore = PostgresFileStore
+  { dbStore :: DBStore,
+    dbStoreLog :: Maybe (StoreLog 'WriteMode)
+  }
+```
+
+- `dbStore` — connection pool created via `createDBStore`, runs schema migrations on init.
+- `dbStoreLog` — optional parallel log file (enabled by `db_store_log` INI setting). When present, every mutation (`addFile`, `setFilePath`, `deleteFile`, `blockFile`, `addRecipient`, `ackFile`) also writes to this log via a `withLog` wrapper. `withLog` is called AFTER the DB operation succeeds (so the log reflects committed state only). Log write failures are non-fatal (logged as warnings, do not fail the DB operation). This provides an audit trail and enables recovery via export.
+
+`closeFileStore` for Postgres calls `closeDBStore` (closes connection pool) then `mapM_ closeStoreLog dbStoreLog` (flushes and closes the parallel log). For STM, it closes the storeLog. Called from a `finally` block during server shutdown, matching SMP's `stopServer` → `closeMsgStore` → `closeQueueStore` pattern.
+
+### STMFileStore Type
+
+After extracting from current `Store.hs`, `STMFileStore` retains the file and recipient maps but no longer owns `usedStorage` (moved to `XFTPEnv`):
+
+```haskell
+data STMFileStore = STMFileStore
+  { files :: TMap SenderId FileRec,
+    recipients :: TMap RecipientId (SenderId, RcvPublicAuthKey)
+  }
+```
+
+`closeFileStore` for STM is a no-op (TMaps are garbage-collected; the env-level `storeLog` is closed separately by the server).
+
+### Error Handling
+
+Postgres operations follow SMP's `withDB` / `handleDuplicate` pattern:
+
+```haskell
+withDB :: Text -> PostgresFileStore -> (DB.Connection -> IO (Either XFTPErrorType a)) -> ExceptT XFTPErrorType IO a
+withDB op st action =
+  ExceptT $ E.try (withTransaction (dbStore st) action) >>= either logErr pure
+  where
+    logErr :: E.SomeException -> IO (Either XFTPErrorType a)
+    logErr e = logError ("STORE: " <> err) $> Left INTERNAL
+      where
+        err = op <> ", withDB, " <> tshow e
+
+handleDuplicate :: SqlError -> IO (Either XFTPErrorType a)
+handleDuplicate e = case constraintViolation e of
+  Just (UniqueViolation _) -> pure $ Left DUPLICATE_
+  _ -> E.throwIO e
+```
+
+- All DB operations wrapped in `withDB` — catches exceptions, logs, returns `INTERNAL`.
+- Unique constraint violations caught by `handleDuplicate` and mapped to `DUPLICATE_`.
+- UPDATE operations verified with `assertUpdated` — returns `AUTH` if 0 rows affected (matching SMP pattern, prevents silent failures when WHERE clause doesn't match).
+- Critical sections (DB write + TVar update) wrapped in `uninterruptibleMask_` to prevent async exceptions from leaving inconsistent state between DB and TVars.
+
+### FileRec and TVar Fields
+
+`FileRec` retains its `TVar` fields (matching SMP's `PostgresQueue` pattern):
+
+```haskell
+data FileRec = FileRec
+  { senderId :: SenderId,
+    fileInfo :: FileInfo,
+    filePath :: TVar (Maybe FilePath),
+    recipientIds :: TVar (Set RecipientId),
+    createdAt :: RoundedFileTime,
+    fileStatus :: TVar ServerEntityStatus
+  }
+```
+
+- **STM backend**: TVars are the source of truth, as currently.
+- **Postgres backend**: `getFile` reads from DB and creates a `FileRec` with fresh TVars populated from the DB row (matching SMP's `mkQ` pattern — `newTVarIO` per load). Mutation methods (`setFilePath`, `blockFile`, etc.) update both the DB (persistence) and the TVars (in-session consistency). The `recipientIds` TVar is initialized to `S.empty` — no subquery needed because no server code reads `recipientIds` directly; all recipient operations go through the typeclass methods (`addRecipient`, `deleteRecipient`, `ackFile`), which query the `recipients` table for Postgres.
+
+### usedStorage Ownership
+
+`usedStorage :: TVar Int64` moves from the store to `XFTPEnv`. The store typeclass does **not** manage `usedStorage` — it only provides `getUsedStorage` for init-time computation.
+
+- **STM init**: StoreLog replay calls `setFilePath` (which only sets the filePath TVar — the STM `setFilePath` implementation is changed to **not** update `usedStorage`). Similarly, STM `deleteFile` (Store.hs line 117) and `blockFile` (line 125) are changed to **not** update `usedStorage` — the server handles all `usedStorage` adjustments externally. After replay, `getUsedStorage` computes the sum over all file sizes (matching current `countUsedStorage` behavior).
+- **Postgres init**: `getUsedStorage` executes `SELECT COALESCE(SUM(file_size), 0) FROM files`.
+- **Runtime**: Server manages `usedStorage` TVar directly for reserve/commit/rollback during uploads, and adjusts after `deleteFile`/`blockFile` calls.
+
+**Note on `getUsedStorage` semantics**: The current STM `countUsedStorage` sums all file sizes unconditionally (including files without `filePath` set, i.e., created but not yet uploaded). The Postgres `getUsedStorage` matches this: `SELECT SUM(file_size) FROM files` (no `WHERE file_path IS NOT NULL`). In practice, orphaned files (created but never uploaded) are rare and short-lived (expired within 48h), so the difference is negligible. A future improvement could filter by `file_path IS NOT NULL` in both backends to reflect actual disk usage more accurately.
+
+### Server.hs Refactoring
+
+`Server.hs` becomes polymorphic over `FileStoreClass s`. Since all typeclass methods are IO, call sites replace `atomically` with direct IO calls to the store.
+
+**Call sites requiring changes** (exhaustive list):
+
+1. **`receiveServerFile`** (line 563): `atomically $ writeTVar filePath (Just fPath)` → `setFilePath store senderId fPath`. The `reserve` logic (line 551-555) stays as direct TVar manipulation on `usedStorage` from `XFTPEnv`.
+
+2. **`verifyXFTPTransmission`** (line 453): `atomically $ verify =<< getFile st party fId` — the `getFile` call and subsequent `readTVar fileStatus` are in a single `atomically` block. Refactored to: `getFile st party fId` (IO), then `readTVarIO (fileStatus fr)` from the returned `FileRec` (safe for both backends — STM TVar is the source of truth, Postgres TVar is a fresh snapshot from DB).
+
+3. **`retryAdd`** (line 516): Signature `XFTPFileId -> STM (Either XFTPErrorType a)` → `XFTPFileId -> IO (Either XFTPErrorType a)`. The `atomically` call (line 520) replaced with `liftIO`.
+
+4. **`deleteOrBlockServerFile_`** (line 620): Parameter `FileStore -> STM (Either XFTPErrorType ())` → `FileStoreClass s => s -> IO (Either XFTPErrorType ())`. The `atomically` call (line 626) removed — the store method is already IO. After the store action, server adjusts `usedStorage` TVar in `XFTPEnv` based on `fileInfo.size`.
+
+5. **`ackFileReception`** (line 605): `atomically $ deleteRecipient st rId fr` → `deleteRecipient st rId fr`.
+
+6. **Control port `CPDelete`/`CPBlock`** (lines 371, 377): `atomically $ getFile fs SFRecipient fileId` → `getFile fs SFRecipient fileId`.
+
+7. **`expireServerFiles`** (line 636): Replace per-file `expiredFilePath` iteration with batched `expiredFiles st old batchSize`, which returns `[(SenderId, Maybe FilePath, Word32)]` — the `Word32` file size is needed so the server can adjust the `usedStorage` TVar after each deletion. Called in a loop until the returned list is empty. The `itemDelay` between files applies to the deletion loop over each batch, not the query itself. STM backend ignores the batch size limit (returns all expired files from TMap scan); Postgres uses `LIMIT`.
+
+8. **`restoreServerStats`** (line 694): `FileStore {files, usedStorage} <- asks store` accesses store fields directly. Refactored to: `usedStorage` from `XFTPEnv` via `asks usedStorage`, file count via `getFileCount store`. STM: `M.size <$> readTVarIO files`. Postgres: `SELECT COUNT(*) FROM files`.
+
+### Store Config Selection
+
+GADT in `Env.hs`:
+
+```haskell
+data XFTPStoreConfig s where
+  XSCMemory :: Maybe FilePath -> XFTPStoreConfig STMFileStore
+#if defined(dbServerPostgres)
+  XSCDatabase :: PostgresFileStoreCfg -> XFTPStoreConfig PostgresFileStore
+#endif
+```
+
+`XFTPEnv` becomes polymorphic:
+
+```haskell
+data XFTPEnv s = XFTPEnv
+  { config :: XFTPServerConfig,
+    store :: s,
+    usedStorage :: TVar Int64,
+    storeLog :: Maybe (StoreLog 'WriteMode),
+    ...
+  }
+```
+
+The `M` monad (`ReaderT (XFTPEnv s) IO`) and all functions in `Server.hs` gain `FileStoreClass s =>` constraints.
+
+**StoreLog lifecycle per backend:**
+
+- **STM mode**: `storeLog = Just sl` (current behavior — append-only log for persistence and recovery).
+- **Postgres mode**: `storeLog = Nothing` (main storeLog disabled — Postgres is the source of truth). The optional parallel `dbStoreLog` inside `PostgresFileStore` provides audit/recovery if enabled via `db_store_log` INI setting.
+
+The existing `withFileLog` pattern in Server.hs continues to work unchanged — it maps over `Maybe (StoreLog 'WriteMode)`, which is `Nothing` in Postgres mode so the calls become no-ops.
+
+### Main.hs Store Type Dispatch
+
+The `Start` CLI command gains a `--confirm-migrations` flag (default `MCConsole` — manual prompt, matching SMP's `StartOptions`). For automated deployments, `--confirm-migrations up` auto-applies forward migrations. The import command uses `MCYesUp` (always auto-apply).
+
+Following SMP's existential dispatch pattern (`AStoreType` + `run`), `Main.hs` selects the store type from INI config and dispatches to the polymorphic server:
+
+```haskell
+runServer ini = do
+  let storeType = fromRight "memory" $ lookupValue "STORE_LOG" "store_files" ini
+  case storeType of
+    "memory" -> run $ XSCMemory (enableStoreLog $> storeLogFilePath)
+    "database" ->
+#if defined(dbServerPostgres)
+      run $ XSCDatabase PostgresFileStoreCfg {..}
+#else
+      exitError "server not compiled with Postgres support"
+#endif
+    _ -> exitError $ "Invalid store_files value: " <> storeType
+  where
+    run :: FileStoreClass s => XFTPStoreConfig s -> IO ()
+    run storeCfg = do
+      env <- newXFTPServerEnv storeCfg config
+      runReaderT (xftpServer config) env
+```
+
+**`newXFTPServerEnv` refactored signature:**
+
+```haskell
+newXFTPServerEnv :: FileStoreClass s => XFTPStoreConfig s -> XFTPServerConfig -> IO (XFTPEnv s)
+newXFTPServerEnv storeCfg config = do
+  (store, storeLog) <- case storeCfg of
+    XSCMemory storeLogPath -> do
+      st <- newFileStore ()
+      sl <- mapM (`readWriteFileStore` st) storeLogPath
+      pure (st, sl)
+    XSCDatabase dbCfg -> do
+      st <- newFileStore dbCfg
+      pure (st, Nothing)  -- main storeLog disabled for Postgres
+  usedStorage <- newTVarIO =<< getUsedStorage store
+  ...
+  pure XFTPEnv {config, store, usedStorage, storeLog, ...}
+```
+
+### Startup Config Validation
+
+Following SMP's `checkMsgStoreMode` pattern, `Main.hs` validates config before starting:
+
+- **`store_files=database` + StoreLog file exists** (without `db_store_log=on`): Error — "StoreLog file present but store_files is `database`. Use `xftp-server database import` to migrate, or set `db_store_log: on`."
+- **`store_files=database` + schema doesn't exist**: Error — "Create schema in PostgreSQL or use `xftp-server database import`."
+- **`store_files=memory` + Postgres schema exists**: Warning — "Postgres schema exists but store_files is `memory`. Data in Postgres will not be used."
+- **Binary compiled without `server_postgres` + `store_files=database`**: Error — "Server not compiled with Postgres support."
+
+## Module Structure
+
+```
+src/Simplex/FileTransfer/Server/
+  Store.hs                    -- FileStoreClass typeclass + shared types (FileRec, FileRecipient, etc.)
+  Store/
+    STM.hs                    -- STMFileStore (extracted from current Store.hs)
+    Postgres.hs               -- PostgresFileStore                [CPP-guarded]
+    Postgres/
+      Migrations.hs           -- Schema migrations                [CPP-guarded]
+      Config.hs               -- PostgresFileStoreCfg             [CPP-guarded]
+  StoreLog.hs                 -- Unchanged (interchange format for both backends + migration)
+  Env.hs                      -- XFTPStoreConfig GADT, polymorphic XFTPEnv
+  Main.hs                     -- Store selection, migration CLI commands
+  Server.hs                   -- Polymorphic over FileStoreClass
+```
+
+## PostgreSQL Schema
+
+Initial migration (`20260325_initial`):
+
+```sql
+CREATE TABLE files (
+  sender_id BYTEA NOT NULL PRIMARY KEY,
+  file_size INT4 NOT NULL,
+  file_digest BYTEA NOT NULL,
+  sender_key BYTEA NOT NULL,
+  file_path TEXT,
+  created_at INT8 NOT NULL,
+  status TEXT NOT NULL DEFAULT 'active'
+);
+
+CREATE TABLE recipients (
+  recipient_id BYTEA NOT NULL PRIMARY KEY,
+  sender_id BYTEA NOT NULL REFERENCES files ON DELETE CASCADE,
+  recipient_key BYTEA NOT NULL
+);
+
+CREATE INDEX idx_recipients_sender_id ON recipients (sender_id);
+CREATE INDEX idx_files_created_at ON files (created_at);
+```
+
+- `file_size` is `INT4` matching `Word32` in `FileInfo.size`
+- `sender_key` and `recipient_key` stored as `BYTEA` using binary encoding via `C.encodePubKey` / `C.decodePubKey` (matching SMP's `ToField`/`FromField` instances for `APublicAuthKey` — includes algorithm type tag in the binary format)
+- `file_path` nullable (set after upload completes via `setFilePath`)
+- `ON DELETE CASCADE` for recipients when file is hard-deleted
+- `created_at` stores rounded epoch seconds (1-hour precision, `RoundedFileTime`)
+- `status` as TEXT via `StrEncoding` (`ServerEntityStatus`: `EntityActive`, `EntityBlocked info`, `EntityOff`)
+- Hard deletes (no `deleted_at` column)
+- No PL/pgSQL functions needed; `setFilePath` uses `WHERE file_path IS NULL` to prevent duplicate uploads (the `UPDATE` itself acquires a row-level lock)
+- `used_storage` computed on startup: `SELECT COALESCE(SUM(file_size), 0) FROM files` (matches STM `countUsedStorage` — all files, see usedStorage Ownership section)
+
+### Migrations Module
+
+Following SMP's `QueueStore/Postgres/Migrations.hs` pattern:
+
+```haskell
+module Simplex.FileTransfer.Server.Store.Postgres.Migrations
+  ( xftpServerMigrations,
+  )
+where
+
+import Data.List (sortOn)
+import Data.Text (Text)
+import Simplex.Messaging.Agent.Store.Shared
+import Text.RawString.QQ (r)
+
+xftpSchemaMigrations :: [(String, Text, Maybe Text)]
+xftpSchemaMigrations =
+  [ ("20260325_initial", m20260325_initial, Nothing)
+  ]
+
+xftpServerMigrations :: [Migration]
+xftpServerMigrations = sortOn name $ map migration xftpSchemaMigrations
+  where
+    migration (name, up, down) = Migration {name, up, down = down}
+
+m20260325_initial :: Text
+m20260325_initial =
+  [r|
+CREATE TABLE files (
+  sender_id BYTEA NOT NULL PRIMARY KEY,
+  ...
+);
+  |]
+```
+
+The `Migration` type (from `Simplex.Messaging.Agent.Store.Shared`) has fields `{name :: String, up :: Text, down :: Maybe Text}`. Initial migration has `Nothing` for `down`. Future migrations should include `Just down_migration` for rollback support. Called via `createDBStore dbOpts xftpServerMigrations (MigrationConfig confirmMigrations Nothing)`.
+
+### Postgres Operations
+
+Key query patterns:
+
+- **`addFile`**: `INSERT INTO files (...) VALUES (...)`, return `DUPLICATE_` on unique violation.
+- **`setFilePath`**: `UPDATE files SET file_path = ? WHERE sender_id = ? AND file_path IS NULL`, verified with `assertUpdated` (returns `AUTH` if 0 rows affected — file not found or already uploaded). The `WHERE file_path IS NULL` prevents duplicate uploads; the `UPDATE` acquires a row lock implicitly. Only persists the path; `usedStorage` managed by server.
+- **`addRecipient`**: `INSERT INTO recipients (...)`, plus check for duplicates. No need for `recipientIds` TVar update — Postgres derives it from the table.
+- **`getFile`** (sender): `SELECT ... FROM files WHERE sender_id = ?`, returns auth key from `sender_key` column.
+- **`getFile`** (recipient): `SELECT f.*, r.recipient_key FROM recipients r JOIN files f ON ... WHERE r.recipient_id = ?`.
+- **`deleteFile`**: `DELETE FROM files WHERE sender_id = ?` (recipients cascade).
+- **`blockFile`**: `UPDATE files SET status = ? WHERE sender_id = ?`. When `deleted = True`, the server adjusts `usedStorage` externally (matching current STM behavior where `blockFile` only updates status and storage, not `filePath`).
+- **`expiredFiles`**: `SELECT sender_id, file_path, file_size FROM files WHERE created_at + ? < ? LIMIT ?` — batched query replaces per-file iteration, includes `file_size` for `usedStorage` adjustment. Called in a loop until no rows returned.
+
+## INI Configuration
+
+New keys in `[STORE_LOG]` section:
+
+```ini
+[STORE_LOG]
+enable: on
+store_files: memory            # memory | database
+db_connection: postgresql://xftp@/xftp_server_store
+db_schema: xftp_server
+db_pool_size: 10
+db_store_log: off
+expire_files_hours: 48
+```
+
+`store_files` selects the backend (`store_files` rather than `store_queues` because XFTP stores files, not queues):
+- `memory` -> `XSCMemory` (current behavior)
+- `database` -> `XSCDatabase` (requires `server_postgres` build flag)
+
+### INI Template Generation (`xftp-server init`)
+
+The `iniFileContent` function in `Main.hs` must be updated to generate the new keys in the `[STORE_LOG]` section. Following SMP's `iniDbOpts` pattern with `optDisabled'` (prefixes `"# "` when value equals default), Postgres keys are generated commented out by default:
+
+```ini
+[STORE_LOG]
+enable: on
+
+# File storage mode: `memory` or `database` (PostgreSQL).
+store_files: memory
+
+# Database connection settings for PostgreSQL database (`store_files: database`).
+# db_connection: postgresql://xftp@/xftp_server_store
+# db_schema: xftp_server
+# db_pool_size: 10
+
+# Write database changes to store log file
+# db_store_log: off
+
+expire_files_hours: 48
+```
+
+Reuses `iniDBOptions` from `Simplex.Messaging.Server.CLI` for runtime parsing (falls back to defaults when keys are commented out or missing). `enableDbStoreLog'` pattern (`settingIsOn "STORE_LOG" "db_store_log"`) controls `dbStoreLogPath`.
+
+### PostgresFileStoreCfg
+
+```haskell
+data PostgresFileStoreCfg = PostgresFileStoreCfg
+  { dbOpts :: DBOpts,
+    dbStoreLogPath :: Maybe FilePath,
+    confirmMigrations :: MigrationConfirmation
+  }
+```
+
+No `deletedTTL` (hard deletes).
+
+### Default DB Options
+
+```haskell
+defaultXFTPDBOpts :: DBOpts
+defaultXFTPDBOpts =
+  DBOpts
+    { connstr = "postgresql://xftp@/xftp_server_store",
+      schema = "xftp_server",
+      poolSize = 10,
+      createSchema = False
+    }
+```
+
+## Migration CLI
+
+Bidirectional migration via StoreLog as interchange format:
+
+```
+xftp-server database import [--database DB_CONN] [--schema DB_SCHEMA] [--pool-size N]
+xftp-server database export [--database DB_CONN] [--schema DB_SCHEMA] [--pool-size N]
+```
+
+No `--table` flag needed (unlike SMP which has queues/messages/all) — XFTP has a single entity type (files + recipients, always migrated together).
+
+CLI options reuse `dbOptsP` parser from `Simplex.Messaging.Server.CLI`.
+
+### Import (StoreLog -> PostgreSQL)
+
+1. Confirm: prompt user with database connection details and StoreLog path
+2. Read and replay StoreLog into temporary `STMFileStore`
+3. Connect to PostgreSQL, run schema migrations (`createSchema = True`, `confirmMigrations = MCYesUp`)
+4. Batch-insert file records into `files` table using PostgreSQL COPY protocol (matching SMP's `batchInsertQueues` pattern for performance). Progress reported every 10k files.
+5. Batch-insert recipient records into `recipients` table using COPY protocol
+6. Verify counts: `SELECT COUNT(*) FROM files` / `recipients` — warn if mismatch
+7. Rename StoreLog to `.bak` (prevents accidental re-import, preserves original for rollback)
+8. Report counts
+
+### Export (PostgreSQL -> StoreLog)
+
+1. Confirm: prompt user with database connection details and output path. Fail if output file already exists.
+2. Connect to PostgreSQL
+3. Open new StoreLog file for writing
+4. Fold over all file records, writing per file (in this order, matching existing `writeFileStore`): `AddFile` (with `ServerEntityStatus` — this preserves `EntityBlocked` state), `AddRecipients`, then `PutFile` (if `file_path` is set)
+5. Report counts
+
+Note: `AddFile` carries `ServerEntityStatus` which includes `EntityBlocked info`, so blocking state is preserved through export/import without needing separate `BlockFile` log entries.
+
+File data on disk is untouched by migration — only metadata moves between backends.
+
+## Cabal Integration
+
+Shared `server_postgres` flag. New Postgres modules added to existing conditional block:
+
+```cabal
+if flag(server_postgres)
+  cpp-options: -DdbServerPostgres
+  exposed-modules:
+    ...existing SMP modules...
+    Simplex.FileTransfer.Server.Store.Postgres
+    Simplex.FileTransfer.Server.Store.Postgres.Migrations
+    Simplex.FileTransfer.Server.Store.Postgres.Config
+```
+
+CPP guards (`#if defined(dbServerPostgres)`) in:
+- `Store.hs` — Postgres `FromField`/`ToField` instances for XFTP-specific types if needed
+- `Env.hs` — `XSCDatabase` constructor
+- `Main.hs` — database CLI commands, store selection for `database` mode, Postgres imports
+- `Server.hs` — Postgres-specific imports if needed
+
+## Testing
+
+- **Parameterized server tests**: Existing `xftpServerTests` refactored to accept a store type parameter (following SMP's `SpecWith (ASrvTransport, AStoreType)` pattern). The same server tests run against both STM and Postgres backends — STM tests run unconditionally, Postgres tests added under `#if defined(dbServerPostgres)` with `postgressBracket` for database lifecycle (drop → create → test → drop).
+- **Unit tests**: `PostgresFileStore` operations — add/get/delete/block/expire, duplicate detection, auth errors
+- **Migration round-trip**: STM store → export to StoreLog → import to Postgres → export back → verify StoreLog equality (including blocked file status)
+- **Tests location**: in `tests/` alongside existing XFTP tests, guarded by `server_postgres` CPP flag
+- **Test database**: PostgreSQL on `localhost:5432`, using a dedicated `xftp_server_test` schema (dropped and recreated per test run via `postgressBracket`, following SMP's test database lifecycle pattern)
+- **Test fixtures**: `testXFTPStoreDBOpts :: DBOpts` with `createSchema = True`, `confirmMigrations = MCYesUp`, in `tests/XFTPClient.hs`
@@ -0,0 +1,648 @@
+# XFTP PostgreSQL Backend — Implementation Plan
+
+> **For agentic workers:** REQUIRED: Use superpowers-extended-cc:subagent-driven-development (if subagents available) or superpowers-extended-cc:executing-plans to implement this plan. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Add PostgreSQL backend support to xftp-server as an alternative to STM + StoreLog, with bidirectional migration.
+
+**Architecture:** Introduce `FileStoreClass` typeclass (IO-based, following `QueueStoreClass` pattern). Extract current STM store into `Store/STM.hs`, make `Server.hs` polymorphic, then add `Store/Postgres.hs` behind `server_postgres` CPP flag. `usedStorage` moves from store to `XFTPEnv` so the server manages quota tracking externally.
+
+**Tech Stack:** Haskell, postgresql-simple, STM, fourmolu, cabal with CPP flags
+
+**Design spec:** `plans/2026-03-25-xftp-postgres-backend-design.md`
+
+---
+
+## File Structure
+
+**Existing files modified:**
+- `src/Simplex/FileTransfer/Server/Store.hs` — rewritten: becomes typeclass + shared types
+- `src/Simplex/FileTransfer/Server/Env.hs` — polymorphic `XFTPEnv s`, `XFTPStoreConfig` GADT
+- `src/Simplex/FileTransfer/Server.hs` — polymorphic over `FileStoreClass s`
+- `src/Simplex/FileTransfer/Server/StoreLog.hs` — update for IO store functions
+- `src/Simplex/FileTransfer/Server/Main.hs` — INI config, dispatch, CLI commands
+- `simplexmq.cabal` — new modules
+- `tests/XFTPClient.hs` — Postgres test fixtures
+- `tests/Test.hs` — Postgres test group
+
+**New files created:**
+- `src/Simplex/FileTransfer/Server/Store/STM.hs` — `STMFileStore` (extracted from current `Store.hs`)
+- `src/Simplex/FileTransfer/Server/Store/Postgres.hs` — `PostgresFileStore` [CPP-guarded]
+- `src/Simplex/FileTransfer/Server/Store/Postgres/Config.hs` — `PostgresFileStoreCfg` [CPP-guarded]
+- `src/Simplex/FileTransfer/Server/Store/Postgres/Migrations.hs` — schema SQL [CPP-guarded]
+- `tests/CoreTests/XFTPStoreTests.hs` — Postgres store unit tests [CPP-guarded]
+
+---
+
+## Task 1: Move `usedStorage` from `FileStore` to `XFTPEnv`
+
+**Files:**
+- Modify: `src/Simplex/FileTransfer/Server/Store.hs`
+- Modify: `src/Simplex/FileTransfer/Server/Env.hs`
+- Modify: `src/Simplex/FileTransfer/Server.hs`
+
+- [ ] **Step 1: Remove `usedStorage` from `FileStore` in `Store.hs`**
+
+  1. Remove `usedStorage :: TVar Int64` field from `FileStore` record (line 47).
+  2. Remove `usedStorage <- newTVarIO 0` from `newFileStore` (line 75) and drop the field from the record construction (line 76).
+  3. In `setFilePath` (line 92-97): remove `modifyTVar' (usedStorage st) (+ fromIntegral (size fileInfo))` — keep only `writeTVar filePath (Just fPath)`. Change pattern from `\FileRec {fileInfo, filePath}` to `\FileRec {filePath}` (fileInfo is now unused — `-Wunused-matches` error).
+  4. In `deleteFile` (line 112-119): remove `modifyTVar' usedStorage $ subtract (fromIntegral $ size fileInfo)`. Change outer pattern match from `FileStore {files, recipients, usedStorage}` to `FileStore {files, recipients}`. Change inner pattern from `Just FileRec {fileInfo, recipientIds}` to `Just FileRec {recipientIds}` (`fileInfo` is now unused — `-Wunused-matches` error).
+  5. In `blockFile` (line 122-127): remove `when deleted $ modifyTVar' usedStorage $ subtract (fromIntegral $ size fileInfo)`. Change pattern match from `st@FileStore {usedStorage}` to `st`. The `deleted` parameter and `fileInfo` in the inner pattern become unused — prefix with `_` or remove from pattern to avoid `-Wunused-matches`.
+
+- [ ] **Step 2: Add `usedStorage` to `XFTPEnv` in `Env.hs`**
+
+  1. Add `usedStorage :: TVar Int64` field to `XFTPEnv` record (between `store` and `storeLog`, line 93).
+  2. In `newXFTPServerEnv` (line 112-126): replace lines 117-118:
+     ```
+     used <- countUsedStorage <$> readTVarIO (files store)
+     atomically $ writeTVar (usedStorage store) used
+     ```
+     with:
+     ```
+     usedStorage <- newTVarIO =<< countUsedStorage <$> readTVarIO (files store)
+     ```
+  3. Add `usedStorage` to the `pure XFTPEnv {..}` construction.
+
+- [ ] **Step 3: Update all `usedStorage` access sites in `Server.hs`**
+
+  1. Line 552: `us <- asks $ usedStorage . store` → `us <- asks usedStorage`.
+  2. Line 569: `us <- asks $ usedStorage . store` → `us <- asks usedStorage`.
+  3. Line 639: `usedStart <- readTVarIO $ usedStorage st` → `usedStart <- readTVarIO =<< asks usedStorage`.
+  4. Line 647: `usedEnd <- readTVarIO $ usedStorage st` → `usedEnd <- readTVarIO =<< asks usedStorage`.
+  5. Line 694: `FileStore {files, usedStorage} <- asks store` → split into `FileStore {files} <- asks store` and `usedStorage <- asks usedStorage`.
+  6. In `deleteOrBlockServerFile_` (line 620): after `void $ atomically $ storeAction st`, add usedStorage adjustment — `us <- asks usedStorage` then `atomically $ modifyTVar' us $ subtract (fromIntegral $ size fileInfo)` when file had a path (check `path` from `readTVarIO filePath` earlier in the function).
+
+- [ ] **Step 4: Build and verify**
+
+  Run: `cabal build`
+
+- [ ] **Step 5: Run existing tests**
+
+  Run: `cabal test --test-show-details=streaming --test-option=--match="/XFTP/"`
+
+- [ ] **Step 6: Format and commit**
+
+  ```bash
+  fourmolu -i src/Simplex/FileTransfer/Server/Store.hs src/Simplex/FileTransfer/Server/Env.hs src/Simplex/FileTransfer/Server.hs
+  git add src/Simplex/FileTransfer/Server/Store.hs src/Simplex/FileTransfer/Server/Env.hs src/Simplex/FileTransfer/Server.hs
+  git commit -m "refactor(xftp): move usedStorage from FileStore to XFTPEnv"
+  ```
+
+---
+
+## Task 2: Add `getUsedStorage`, `getFileCount`, `expiredFiles` functions
+
+**Files:**
+- Modify: `src/Simplex/FileTransfer/Server/Store.hs`
+- Modify: `src/Simplex/FileTransfer/Server/Env.hs`
+- Modify: `src/Simplex/FileTransfer/Server.hs`
+
+- [ ] **Step 1: Add three new functions to `Store.hs`**
+
+  1. Add to exports: `getUsedStorage`, `getFileCount`, `expiredFiles`.
+  2. Remove `expiredFilePath` from exports AND delete the function definition (dead code → `-Wunused-binds` error). Also remove `($>>=)` from import `Simplex.Messaging.Util (ifM, ($>>=))` → `Simplex.Messaging.Util (ifM)` — `$>>=` was only used by `expiredFilePath`.
+  3. Add import: `qualified Data.Map.Strict as M` (needed for `M.foldl'` in `getUsedStorage` and `M.toList` in `expiredFiles`).
+  4. Implement:
+     ```haskell
+     getUsedStorage :: FileStore -> IO Int64
+     getUsedStorage FileStore {files} =
+       M.foldl' (\acc FileRec {fileInfo = FileInfo {size}} -> acc + fromIntegral size) 0 <$> readTVarIO files
+
+     getFileCount :: FileStore -> IO Int
+     getFileCount FileStore {files} = M.size <$> readTVarIO files
+
+     expiredFiles :: FileStore -> Int64 -> Int -> IO [(SenderId, Maybe FilePath, Word32)]
+     expiredFiles FileStore {files} old _limit = do
+       fs <- readTVarIO files
+       fmap catMaybes . forM (M.toList fs) $ \(sId, FileRec {fileInfo = FileInfo {size}, filePath, createdAt = RoundedSystemTime createdAt}) ->
+         if createdAt + fileTimePrecision < old
+           then do
+             path <- readTVarIO filePath
+             pure $ Just (sId, path, size)
+           else pure Nothing
+     ```
+  5. Add imports: `Data.Maybe (catMaybes)`, `Data.Word (Word32)` (note: `qualified Data.Map.Strict as M` already added in item 3).
+
+- [ ] **Step 2: Replace `countUsedStorage` in `Env.hs`**
+
+  1. Replace `countUsedStorage <$> readTVarIO (files store)` with `getUsedStorage store` in `newXFTPServerEnv`.
+  2. Remove `countUsedStorage` function definition and its export.
+  3. Remove `qualified Data.Map.Strict as M` import if no longer used.
+
+- [ ] **Step 3: Update `restoreServerStats` in `Server.hs` to use `getFileCount`**
+
+  In `restoreServerStats` (line 694-696): replace `FileStore {files} <- asks store` and `_filesCount <- M.size <$> readTVarIO files` with `st <- asks store` and `_filesCount <- liftIO $ getFileCount st` (eliminates the `FileStore` pattern match — `files` binding no longer needed).
+
+- [ ] **Step 4: Replace `expireServerFiles` iteration in `Server.hs`**
+
+  1. Replace the body of `expireServerFiles` (lines 636-660). Remove `files' <- readTVarIO (files st)` and the `forM_ (M.keys files')` loop.
+  2. New body: call `expiredFiles st old 10000` in a loop. For each `(sId, filePath_, fileSize)` in returned list: apply `itemDelay`, remove disk file if present, call `atomically $ deleteFile st sId`, adjust `usedStorage` TVar by `fileSize`, increment `filesExpired` stat. Loop until `expiredFiles` returns `[]`.
+  3. Remove `Data.Map.Strict` import from Server.hs if no longer needed (was used for `M.size` and `M.keys` — now replaced by `getFileCount` and `expiredFiles`).
+
+- [ ] **Step 5: Build and verify**
+
+  Run: `cabal build`
+
+- [ ] **Step 6: Run existing tests**
+
+  Run: `cabal test --test-show-details=streaming --test-option=--match="/XFTP/"`
+
+- [ ] **Step 7: Format and commit**
+
+  ```bash
+  fourmolu -i src/Simplex/FileTransfer/Server/Store.hs src/Simplex/FileTransfer/Server/Env.hs src/Simplex/FileTransfer/Server.hs
+  git add src/Simplex/FileTransfer/Server/Store.hs src/Simplex/FileTransfer/Server/Env.hs src/Simplex/FileTransfer/Server.hs
+  git commit -m "refactor(xftp): add getUsedStorage, getFileCount, expiredFiles store functions"
+  ```
+
+---
+
+## Task 3: Change `Store.hs` functions from STM to IO
+
+**Files:**
+- Modify: `src/Simplex/FileTransfer/Server/Store.hs`
+- Modify: `src/Simplex/FileTransfer/Server.hs`
+- Modify: `src/Simplex/FileTransfer/Server/StoreLog.hs`
+
+- [ ] **Step 1: Change all Store.hs function signatures from STM to IO**
+
+  For each of: `addFile`, `setFilePath`, `addRecipient`, `getFile`, `deleteFile`, `blockFile`, `deleteRecipient`, `ackFile`:
+  1. Change return type from `STM (Either XFTPErrorType ...)` to `IO (Either XFTPErrorType ...)` (or `STM ()` to `IO ()` for `deleteRecipient`).
+  2. Wrap the function body in `atomically $ do ...`.
+  3. Keep `withFile` and `newFileRec` as internal STM helpers (called inside the `atomically` blocks).
+
+- [ ] **Step 2: Update Server.hs call sites — remove `atomically` wrappers**
+
+  1. Line 563 (`receiveServerFile`): change `atomically $ writeTVar filePath (Just fPath)` → add `st <- asks store` then `void $ liftIO $ setFilePath st senderId fPath` (design call site #1 — `store` is not in scope in `receiveServerFile`'s `receive` helper, so bind via `asks`; `void` avoids `-Wunused-do-bind` warning on the `Either` result).
+  2. Line 453 (`verifyXFTPTransmission`): split `atomically $ verify =<< getFile st party fId` into: `liftIO (getFile st party fId)` (IO→M lift), then pattern match on result, use `readTVarIO (fileStatus fr)` instead of `readTVar`.
+  3. Lines 371, 377 (control port `CPDelete`/`CPBlock`): change `ExceptT $ atomically $ getFile fs SFRecipient fileId` → `ExceptT $ liftIO $ getFile fs SFRecipient fileId` (inside `unliftIO u $ do` block which runs in M monad — `liftIO` required to lift IO into M).
+  4. Line 508 (`addFile` in `createFile`): the `ExceptT $ addFile st sId file ts EntityActive` — `addFile` is now IO, `ExceptT` wraps IO directly. Remove any `atomically`.
+  5. Line 514 (`addRecipient`): same — `ExceptT . addRecipient st sId` works directly in IO.
+  6. Line 516 (`retryAdd`): change parameter type from `(XFTPFileId -> STM (Either XFTPErrorType a))` to `(XFTPFileId -> IO (Either XFTPErrorType a))`. Line 520: change `atomically (add fId)` to `liftIO (add fId)`.
+  7. Line 605 (`ackFileReception`): change `atomically $ deleteRecipient st rId fr` to `liftIO $ deleteRecipient st rId fr`.
+  8. Line 620 (`deleteOrBlockServerFile_`): change third parameter type from `(FileStore -> STM (Either XFTPErrorType ()))` to `(FileStore -> IO (Either XFTPErrorType ()))`. Line 626: change `void $ atomically $ storeAction st` to `void $ liftIO $ storeAction st`.
+  9. `expireServerFiles` `delete` helper: change `atomically $ deleteFile st sId` to `liftIO $ deleteFile st sId` (deleteFile is now IO; `liftIO` required because the helper runs in M monad, not IO).
+
+- [ ] **Step 3: Update `StoreLog.hs` — remove `atomically` from replay**
+
+  In `readFileStore` (line 93), function `addToStore`:
+  1. Change `atomically (addToStore lr)` to `addToStore lr` — store functions are now IO.
+  2. The `addToStore` body calls `addFile`, `setFilePath`, `deleteFile`, `blockFile`, `ackFile` — all IO now, no `atomically` needed.
+  3. For `AddRecipients`: `runExceptT $ mapM_ (ExceptT . addRecipient st sId) rcps` — `addRecipient` returns `IO (Either ...)`, so `ExceptT . addRecipient st sId` works directly.
+
+- [ ] **Step 4: Build and verify**
+
+  Run: `cabal build`
+
+- [ ] **Step 5: Run existing tests**
+
+  Run: `cabal test --test-show-details=streaming --test-option=--match="/XFTP/"`
+
+- [ ] **Step 6: Format and commit**
+
+  ```bash
+  fourmolu -i src/Simplex/FileTransfer/Server/Store.hs src/Simplex/FileTransfer/Server.hs src/Simplex/FileTransfer/Server/StoreLog.hs
+  git add src/Simplex/FileTransfer/Server/Store.hs src/Simplex/FileTransfer/Server.hs src/Simplex/FileTransfer/Server/StoreLog.hs
+  git commit -m "refactor(xftp): change file store operations from STM to IO"
+  ```
+
+---
+
+## Task 4: Extract `FileStoreClass` typeclass, move STM impl to `Store/STM.hs`
+
+**Files:**
+- Rewrite: `src/Simplex/FileTransfer/Server/Store.hs`
+- Create: `src/Simplex/FileTransfer/Server/Store/STM.hs`
+- Modify: `src/Simplex/FileTransfer/Server/StoreLog.hs`
+- Modify: `src/Simplex/FileTransfer/Server/Env.hs`
+- Modify: `src/Simplex/FileTransfer/Server.hs`
+- Modify: `simplexmq.cabal`
+
+- [ ] **Step 1: Create `Store/STM.hs` — move all implementation code**
+
+  1. Create directory `src/Simplex/FileTransfer/Server/Store/`.
+  2. Create `src/Simplex/FileTransfer/Server/Store/STM.hs`.
+  3. Move from `Store.hs`: `FileStore` data type (rename to `STMFileStore`), all function implementations, internal helpers (`withFile`, `newFileRec`), all STM-specific imports.
+  4. Rename all `FileStore` references to `STMFileStore` in the new file.
+  5. Module declaration: `module Simplex.FileTransfer.Server.Store.STM` exporting only `STMFileStore (..)` — do NOT export standalone functions (`addFile`, `setFilePath`, etc.) to avoid name collisions with the typeclass methods from `Store.hs`.
+
+- [ ] **Step 2: Rewrite `Store.hs` as the typeclass module**
+
+  1. Add `{-# LANGUAGE TypeFamilies #-}` pragma to `Store.hs` (required for `type FileStoreConfig s` associated type).
+  2. Keep in `Store.hs`: `FileRec (..)`, `FileRecipient (..)`, `RoundedFileTime`, `fileTimePrecision` definitions and their `StrEncoding` instance.
+  3. Add `FileStoreClass` typeclass:
+     ```haskell
+     class FileStoreClass s where
+       type FileStoreConfig s
+
+       -- Lifecycle
+       newFileStore :: FileStoreConfig s -> IO s
+       closeFileStore :: s -> IO ()
+
+       -- File operations
+       addFile :: s -> SenderId -> FileInfo -> RoundedFileTime -> ServerEntityStatus -> IO (Either XFTPErrorType ())
+       setFilePath :: s -> SenderId -> FilePath -> IO (Either XFTPErrorType ())
+       addRecipient :: s -> SenderId -> FileRecipient -> IO (Either XFTPErrorType ())
+       getFile :: s -> SFileParty p -> XFTPFileId -> IO (Either XFTPErrorType (FileRec, C.APublicAuthKey))
+       deleteFile :: s -> SenderId -> IO (Either XFTPErrorType ())
+       blockFile :: s -> SenderId -> BlockingInfo -> Bool -> IO (Either XFTPErrorType ())
+       deleteRecipient :: s -> RecipientId -> FileRec -> IO ()
+       ackFile :: s -> RecipientId -> IO (Either XFTPErrorType ())
+
+       -- Expiration
+       expiredFiles :: s -> Int64 -> Int -> IO [(SenderId, Maybe FilePath, Word32)]
+
+       -- Stats
+       getUsedStorage :: s -> IO Int64
+       getFileCount :: s -> IO Int
+     ```
+  4. Do NOT re-export from `Store/STM.hs` — this would create a circular module dependency (Store.hs imports Store/STM.hs, Store/STM.hs imports Store.hs). Consumers must import `Store.STM` directly where they need `STMFileStore`.
+  5. Remove all STM-specific imports that are no longer needed.
+
+- [ ] **Step 3: Add `FileStoreClass` instance in `Store/STM.hs`**
+
+  1. Import `FileStoreClass` from `Simplex.FileTransfer.Server.Store`.
+  2. Inline all implementations directly in the instance body (do NOT delegate to standalone functions — the standalone names collide with typeclass method names, causing ambiguous occurrences for importers):
+     ```haskell
+     instance FileStoreClass STMFileStore where
+       type FileStoreConfig STMFileStore = ()
+       newFileStore () = do
+         files <- TM.emptyIO
+         recipients <- TM.emptyIO
+         pure STMFileStore {files, recipients}
+       closeFileStore _ = pure ()
+       addFile st sId fileInfo createdAt status = atomically $ ...
+       setFilePath st sId fPath = atomically $ ...
+       -- ... (each method's body is the existing function body, inlined)
+     ```
+  3. Remove the standalone top-level function definitions — they are now instance methods. Keep only `withFile` and `newFileRec` as internal helpers used by the instance methods.
+
+- [ ] **Step 4: Update importers**
+
+  1. `Env.hs`: add `import Simplex.FileTransfer.Server.Store.STM (STMFileStore (..))`. Change `FileStore` → `STMFileStore` in `XFTPEnv` type and `newXFTPServerEnv`. Change `store <- newFileStore` to `store <- newFileStore ()` (typeclass method now takes `FileStoreConfig STMFileStore` which is `()`). Keep `import Simplex.FileTransfer.Server.Store` for `FileRec`, `FileRecipient`, `FileStoreClass`, etc.
+  2. `Server.hs`: add `import Simplex.FileTransfer.Server.Store.STM`. Change `FileStore` → `STMFileStore` in any explicit type annotations. Import `FileStoreClass` from `Simplex.FileTransfer.Server.Store`.
+  3. `StoreLog.hs`: add `import Simplex.FileTransfer.Server.Store.STM` to access concrete `STMFileStore` type and store functions used during log replay. Change `FileStore` → `STMFileStore` in `readWriteFileStore` and `writeFileStore` parameter types.
+
+- [ ] **Step 5: Update cabal file**
+
+  Add `Simplex.FileTransfer.Server.Store.STM` to `exposed-modules` in the `!flag(client_library)` section, alongside existing XFTP server modules.
+
+- [ ] **Step 6: Build and verify**
+
+  Run: `cabal build`
+
+- [ ] **Step 7: Run existing tests**
+
+  Run: `cabal test --test-show-details=streaming --test-option=--match="/XFTP/"`
+
+- [ ] **Step 8: Format and commit**
+
+  ```bash
+  fourmolu -i src/Simplex/FileTransfer/Server/Store.hs src/Simplex/FileTransfer/Server/Store/STM.hs src/Simplex/FileTransfer/Server/Env.hs src/Simplex/FileTransfer/Server.hs src/Simplex/FileTransfer/Server/StoreLog.hs
+  git add src/Simplex/FileTransfer/Server/Store.hs src/Simplex/FileTransfer/Server/Store/STM.hs src/Simplex/FileTransfer/Server/Env.hs src/Simplex/FileTransfer/Server.hs src/Simplex/FileTransfer/Server/StoreLog.hs simplexmq.cabal
+  git commit -m "refactor(xftp): extract FileStoreClass typeclass, move STM impl to Store.STM"
+  ```
+
+---
+
+## Task 5: Make `XFTPEnv` and `Server.hs` polymorphic over `FileStoreClass`
+
+**Files:**
+- Modify: `src/Simplex/FileTransfer/Server/Env.hs`
+- Modify: `src/Simplex/FileTransfer/Server.hs`
+- Modify: `src/Simplex/FileTransfer/Server/Main.hs`
+- Modify: `tests/XFTPClient.hs` (if it calls `runXFTPServerBlocking` directly)
+
+- [ ] **Step 1: Make `XFTPEnv` polymorphic in `Env.hs`**
+
+  1. Add `XFTPStoreConfig` GADT: `data XFTPStoreConfig s where XSCMemory :: Maybe FilePath -> XFTPStoreConfig STMFileStore`.
+  2. Change `data XFTPEnv` to `data XFTPEnv s` — field `store :: FileStore` becomes `store :: s`.
+  3. Change `newXFTPServerEnv :: XFTPServerConfig -> IO XFTPEnv` to `newXFTPServerEnv :: FileStoreClass s => XFTPStoreConfig s -> XFTPServerConfig -> IO (XFTPEnv s)`.
+  4. Pattern match on `XSCMemory storeLogPath` in `newXFTPServerEnv` body. Create store via `newFileStore ()`, storeLog via `mapM (`readWriteFileStore` st) storeLogPath`.
+
+- [ ] **Step 2: Make `Server.hs` polymorphic**
+
+  1. Change `type M a = ReaderT XFTPEnv IO a` to `type M s a = ReaderT (XFTPEnv s) IO a`.
+  2. Add `FileStoreClass s =>` constraint to all functions using `M s a`. Use `forall s.` in signatures of functions that have `where`-block bindings with `M s` type annotations — `ScopedTypeVariables` requires explicit `forall` to bring `s` into scope for inner type signatures (matching SMP's `smpServer :: forall s. MsgStoreClass s => ...` pattern). Full list: `xftpServer`, `processRequest`, `verifyXFTPTransmission`, `processXFTPRequest` and all its `where`-bound functions (`createFile`, `addRecipients`, `receiveServerFile`, `sendServerFile`, `deleteServerFile`, `ackFileReception`, `retryAdd`, `addFileRetry`, `addRecipientRetry`), `deleteServerFile_`, `blockServerFile`, `deleteOrBlockServerFile_`, `expireServerFiles`, `randomId`, `getFileId`, `withFileLog`, `incFileStat`, `saveServerStats`, `restoreServerStats`, `randomDelay` (inside `#ifdef slow_servers` CPP block). Also update `encodeXftp` (line 236) and `runCPClient` (line 339) which use explicit `ReaderT XFTPEnv IO` instead of the `M` alias — change to `ReaderT (XFTPEnv s) IO`.
+  3. Change `runXFTPServerBlocking` and `runXFTPServer` to take `XFTPStoreConfig s` parameter.
+  4. Add `closeFileStore store` call to the server shutdown path (in the `finally` block or `stopServer` equivalent — after saving stats, before logging "Server stopped"). This ensures Postgres connection pool and `dbStoreLog` are properly closed. For STM this is a no-op.
+
+- [ ] **Step 3: Update `Main.hs` dispatch**
+
+  1. In `runServer`: construct `XSCMemory (enableStoreLog $> storeLogFilePath)`.
+  2. Add dispatch function that calls the updated `runXFTPServer` (which creates `started` internally):
+     ```haskell
+     run :: FileStoreClass s => XFTPStoreConfig s -> IO ()
+     run storeCfg = runXFTPServer storeCfg serverConfig
+     ```
+  3. Call `run` with the `XSCMemory` config.
+
+- [ ] **Step 4: Update test helper if needed**
+
+  If `tests/XFTPClient.hs` calls `runXFTPServerBlocking` directly, update the call to pass an `XSCMemory` config. Check the `withXFTPServer` / `serverBracket` helper.
+
+- [ ] **Step 5: Build and verify**
+
+  Run: `cabal build && cabal build test:simplexmq-test`
+
+- [ ] **Step 6: Run existing tests**
+
+  Run: `cabal test --test-show-details=streaming --test-option=--match="/XFTP/"`
+
+- [ ] **Step 7: Format and commit**
+
+  ```bash
+  fourmolu -i src/Simplex/FileTransfer/Server/Env.hs src/Simplex/FileTransfer/Server.hs src/Simplex/FileTransfer/Server/Main.hs
+  git add src/Simplex/FileTransfer/Server/Env.hs src/Simplex/FileTransfer/Server.hs src/Simplex/FileTransfer/Server/Main.hs tests/XFTPClient.hs simplexmq.cabal
+  git commit -m "refactor(xftp): make XFTPEnv and server polymorphic over FileStoreClass"
+  ```
+
+---
+
+## Task 6: Add Postgres config, migrations, and store skeleton
+
+**Files:**
+- Create: `src/Simplex/FileTransfer/Server/Store/Postgres/Config.hs`
+- Create: `src/Simplex/FileTransfer/Server/Store/Postgres/Migrations.hs`
+- Create: `src/Simplex/FileTransfer/Server/Store/Postgres.hs`
+- Modify: `src/Simplex/FileTransfer/Server/Env.hs`
+- Modify: `simplexmq.cabal`
+
+- [ ] **Step 1: Create `Store/Postgres/Config.hs`**
+
+  ```haskell
+  module Simplex.FileTransfer.Server.Store.Postgres.Config
+    ( PostgresFileStoreCfg (..),
+      defaultXFTPDBOpts,
+    )
+  where
+
+  import Simplex.Messaging.Agent.Store.Postgres.Options (DBOpts (..))
+  import Simplex.Messaging.Agent.Store.Shared (MigrationConfirmation)
+
+  data PostgresFileStoreCfg = PostgresFileStoreCfg
+    { dbOpts :: DBOpts,
+      dbStoreLogPath :: Maybe FilePath,
+      confirmMigrations :: MigrationConfirmation
+    }
+
+  defaultXFTPDBOpts :: DBOpts
+  defaultXFTPDBOpts =
+    DBOpts
+      { connstr = "postgresql://xftp@/xftp_server_store",
+        schema = "xftp_server",
+        poolSize = 10,
+        createSchema = False
+      }
+  ```
+
+- [ ] **Step 2: Create `Store/Postgres/Migrations.hs`**
+
+  Full migration module with `xftpServerMigrations :: [Migration]` and `m20260325_initial` containing CREATE TABLE SQL for `files` and `recipients` tables plus indexes. Follow SMP's `QueueStore/Postgres/Migrations.hs` pattern exactly: tuple list → `sortOn name . map migration`.
+
+- [ ] **Step 3: Create `Store/Postgres.hs` with stub instance**
+
+  1. Define `PostgresFileStore` with `dbStore :: DBStore` and `dbStoreLog :: Maybe (StoreLog 'WriteMode)`.
+  2. `instance FileStoreClass PostgresFileStore` with `error "not implemented"` for all methods except `newFileStore` (calls `createDBStore` + opens `dbStoreLog`) and `closeFileStore` (closes both). `type FileStoreConfig PostgresFileStore = PostgresFileStoreCfg`.
+  3. Add `withDB`, `handleDuplicate`, `assertUpdated`, `withLog` helpers.
+
+- [ ] **Step 4: Add `XSCDatabase` GADT constructor in `Env.hs` (CPP-guarded)**
+
+  ```haskell
+  #if defined(dbServerPostgres)
+  import Simplex.FileTransfer.Server.Store.Postgres (PostgresFileStore)
+  import Simplex.FileTransfer.Server.Store.Postgres.Config (PostgresFileStoreCfg)
+  #endif
+
+  data XFTPStoreConfig s where
+    XSCMemory :: Maybe FilePath -> XFTPStoreConfig STMFileStore
+  #if defined(dbServerPostgres)
+    XSCDatabase :: PostgresFileStoreCfg -> XFTPStoreConfig PostgresFileStore
+  #endif
+  ```
+
+- [ ] **Step 5: Update cabal**
+
+  Add to existing `if flag(server_postgres)` block:
+  ```
+  Simplex.FileTransfer.Server.Store.Postgres
+  Simplex.FileTransfer.Server.Store.Postgres.Config
+  Simplex.FileTransfer.Server.Store.Postgres.Migrations
+  ```
+
+- [ ] **Step 6: Build both ways**
+
+  Run: `cabal build && cabal build -fserver_postgres`
+
+- [ ] **Step 7: Format and commit**
+
+  ```bash
+  fourmolu -i src/Simplex/FileTransfer/Server/Store/Postgres.hs src/Simplex/FileTransfer/Server/Store/Postgres/Config.hs src/Simplex/FileTransfer/Server/Env.hs
+  git add src/Simplex/FileTransfer/Server/Store/Postgres.hs src/Simplex/FileTransfer/Server/Store/Postgres/Config.hs src/Simplex/FileTransfer/Server/Store/Postgres/Migrations.hs src/Simplex/FileTransfer/Server/Env.hs simplexmq.cabal
+  git commit -m "feat(xftp): add PostgreSQL store skeleton with schema migration"
+  ```
+
+---
+
+## Task 7: Implement `PostgresFileStore` operations
+
+**Files:**
+- Modify: `src/Simplex/FileTransfer/Server/Store/Postgres.hs`
+
+- [ ] **Step 1: Implement `addFile`**
+
+  `INSERT INTO files (sender_id, file_size, file_digest, sender_key, file_path, created_at, status) VALUES (?,?,?,?,NULL,?,?)`. Catch unique violation with `handleDuplicate` → `DUPLICATE_`. Call `withLog "addFile"` after.
+
+- [ ] **Step 2: Implement `getFile`**
+
+  For `SFSender`: `SELECT ... FROM files WHERE sender_id = ?`. Construct `FileRec` with `newTVarIO` per TVar field. `recipientIds = S.empty`.
+  For `SFRecipient`: `SELECT f.*, r.recipient_key FROM recipients r JOIN files f ON r.sender_id = f.sender_id WHERE r.recipient_id = ?`.
+
+- [ ] **Step 3: Implement `setFilePath`**
+
+  `UPDATE files SET file_path = ? WHERE sender_id = ? AND file_path IS NULL`. Use `assertUpdated`. Call `withLog "setFilePath"`.
+
+- [ ] **Step 4: Implement `addRecipient`**
+
+  `INSERT INTO recipients (recipient_id, sender_id, recipient_key) VALUES (?,?,?)`. `handleDuplicate` → `DUPLICATE_`. Call `withLog "addRecipient"`.
+
+- [ ] **Step 5: Implement `deleteFile`, `blockFile`**
+
+  `deleteFile`: `DELETE FROM files WHERE sender_id = ?` (CASCADE). `withLog "deleteFile"`.
+  `blockFile`: `UPDATE files SET status = ? WHERE sender_id = ?`. `assertUpdated`. `withLog "blockFile"`.
+
+- [ ] **Step 6: Implement `deleteRecipient`, `ackFile`**
+
+  `deleteRecipient`: `DELETE FROM recipients WHERE recipient_id = ?`. `withLog "deleteRecipient"`.
+  `ackFile`: same + return `Left AUTH` if 0 rows.
+
+- [ ] **Step 7: Implement `expiredFiles`, `getUsedStorage`, `getFileCount`**
+
+  `expiredFiles`: `SELECT sender_id, file_path, file_size FROM files WHERE created_at + ? < ? LIMIT ?`.
+  `getUsedStorage`: `SELECT COALESCE(SUM(file_size), 0) FROM files`.
+  `getFileCount`: `SELECT COUNT(*) FROM files`.
+
+- [ ] **Step 8: Add `ToField`/`FromField` instances**
+
+  For `RoundedFileTime` (Int64 wrapper), `ServerEntityStatus` (Text via StrEncoding), `C.APublicAuthKey` (Binary via `encodePubKey`/`decodePubKey`). Check SMP's `QueueStore/Postgres.hs` for existing instances to import.
+
+- [ ] **Step 9: Wrap mutation operations in `uninterruptibleMask_`**
+
+  Operations that combine a DB write with a TVar update (e.g., `getFile` constructs `FileRec` with `newTVarIO`) must be wrapped in `E.uninterruptibleMask_` to prevent async exceptions from leaving inconsistent state. Follow SMP's `addQueue_`, `deleteStoreQueue` pattern.
+
+- [ ] **Step 10: Build**
+
+  Run: `cabal build -fserver_postgres`
+
+- [ ] **Step 11: Format and commit**
+
+  ```bash
+  fourmolu -i src/Simplex/FileTransfer/Server/Store/Postgres.hs
+  git add src/Simplex/FileTransfer/Server/Store/Postgres.hs
+  git commit -m "feat(xftp): implement PostgresFileStore operations"
+  ```
+
+---
+
+## Task 8: Add INI config, Main.hs dispatch, startup validation
+
+**Files:**
+- Modify: `src/Simplex/FileTransfer/Server/Main.hs`
+- Modify: `src/Simplex/FileTransfer/Server/Env.hs`
+
+- [ ] **Step 1: Update `iniFileContent` in `Main.hs`**
+
+  Add to `[STORE_LOG]` section: `store_files: memory`, commented-out `db_connection`, `db_schema`, `db_pool_size`, `db_store_log` keys. Follow SMP's `optDisabled'` pattern for commented defaults.
+
+- [ ] **Step 2: Add `StartOptions` and `--confirm-migrations` flag**
+
+  ```haskell
+  data StartOptions = StartOptions
+    { confirmMigrations :: MigrationConfirmation
+    }
+  ```
+  Add to `Start` command parser with default `MCConsole`. Thread through to `runServer`.
+
+- [ ] **Step 3: Add store_files INI parsing and CPP-guarded Postgres dispatch**
+
+  In `runServer`: read `store_files` from INI (`fromRight "memory" $ lookupValue "STORE_LOG" "store_files" ini`). Add `"database"` branch (CPP-guarded) that constructs `PostgresFileStoreCfg` using `iniDBOptions ini defaultXFTPDBOpts` and `enableDbStoreLog'` pattern. Non-postgres build: `exitError`.
+
+- [ ] **Step 4: Add `XSCDatabase` branch in `newXFTPServerEnv` (`Env.hs`)**
+
+  CPP-guarded pattern match on `XSCDatabase dbCfg`: `newFileStore dbCfg`, `storeLog = Nothing`.
+
+- [ ] **Step 5: Add startup config validation**
+
+  Add `checkFileStoreMode` (CPP-guarded) before `run`: validate conflicting storeLog file + database mode, missing schema, etc. per design doc.
+
+- [ ] **Step 6: Build both ways**
+
+  Run: `cabal build && cabal build -fserver_postgres`
+
+- [ ] **Step 7: Format and commit**
+
+  ```bash
+  fourmolu -i src/Simplex/FileTransfer/Server/Main.hs src/Simplex/FileTransfer/Server/Env.hs
+  git add src/Simplex/FileTransfer/Server/Main.hs src/Simplex/FileTransfer/Server/Env.hs
+  git commit -m "feat(xftp): add PostgreSQL INI config, store dispatch, startup validation"
+  ```
+
+---
+
+## Task 9: Add database import/export CLI commands
+
+**Files:**
+- Modify: `src/Simplex/FileTransfer/Server/Main.hs`
+
+- [ ] **Step 1: Add `Database` CLI command (CPP-guarded)**
+
+  Add `Database StoreCmd DBOpts` constructor to `CliCommand`. Add `database` subcommand parser with `import`/`export` subcommands + `dbOptsP defaultXFTPDBOpts`.
+
+- [ ] **Step 2: Implement `importFileStoreToDatabase`**
+
+  1. `confirmOrExit` with database details.
+  2. Create temporary `STMFileStore`, replay StoreLog via `readWriteFileStore`.
+  3. Create `PostgresFileStore` with `createSchema = True`, `confirmMigrations = MCYesUp`.
+  4. Batch-insert files using PostgreSQL COPY protocol. Progress every 10k.
+  5. Batch-insert recipients using COPY protocol.
+  6. Verify counts: `SELECT COUNT(*)` — warn on mismatch.
+  7. Rename StoreLog to `.bak`.
+  8. Report counts.
+
+- [ ] **Step 3: Implement `exportDatabaseToStoreLog`**
+
+  1. `confirmOrExit`. Fail if output file exists.
+  2. Create `PostgresFileStore` from config.
+  3. Open StoreLog for writing.
+  4. Fold over file records: write `AddFile` (with status), `AddRecipients`, `PutFile` per file.
+  5. Close StoreLog, report counts.
+
+- [ ] **Step 4: Build**
+
+  Run: `cabal build -fserver_postgres`
+
+- [ ] **Step 5: Format and commit**
+
+  ```bash
+  fourmolu -i src/Simplex/FileTransfer/Server/Main.hs
+  git add src/Simplex/FileTransfer/Server/Main.hs
+  git commit -m "feat(xftp): add database import/export CLI commands"
+  ```
+
+---
+
+## Task 10: Add Postgres tests
+
+**Files:**
+- Modify: `tests/XFTPClient.hs`
+- Modify: `tests/Test.hs`
+- Create: `tests/CoreTests/XFTPStoreTests.hs`
+
+- [ ] **Step 1: Add test fixtures in `tests/XFTPClient.hs`**
+
+  ```haskell
+  testXFTPStoreDBOpts :: DBOpts
+  testXFTPStoreDBOpts =
+    DBOpts
+      { connstr = "postgresql://test_xftp_server_user@/test_xftp_server_db",
+        schema = "xftp_server_test",
+        poolSize = 10,
+        createSchema = True
+      }
+  ```
+  Add `testXFTPDBConnectInfo :: ConnectInfo` matching the connection string.
+
+- [ ] **Step 2: Add Postgres server test group in `tests/Test.hs`**
+
+  CPP-guarded block that runs existing `xftpServerTests` with Postgres store config, wrapped in `postgressBracket testXFTPDBConnectInfo`. Parameterize `withXFTPServer` to accept store config if needed.
+
+- [ ] **Step 3: Create `tests/CoreTests/XFTPStoreTests.hs` — unit tests**
+
+  Test `PostgresFileStore` operations directly:
+  - `addFile` + `getFile SFSender` round-trip.
+  - `addFile` duplicate → `DUPLICATE_`.
+  - `getFile` nonexistent → `AUTH`.
+  - `setFilePath` + verify `WHERE file_path IS NULL` guard.
+  - `addRecipient` + `getFile SFRecipient` round-trip.
+  - `deleteFile` cascades recipients.
+  - `blockFile` + verify status.
+  - `expiredFiles` batch semantics.
+  - `getUsedStorage`, `getFileCount` correctness.
+
+- [ ] **Step 4: Add migration round-trip test**
+
+  Create `STMFileStore` with test data (files + recipients + blocked status) → export to StoreLog → import to Postgres → export back → compare StoreLog files byte-for-byte.
+
+- [ ] **Step 5: Build and run tests**
+
+  ```bash
+  cabal build -fserver_postgres test:simplexmq-test
+  cabal test --test-show-details=streaming --test-option=--match="/XFTP/" -fserver_postgres
+  ```
+
+- [ ] **Step 6: Format and commit**
+
+  ```bash
+  fourmolu -i tests/CoreTests/XFTPStoreTests.hs tests/XFTPClient.hs
+  git add tests/CoreTests/XFTPStoreTests.hs tests/XFTPClient.hs tests/Test.hs
+  git commit -m "test(xftp): add PostgreSQL backend tests"
+  ```
@@ -0,0 +1,126 @@
+# BBS+ Bindings for simplexmq
+
+Haskell FFI bindings to libbbs for BBS+ signatures. General-purpose - the module knows nothing about specific applications.
+
+## How BBS+ works
+
+BBS+ signs a fixed list of N messages. Each message is an arbitrary byte array. The signer signs all N messages at once with one signature.
+
+The holder of the signature can then generate a proof that selectively discloses some messages and hides others. The verifier learns the disclosed messages and confirms they were signed by the signer, but learns nothing about the hidden messages. Different proofs from the same signature are unlinkable.
+
+Key constraint: the total number of messages N is fixed at signing time. The verifier must know N. A proof generated from a 3-message signature cannot be verified as a 2-message proof.
+
+## Types
+
+```haskell
+newtype BBSSecretKey = BBSSecretKey ByteString  -- 32 bytes
+newtype BBSPublicKey = BBSPublicKey ByteString  -- 96 bytes (BLS12-381 G2 point)
+newtype BBSSignature = BBSSignature ByteString  -- 80 bytes
+newtype BBSProof = BBSProof ByteString          -- 272 + 32 * numUndisclosed bytes
+newtype BBSHeader = BBSHeader ByteString        -- always-disclosed context (e.g. protocol identifier)
+newtype BBSPresHeader = BBSPresHeader ByteString -- random nonce for proof unlinkability
+```
+
+All newtypes get StrEncoding (base64url), ToJSON/FromJSON (via strToJSON/strParseJSON), Eq, Show.
+
+## Functions
+
+```haskell
+bbsKeyGen :: IO (Either String BBSKeyPair)  -- BBSKeyPair = (BBSPublicKey, BBSSecretKey)
+
+-- pk is derived from sk internally, so it is not a parameter
+bbsSign
+  :: BBSSecretKey
+  -> BBSHeader            -- always-disclosed context
+  -> [ByteString]         -- all N messages
+  -> IO (Either String BBSSignature)
+
+-- C order: pk, signature, header, presentation_header, disclosed_indexes, messages
+bbsProofGen
+  :: BBSPublicKey
+  -> BBSSignature
+  -> BBSHeader            -- must match what was signed
+  -> BBSPresHeader        -- random nonce bound into the proof
+  -> [Int]                -- disclosed indexes (0-based)
+  -> [ByteString]         -- all N messages (needed internally, hidden ones not revealed in proof)
+  -> IO (Either String BBSProof)
+
+-- C order: pk, proof, header, presentation_header, disclosed_indexes, n, messages
+bbsProofVerify
+  :: BBSPublicKey
+  -> BBSProof
+  -> BBSHeader            -- must match what was signed
+  -> BBSPresHeader        -- must match what was used in bbsProofGen
+  -> [Int]                -- disclosed indexes
+  -> Int                  -- total message count N
+  -> [ByteString]         -- disclosed messages only
+  -> IO Bool
+```
+
+## How applications use it
+
+An application defines:
+- A message layout: which index means what
+- Which indexes are disclosed vs hidden
+- How to encode application values as ByteString messages
+
+### Badge example (in simplex-chat, not in this module)
+
+Message layout (always 3 messages):
+- Index 0: master secret (32 random bytes) - HIDDEN
+- Index 1: expiry (UTF-8 encoded timestamp string) - DISCLOSED
+- Index 2: badge type (UTF-8 encoded, e.g. "supporter") - DISCLOSED
+
+Signing (v2, on the server):
+```
+bbsSign sk header [ms, encodeUtf8 "2026-07-31", encodeUtf8 "supporter"]
+```
+
+Proof generation (v2, on the client):
+```
+bbsProofGen pk sig header presHeader [1, 2] [ms, encodeUtf8 "2026-07-31", encodeUtf8 "supporter"]
+```
+
+Proof verification (v1, on the recipient):
+```
+bbsProofVerify pk proof header presHeader 3 [1, 2] [encodeUtf8 "2026-07-31", encodeUtf8 "supporter"]
+```
+
+The recipient only sees the proof, presentationHeader, expiry string, and badge type string. They verify these were signed by the server (pk is hardcoded). They never see the master secret.
+
+Expiry is always present as a string. Monthly badges use a date like `"2026-07-31"`, lifetime badges use `"lifetime"`. BBS+ doesn't interpret the bytes - expiry semantics are the application's responsibility. This keeps the message count fixed at 3 for all badge types.
+
+## libbbs C API mapping
+
+```c
+int bbs_keygen_full(ciphersuite, sk, pk)
+int bbs_sign(ciphersuite, sk, pk, signature, header, header_len, n, messages, message_lens)
+int bbs_proof_gen(ciphersuite, pk, signature, proof, header, header_len, presentation_header, presentation_header_len, disclosed_indexes, disclosed_indexes_len, n, messages, message_lens)
+int bbs_proof_verify(ciphersuite, pk, proof, proof_len, header, header_len, presentation_header, presentation_header_len, disclosed_indexes, disclosed_indexes_len, n, messages, message_lens)
+```
+
+We use `bbs_sha256_ciphersuite`. The header parameter is exposed in all Haskell functions - the application decides what to put there. Tests use `"SimpleX"` as header.
+
+The `presentation_header` parameter is what we call `presentationHeader`.
+
+In `bbs_proof_verify`, the `n` parameter is the total number of messages (not the number of disclosed messages). The `messages` array contains only the disclosed messages, and `disclosed_indexes` maps each to its position in the original message list.
+
+## Build
+
+Submodules in cbits/:
+- `cbits/libbbs` - https://github.com/Fraunhofer-AISEC/libbbs
+- `cbits/blst` - https://github.com/supranational/blst (libbbs dependency)
+
+C sources in cabal: `cbits/blst/src/server.c`, `cbits/blst/build/assembly.S`, libbbs source files.
+Include dirs: `cbits/blst/bindings/`, `cbits/blst/src/`, `cbits/libbbs/include/`, `cbits/libbbs/src/`.
+C flags: `-D__BLST_PORTABLE__` for cross-CPU-generation compatibility.
+
+## Tests
+
+- Keygen produces keys of correct size
+- Sign + proofGen + proofVerify roundtrip succeeds
+- Tampered proof fails verification
+- Tampered disclosed message fails verification
+- Wrong public key fails verification
+- Two proofs from same credential with different nonces both verify
+- Proof size matches expected (272 + 32 * numUndisclosed)
@@ -0,0 +1,57 @@
+## Root cause: orphaned `Sub` entries in the service client's `subscriptions` map
+
+**The leak is service-specific and was introduced by PR #1667 "messaging services" (`f0b7a4be`).** A long-lived messaging-service connection accumulates per-queue `Sub` records in its `Client.subscriptions` map that are **never removed** when the associated queues are deleted or unassociated — only the counter is decremented. Over normal queue churn the map grows monotonically for the entire lifetime of the service connection.
+
+### The proof — an asymmetry between two handlers in `serverThread`
+
+Both individual queue subscriptions and service subscriptions store a `Sub` per queue in `Client.subscriptions` (= `clientSubs` for the SMP subscriber thread, wired at `Server.hs:189`). When a queue ends/is deleted, the two paths diverge:
+
+**Individual subscriber — entry IS removed** (`Server.hs:332`, `346`):
+```haskell
+CSAEndSub qId -> atomically (endSub c qId) >>= a unsub_   -- :332
+  ...
+endSub c qId = TM.lookupDelete qId (clientSubs c) >>= (removeWhenNoSubs c $>)  -- :346
+```
+
+**Service subscriber — entry is NOT removed** (`Server.hs:336-340`):
+```haskell
+CSAEndServiceSub qId -> atomically $ do
+  modifyTVar' (clientServiceSubs c) decrease   -- decrements serviceSubsCount
+  modifyTVar' totalServiceSubs decrease        -- decrements global count
+  where decrease = subtractServiceSubs (1, queueIdHash qId)
+  -- never touches (clientSubs c) — the Sub for qId stays forever
+```
+
+### Where the orphaned entries are added (both new in this PR)
+- `Server.hs:1860-1862` — on service subscribe (`SSUB`), one `Sub` inserted per queue that has a pending message.
+- `Server.hs:2039-2043` (`newServiceDeliverySub`) — on **every** `SEND` to a service-associated queue with no existing sub, a `Sub` is inserted into the service client's `subscriptions`. After delivery the thread state resets to `NoSub` (`:2069`) but the map entry remains as a "already delivering" marker (`:1856-1859`).
+
+### Why they leak
+The only places the service client's `subscriptions` map is cleared are:
+- `clientDisconnected` — `swapTVar subscriptions M.empty` (`Server.hs:1097`) — only on disconnect.
+- `CSADecreaseSubs` — `swapTVar (clientSubs c) M.empty` (`Server.hs:343`) — only on full service takeover by another connection.
+- `delQueueAndMsgs` — `TM.lookupDelete entId $ subscriptions clnt` (`Server.hs:2164`) — but `clnt` here is **the recipient deleting its own queue, not the service client**. The service's entry for that queue is reached only via the `CSDeleted → endServiceSub → CSAEndServiceSub` path (`Server.hs:306, 313, 336`), which decrements the counter but leaves the map entry.
+
+**Concrete scenario (fully traced):** Service `S` subscribes (`SSUB`) and stays connected for days. Recipient `R` owns service-associated queue `Q`. A `SEND` to `Q` inserts a `Sub` into `S.subscriptions[Q]` (`:2042`). `R` later deletes `Q` → `delQueueAndMsgs` runs on `R`'s connection, removes `Q` from `R.subscriptions`, decrements counters, enqueues `CSDeleted Q (Just S)` (`:2167`) → `serverThread` runs `CSAEndServiceSub Q` for `S` (`:336`), decrementing `S.serviceSubsCount` but **leaving `S.subscriptions[Q]` in place**. Net: one orphaned `Sub` (record + 2 TVars) per service-associated queue ever deleted/unassociated, never reclaimed until `S` disconnects. The logical counter `serviceSubsCount` correctly drops, so the map size diverges from the counter — making the leak invisible to the existing service-sub metric.
+
+### Verdict
+This is a deterministic, static-provable memory leak — no production logging needed to confirm the existence; the asymmetry between `CSAEndSub` (removes) and `CSAEndServiceSub` (doesn't) is the smoking gun. It is specific to messaging-service certificate clients, which is exactly the population added by the services/certificate PR.
+
+### Secondary findings (lower impact, same PR area, not the primary cause)
+- **`forkClient` register-after-fork race** (`Server.hs:1356-1359`): if the forked action's `finally` delete (`:1358`) runs before the parent's `IM.insert` (`:1359`), a `Weak ThreadId` of a dead thread is left in `endThreads` until disconnect. Pre-existing, tiny per-entry, but exercised far more by the PR's higher END/DELD volume.
+- **Wrong-client counter decrement** (`Server.hs:2166`): `delQueueAndMsgs` decrements `serviceSubsCount` of the *deleting* client, not the service; harmless for non-service deleters (floored at 0) but corrupts accounting if a service deletes its own queue.
+
+---
+
+### Recommended fix (mirror `endSub` in the service path)
+Make `CSAEndServiceSub` also delete the per-queue `Sub` and cancel its delivery thread, exactly as `CSAEndSub`/`endSub` do for individual subscribers. Roughly:
+
+```haskell
+CSAEndServiceSub qId -> do
+  s_ <- atomically $ do
+    modifyTVar' (clientServiceSubs c) decrease
+    modifyTVar' totalServiceSubs decrease
+    TM.lookupDelete qId (clientSubs c) <* removeWhenNoSubs c
+  forM_ unsub_ $ \unsub -> mapM_ unsub s_
+  where decrease = subtractServiceSubs (1, queueIdHash qId)
+```
@@ -0,0 +1,152 @@
+# Server: batched SUB command processing
+
+Implementation plan for Part 1 of [RFC 2026-03-28-subscription-performance](../rfcs/2026-03-28-subscription-performance.md).
+
+## Current state
+
+When a batch of ~135 SUB commands arrives, the server already batches:
+- Queue record lookups (`getQueueRecs` in `receive`, Server.hs:1151)
+- Command verification (`verifyLoadedQueue`, Server.hs:1152)
+
+But command processing is per-command (`foldrM process` in `client`, Server.hs:1372-1375). Each SUB calls `subscribeQueueAndDeliver` which calls `tryPeekMsg` - one DB query per queue. For Postgres, that's ~135 individual `SELECT ... FROM messages WHERE recipient_id = ? ORDER BY message_id ASC LIMIT 1` queries per batch.
+
+## Goal
+
+Replace ~135 individual message peek queries with 1 batched query per batch. No protocol changes.
+
+## Implementation
+
+### Step 1: Add `tryPeekMsgs` to MsgStoreClass
+
+File: `src/Simplex/Messaging/Server/MsgStore/Types.hs`
+
+Add to `MsgStoreClass`:
+
+```haskell
+tryPeekMsgs :: s -> [StoreQueue s] -> ExceptT ErrorType IO (Map RecipientId Message)
+```
+
+Returns a map from recipient ID to earliest pending message for each queue that has one. Queues with no messages are absent from the map.
+
+### Step 2: Parameterize `deliver` to accept pre-fetched message
+
+File: `src/Simplex/Messaging/Server.hs`
+
+Currently `deliver` (inside `subscribeQueueAndDeliver`, line 1641) calls `tryPeekMsg ms q`. Add a parameter for an optional pre-fetched message:
+
+```haskell
+deliver :: Maybe Message -> (Bool, Maybe Sub) -> M s ResponseAndMessage
+deliver prefetchedMsg (hasSub, sub_) = do
+  stats <- asks serverStats
+  fmap (either ((,Nothing) . err) id) $ liftIO $ runExceptT $ do
+    msg_ <- maybe (tryPeekMsg ms q) (pure . Just) prefetchedMsg
+    ...
+```
+
+When `Nothing` is passed, falls back to individual `tryPeekMsg` (existing behavior). When `Just msg` is passed, uses it directly (batched path).
+
+### Step 3: Pre-fetch messages before the processing loop
+
+File: `src/Simplex/Messaging/Server.hs`
+
+Currently (lines 1372-1375):
+
+```haskell
+forever $
+  atomically (readTBQueue rcvQ)
+    >>= foldrM process ([], [])
+    >>= \(rs_, msgs) -> ...
+```
+
+Add a pre-fetch step before the existing loop:
+
+```haskell
+forever $ do
+  batch <- atomically (readTBQueue rcvQ)
+  msgMap <- prefetchMsgs batch
+  foldrM (process msgMap) ([], []) batch
+    >>= \(rs_, msgs) -> ...
+```
+
+`prefetchMsgs` scans the batch, collects queues from SUB commands that have a verified queue (`q_ = Just (q, _)`), calls `tryPeekMsgs` once, returns the map. For batches with no SUBs it returns an empty map (no DB call).
+
+`process` passes the looked-up message (or Nothing) through to `processCommand` and down to `deliver`.
+
+The `foldrM process` loop, `processCommand`, `subscribeQueueAndDeliver`, and all other command handlers stay structurally the same. Only `deliver` gains one parameter, and the `client` loop gains one pre-fetch call.
+
+### Step 4: Review
+
+Review the typeclass signature and server usage. Confirm the interface has the right shape before implementing store backends.
+
+### Step 5: Implement for each store backend
+
+#### Postgres
+
+File: `src/Simplex/Messaging/Server/MsgStore/Postgres.hs`
+
+Single query using `DISTINCT ON`:
+
+```sql
+SELECT DISTINCT ON (recipient_id)
+  recipient_id, msg_id, msg_ts, msg_quota, msg_ntf_flag, msg_body
+FROM messages
+WHERE recipient_id IN ?
+ORDER BY recipient_id, message_id ASC
+```
+
+Build `Map RecipientId Message` from results.
+
+#### STM
+
+File: `src/Simplex/Messaging/Server/MsgStore/STM.hs`
+
+Loop over queues, call `tryPeekMsg` for each, collect into map.
+
+#### Journal
+
+File: `src/Simplex/Messaging/Server/MsgStore/Journal.hs`
+
+Loop over queues, call `tryPeekMsg` for each, collect into map.
+
+### Step 6: Handle edge cases
+
+1. **Mixed batches**: `prefetchMsgs` collects only SUB queues. Non-SUB commands get Nothing for the pre-fetched message and process unchanged.
+
+2. **Already-subscribed queues**: Include in pre-fetch - `deliver` is called for re-SUBs too (delivers pending message).
+
+3. **Service subscriptions**: The pre-fetch doesn't care about service state. `sharedSubscribeQueue` handles service association in STM; message peek is the same.
+
+4. **Error queues**: Verification errors from `receive` are Left values in the batch. `prefetchMsgs` only looks at Right values with SUB commands.
+
+5. **Empty pre-fetch**: If batch has no SUBs (e.g., all ACKs), `prefetchMsgs` returns empty map, no DB call made.
+
+### Step 7: Batch other commands (future, not in scope)
+
+The same pattern (pre-fetch before loop, parameterize handler) can extend to:
+- `ACK` with `tryDelPeekMsg` - batch delete+peek
+- `GET` with `tryPeekMsg` - same map lookup
+
+Lower priority since these don't have the N-at-once pattern of subscriptions.
+
+## File changes summary
+
+| File | Change |
+|---|---|
+| `src/Simplex/Messaging/Server/MsgStore/Types.hs` | Add `tryPeekMsgs` to typeclass |
+| `src/Simplex/Messaging/Server/MsgStore/Postgres.hs` | Implement `tryPeekMsgs` with batch SQL |
+| `src/Simplex/Messaging/Server/MsgStore/STM.hs` | Implement `tryPeekMsgs` as loop |
+| `src/Simplex/Messaging/Server/MsgStore/Journal.hs` | Implement `tryPeekMsgs` as loop |
+| `src/Simplex/Messaging/Server.hs` | Add `prefetchMsgs`, parameterize `deliver` |
+
+## Testing
+
+1. Existing server tests must pass unchanged (correctness preserved).
+2. Add a test that subscribes a batch of queues (some with pending messages, some without) and verifies all get correct SOK + MSG responses.
+3. Prometheus metrics: existing `qSub` stat should still increment correctly.
+
+## Performance expectation
+
+For 300K queues across ~2200 batches:
+- Before: ~300K individual DB queries
+- After: ~2200 batched DB queries (one per batch of ~135)
+- ~136x reduction in DB round-trips
@@ -0,0 +1,126 @@
+# Server: batch queue service associations
+
+When a batch of SUB or NSUB commands arrives from a service client, each command that needs a new or removed service association calls `setQueueService` individually - one DB write per command. For 135 commands per batch, that's 135 individual `UPDATE msg_queues` queries.
+
+## Goal
+
+Reduce to at most 2 DB queries per batch (one for rcv associations, one for ntf associations), using `UPDATE ... RETURNING recipient_id` to identify which queues were actually updated.
+
+Also fuse message pre-fetch and association batching into a single batch preparation step with a clean contract.
+
+## Contract
+
+```haskell
+prepareBatch :: Maybe ServiceId -> NonEmpty (VerifiedTransmission s) -> M s (Either ErrorType (Map RecipientId (Maybe Message, Maybe (Either ErrorType ()))))
+```
+
+`Left e` = batch-level failure (message pre-fetch or association query failed entirely). All SUBs/NSUBs in the batch get this error.
+
+`Right map` = per-queue results as a tuple:
+- `Maybe Message` - pre-fetched message for SUB queues, `Nothing` for NSUB or no message
+- `Maybe (Either ErrorType ())` - association result. `Nothing` = no update needed. `Just (Right ())` = update succeeded. `Just (Left e)` = update failed for this queue.
+
+One map, one lookup per queue. `processCommand` passes both values to `subscribeQueueAndDeliver` / `subscribeNotifications` -> `sharedSubscribeQueue`.
+
+Queues not in the map (non-SUB/NSUB commands, failed verification) are not affected.
+
+## prepareBatch implementation
+
+One accumulating fold over the batch, collecting three lists:
+- `subMsgQs :: [StoreQueue s]` - SUB queues for message pre-fetch
+- `rcvAssocQs :: [StoreQueue s]` - SUB queues needing `rcv_service_id` update (`clntServiceId /= rcvServiceId qr`)
+- `ntfAssocQs :: [StoreQueue s]` - NSUB queues needing `ntf_service_id` update (`clntServiceId /= ntfServiceId` from `NtfCreds`)
+
+Classification reads from the already-loaded `QueueRec` in `VerifiedTransmission` - no extra DB query.
+
+Then three store calls (each skipped if its list is empty):
+1. `tryPeekMsgs ms subMsgQs` -> `Map RecipientId Message`
+2. `setRcvQueueServices (queueStore ms) clntServiceId rcvAssocQs` -> `Set RecipientId`
+3. `setNtfQueueServices (queueStore ms) clntServiceId ntfAssocQs` -> `Set RecipientId`
+
+Then one pass to merge results into `Map RecipientId (Maybe Message, Maybe (Either ErrorType ()))`:
+- For each SUB queue: `(M.lookup rId msgMap, assocResult rId rcvUpdated rcvAssocQs)`
+- For each NSUB queue: `(Nothing, assocResult rId ntfUpdated ntfAssocQs)`
+
+Where `assocResult rId updated assocQs` = if the queue was in `assocQs` (needed update), then `Just (Right ())` if `rId` is in `updated`, else `Just (Left AUTH)`. If not in `assocQs` (no update needed), `Nothing`.
+
+If any of the three calls fails entirely, return `Left e`.
+
+## Store interface
+
+Replace the polymorphic `setQueueServices` with two plain functions in `QueueStoreClass`:
+
+```haskell
+setRcvQueueServices :: s -> Maybe ServiceId -> [q] -> IO (Set RecipientId)
+setNtfQueueServices :: s -> Maybe ServiceId -> [q] -> IO (Set RecipientId)
+```
+
+No `SParty p` polymorphism. Each function knows its column.
+
+### Postgres implementation
+
+`setRcvQueueServices`:
+```sql
+UPDATE msg_queues SET rcv_service_id = ?
+WHERE recipient_id IN ? AND deleted_at IS NULL
+RETURNING recipient_id
+```
+
+`setNtfQueueServices`:
+```sql
+UPDATE msg_queues SET ntf_service_id = ?
+WHERE recipient_id IN ? AND notifier_id IS NOT NULL AND deleted_at IS NULL
+RETURNING recipient_id
+```
+
+After each batch query, for each queue in the returned set:
+1. Read QueueRec TVar, update with new serviceId
+2. Write store log entry
+
+### STM implementation
+
+Loop over queues, call existing per-item logic, collect succeeded `RecipientId`s into a Set.
+
+## Downstream changes in Server.hs
+
+### processCommand
+
+Gains one parameter: `Map RecipientId (Maybe Message, Maybe (Either ErrorType ()))`.
+
+SUB case: `M.lookup entId prepared` gives `Just (msg_, assocResult)` or `Nothing`. Pass both to `subscribeQueueAndDeliver`.
+
+NSUB case: `M.lookup entId prepared` gives `Just (Nothing, assocResult)` or `Nothing`. Pass `assocResult` to `subscribeNotifications`.
+
+Forwarded commands: pass `M.empty`.
+
+### subscribeQueueAndDeliver
+
+Takes `Maybe Message` and `Maybe (Either ErrorType ())` as before. No change in how it uses them.
+
+### sharedSubscribeQueue
+
+Takes `Maybe (Either ErrorType ())`. On paths needing association update:
+- `Just (Left e)` -> return error
+- `Just (Right ())` -> skip `setQueueService`, proceed with STM work
+- `Nothing` -> no update needed, proceed with existing logic
+
+## Implementation order (top-down)
+
+1. Define the `prepareBatch` contract and thread one map through `processCommand` -> `subscribeQueueAndDeliver` / `subscribeNotifications` -> `sharedSubscribeQueue` (Server.hs)
+2. Implement `prepareBatch` with the fold, three calls, and merge (Server.hs)
+3. Add `setRcvQueueServices` and `setNtfQueueServices` to `QueueStoreClass` (Types.hs)
+4. Implement for Postgres with batch `UPDATE ... RETURNING` (Postgres.hs)
+5. Implement for STM as loop (STM.hs)
+6. Implement for Journal as delegation (Journal.hs)
+
+At step 2, store functions can initially be stubs returning empty sets. Steps 3-6 fill in the real implementations.
+
+## Files changed
+
+| File | Change |
+|---|---|
+| `src/Simplex/Messaging/Server.hs` | `prepareBatch` with fold + merge; one map parameter through `processCommand` -> `subscribeQueueAndDeliver` / `subscribeNotifications` -> `sharedSubscribeQueue` |
+| `src/Simplex/Messaging/Server/QueueStore/Types.hs` | Add `setRcvQueueServices`, `setNtfQueueServices` to `QueueStoreClass` |
+| `src/Simplex/Messaging/Server/QueueStore/Postgres.hs` | Implement with batch `UPDATE ... RETURNING` + per-item TVar/log updates |
+| `src/Simplex/Messaging/Server/QueueStore/STM.hs` | Implement as loop |
+| `src/Simplex/Messaging/Server/MsgStore/Journal.hs` | Delegate to underlying store |
@@ -0,0 +1,455 @@
+# Server: SMP support for public namespaces
+
+> **⚠ Implementation diverged from this plan.** Six audit rounds reshaped the
+> original design. **The shipped code differs in several load-bearing ways:**
+>
+> - **Wire format**: `NameRecord` is now JSON (aeson), not the custom binary
+>   ABNF this plan documents. See `protocol/simplex-messaging.md` §Resolver
+>   commands and `src/Simplex/Messaging/Protocol.hs` ToJSON/FromJSON instances.
+> - **No cache**: the TTL + FIFO + byte-cap cache, in-flight coalescing,
+>   `psqueues` dep, and `cache_*` INI keys are all gone. Every RSLV becomes
+>   one `eth_call` bounded by `rpcMaxConcurrency` + `rpcTimeoutMs`. See
+>   `src/Simplex/Messaging/Server/Names.hs`.
+> - **No `allow_dangerous_colocation` flag**: the proxy co-location guard
+>   was demoted to a startup `logWarn` (the flag was always-on because
+>   `[PROXY]` has no enable toggle).
+> - **Module shape**: `Names/Resolver.hs` was merged into `Names.hs`; only
+>   `Names/Eth/RPC.hs` and `Names/Eth/SNRC.hs` remain as separate modules.
+> - **Test list**: of the 15 specs listed below, ~7 shipped; the rest were
+>   either superseded by the cache removal (CacheSpec) or deferred
+>   (ForwardedRslvSpec, MockRpcSpec, StartupGuardSpec, UrlValidationSpec,
+>   EipChecksumSpec).
+>
+> Sources of truth: `CHANGELOG.md` (release notes),
+> `protocol/simplex-messaging.md` §Resolver commands (wire format),
+> `src/Simplex/Messaging/Server/Names*.hs` (implementation). This file is
+> retained as historical context; do not treat it as a specification.
+
+Implementation plan for Part 2 of [RFC 2026-05-21-public-namespaces](https://github.com/simplex-chat/simplex-chat/blob/ep/namespace/docs/rfcs/2026-05-21-public-namespaces.md). Adds a forwarded-only `RSLV <lookup_key>` SMP command that returns `NAME <NameRecord>` read from the SNRC contract via a Reth+Nimbus JSON-RPC endpoint. Smp-server becomes name-capable by `[NAMES] enable: on`.
+
+Out of scope: `Simplex.Messaging.Client` API, agent-side resolution flow, `ServerRoles.names` in the agent, default-router list, reverse resolution, multicoin/text records, state proofs.
+
+## Architecture
+
+```mermaid
+sequenceDiagram
+  participant C as Client
+  participant P as Proxy (storage role)
+  participant N as Name server (names role)
+  participant E as Ethereum endpoint<br/>(Reth+Nimbus)
+
+  C ->> P: PFWD(enc(RSLV key))
+  P ->> N: RFWD(enc(RSLV key))
+  note over N: verifyTransmission True →<br/>vc SResolver (RSLV _) → VRVerified
+  N ->> N: cache lookup
+  alt cache miss
+    N ->> E: eth_call(SNRC, namehash(key))
+    E -->> N: ABI bytes
+    note over N: ABI decode + zero-owner check + cache insert
+  end
+  N -->> P: RFWD(enc(NAME rec | ERR AUTH))
+  P -->> C: PRES(enc(NAME rec | ERR AUTH))
+```
+
+RSLV is **forwarded-only** — direct RSLV is rejected `CMD PROHIBITED`. This preserves the RFC's two-server resolution: the name server sees the lookup key but never the client's IP, session, or identity.
+
+## Protocol
+
+Shared library: `src/Simplex/Messaging/Protocol.hs` and `src/Simplex/Messaging/Transport.hs`.
+
+**Version.** `Transport.hs:226`: `namesSMPVersion = VersionSMP 20`. Bump `currentClientSMPRelayVersion`, `currentServerSMPRelayVersion`, `proxiedSMPRelayVersion` to 20. Pre-v20 binaries lack the `RSLV_` tag; v20 binaries with sessions negotiated at v < 20 reject `RSLV_` at the parameter parser. The proxied-version bump 18 → 20 is safe (v19's `RecipientService`/`NotifierService` aren't in the forwarded whitelist; v18's `BLOCKED info` is already version-branched at `Protocol.hs:1943`).
+
+**Party kind.** Append `Resolver` to `Party` (line 335); add `SResolver` (line 349), `TestEquality` clause (line 361), `PartyI Resolver` (line 394). `queueParty SResolver = Nothing` (falls through line 412). `partyClientRole SResolver = Nothing`.
+
+**`RSLV` command.**
+
+```haskell
+RSLV :: LookupKey -> Command Resolver
+newtype LookupKey = LookupKey ByteString
+
+instance Encoding LookupKey where
+  smpEncode (LookupKey s) = smpEncode s
+  smpP = do
+    n <- lenP
+    when (n > 64) $ fail "LookupKey too large"
+    LookupKey <$> A.take n
+```
+
+Name-syntax validation is client-side per RFC; the server treats the key as opaque bytes. Tag `"RSLV"`, version guard inside `protocolP v (CT SResolver RSLV_)`: `| v >= namesSMPVersion -> Cmd SResolver . RSLV <$> _smpP`.
+
+**Testnet/mainnet selector**: how the `#testnet:name` namespace appears in `LookupKey` bytes is determined by the SNRC contract (Part 1) — confirm with Part 1 before merging.
+
+**`NAME` response.**
+
+```haskell
+NAME :: NameRecord -> BrokerMsg
+```
+
+Tag `"NAME"`. Symmetric version guards on encode (in `encodeProtocol v`) and decode (in `protocolP v NAME_`): `| v >= namesSMPVersion -> ...`. `NameRecord` has **no `Encoding` typeclass instance** — the typeclass cannot version-branch. Use top-level helpers `nameRecBytes :: VersionSMP -> NameRecord -> ByteString` and `parseNameRec :: VersionSMP -> Parser NameRecord`, mirroring the `IDS QIK` precedent at `Protocol.hs:1912–1979`.
+
+**`NameRecord` schema and wire layout.**
+
+```haskell
+data NameRecord = NameRecord
+  { nrDisplayName  :: Text                    -- ≤255 bytes UTF-8
+  , nrOwner        :: NameOwner               -- 20 raw bytes
+  , nrChannelLinks :: [NameLink]
+  , nrContactLinks :: [NameLink]
+  , nrAdminAddress :: Maybe Text
+  , nrAdminEmail   :: Maybe Text
+  , nrExpiry       :: Int64                   -- Unix seconds, ≥ 0
+  , nrIsTest       :: Bool
+  }
+
+newtype NameOwner = NameOwner ByteString   -- bare ctor NOT exported; smart ctor enforces length 20
+newtype NameLink  = NameLink  Text         -- bare ctor NOT exported; smart ctor enforces ≤1024 bytes
+
+unNameOwner :: NameOwner -> ByteString
+unNameOwner (NameOwner bs) = bs
+
+unNameLink :: NameLink -> Text
+unNameLink (NameLink t) = t
+```
+
+Field additions are gated by future SMP version bumps (matching the `IDS QIK` precedent at `Protocol.hs:1912–1979`) — no separate record-version field.
+
+| Field | Encoding | Max bytes |
+|---|---|---|
+| `nrDisplayName` | 1-byte length prefix + UTF-8 | 1 + 255 |
+| `nrOwner` | 20 raw bytes, no prefix | 20 |
+| `nrChannelLinks`, `nrContactLinks` | 1-byte count + per-element (Word16 BE len + UTF-8); combined cap **8 entries** across both lists | 1 + Σ(2 + ≤1024) |
+| `nrAdminAddress`, `nrAdminEmail` | `'0'` or `'1'` + (1-byte length + UTF-8 if `'1'`) | 1 + 1 + 255 |
+| `nrExpiry` | two big-endian `Word32` | 8 |
+| `nrIsTest` | `'T'` or `'F'` | 1 |
+
+`Encoding NameLink` reads the Word16 length **before** `A.take` allocates — going through the existing `Large` wrapper allows up to 65 535 bytes per element. There is no `Encoding [a]` instance — use `smpEncodeList` / `smpListP` / a bounded variant:
+
+```haskell
+smpListPUpTo :: Encoding a => Int -> Parser [a]
+smpListPUpTo cap = do
+  n <- lenP
+  when (n > cap) $ fail "list too long"
+  A.count n smpP
+
+parseNameRec _v = do
+  nrDisplayName  <- smpP
+  nrOwner        <- smpP
+  nrChannelLinks <- smpListPUpTo 8
+  nrContactLinks <- smpListPUpTo (8 - length nrChannelLinks)
+  nrAdminAddress <- smpP
+  nrAdminEmail   <- smpP
+  nrExpiry       <- smpP
+  when (nrExpiry < 0) $ fail "expiry must be non-negative"
+  nrIsTest       <- smpP
+  pure NameRecord{..}
+```
+
+Both list parsers fail at the count step before allocating; the second inherits the residual budget. Canonical encoding by construction: every primitive has exactly one valid byte form — two name servers reading the same SNRC state produce byte-identical responses.
+
+**Wire-size budget.** `paddedProxiedTLength = 16226` is the plaintext input to `cbEncrypt` (`Server.hs:2117`); `pad` reserves 2 bytes → framed transmission ≤ 16 224 bytes. Combined-link cap 8 yields max payload ≈ 9 050 bytes — generous margin.
+
+**Error semantics.** A single wire code: `ERR AUTH`. Per RFC, this collapses every failure (name not found, malformed key, names disabled, RPC unreachable, decode error, timeout). Resolver internally distinguishes the cause for stats only.
+
+**Forwarded-only access.** Direct RSLV is rejected with `CMD PROHIBITED`. The shape of `THAuthServer` alone cannot discriminate direct from forwarded (`Transport.hs:852` sets `sessSecret' = Just _` for every v6+ direct client too). An explicit `forwarded :: Bool` flag is threaded through `verifyTransmission` (see below).
+
+## Server changes
+
+All edits in `src/Simplex/Messaging/Server.hs`.
+
+**`forwarded :: Bool` plumbing.** Three signatures change:
+
+- `verifyTransmission :: Bool -> ...` (line 1233) — direct path passes `False` (lines 1152–1153), forwarded path passes `True` (line 2129).
+- `verifyLoadedQueue :: Bool -> ...` (line 1238) — receives the flag from `verifyTransmission` (lines 1235, 1240).
+- `verifyQueueTransmission :: Bool -> ...` (line 1244) — receives and uses the flag.
+
+New `vc` clauses inside `verifyQueueTransmission`:
+
+```haskell
+vc SResolver (RSLV _) | forwarded = VRVerified Nothing
+                      | otherwise = VRFailed (CMD PROHIBITED)
+vc SResolver _ = VRFailed (CMD PROHIBITED)   -- defensive catch-all
+```
+
+**Forwarded whitelist** (`Server.hs:2132`):
+
+```haskell
+Cmd SResolver (RSLV _) -> True
+```
+
+**`processCommand` branch** (alongside line 1481):
+
+```haskell
+Cmd SResolver (RSLV (LookupKey key)) -> do
+  st <- asks (rslvStats . serverStats)
+  incStat (rslvReqs st)
+  asks namesEnv >>= \case
+    Nothing -> incStat (rslvDisabled st)  $> response (corrId, NoEntity, ERR AUTH)
+    Just nenv -> liftIO (resolveName nenv key) >>= \case
+      Right rec     -> incStat (rslvSucc st)     $> response (corrId, NoEntity, NAME rec)
+      Left NotFound -> incStat (rslvNotFound st) $> response (corrId, NoEntity, ERR AUTH)
+      Left _        -> incStat (rslvEthErrs st)  $> response (corrId, NoEntity, ERR AUTH)
+```
+
+**Shutdown.** Add `closeNamesEnv :: NamesEnv -> IO ()` calling `closeManager`. Wire into `closeServer` (`Server.hs:247`):
+
+```haskell
+closeServer = do
+  asks (smpAgent . proxyAgent) >>= liftIO . closeSMPClientAgent
+  asks namesEnv >>= liftIO . mapM_ closeNamesEnv
+```
+
+In-flight `resolveName` calls during shutdown receive `ConnectionClosed` → `EthHttpErr` → masked-leader cleanup runs → waiters unblock with `ERR AUTH`.
+
+**`incStat` relocation.** Defined at `Server.hs:2220`, currently unexported. Move to `Server/Stats.hs` (one-line transplant + export) so `Resolver.hs` can use it.
+
+**Co-located proxy warning.** `newEnv` logs a startup warning whenever `allowSMPProxy = True` and `namesConfig = Just _`. RSLV is the first slow forwarded command; on a proxy host it can serialise other forwarded commands on the same proxy-relay session up to `rpcTimeoutMs` per cache miss. The warning is not a hard refusal because `[PROXY]` has no `enable: on/off` toggle — proxy is always on for every smp-server. `forkForwardedCmd` async dispatch is the longer-term fix, tracked as a follow-up; once the proxy role is gateable per-server, the warning can be tightened back to a refusal.
+
+## Resolver subtree
+
+New module tree at `src/Simplex/Messaging/Server/Names/`:
+
+| Module | Contents |
+|---|---|
+| `Names.hs` | Façade — re-exports `NamesConfig`, `NamesEnv`, `ResolveError`, `resolveName`, `newNamesEnv`, `closeNamesEnv`. |
+| `Names/Resolver.hs` | All types + cache + in-flight + `resolveName`. Helpers exported directly (no `.Internal` per codebase convention). **Test seam**: `NamesEnv` holds `ethCall` as a function value, so tests construct stubs via `newNamesEnvWith`. |
+| `Names/Eth/RPC.hs` | `EthRpcEnv`; `ethCallReal` via `http-client` + `withResponse` + `brReadSome rpcMaxResponseBytes`. JSON-RPC error / HTTP error split. `rpcMaxConcurrency` semaphore. `Authorization` header from `rpcAuth`. |
+| `Names/Eth/SNRC.hs` | `EthAddress`, Keccak-256 namehash via `crypton`'s `Crypto.Hash.Algorithms.Keccak_256` (mirroring `Crypto.hs:1023–1025` for SHA3), hand-rolled bounded Solidity ABI codec, `getRecord` with zero-owner detection. **Ethereum's Keccak ≠ NIST SHA3-256.** |
+
+**ABI codec invariants**, enforced before any allocation: `offset + 32 ≤ buf.length`; `offset + 32 + length ≤ buf.length`; `offset ≥ headEnd` (no backward jumps); every length ≤ per-field cap; `string[]` outer length × 32 ≤ buf.length; recursion depth ≤ 2; `uint256 → Int64` rejects if any high 24 bytes non-zero; UTF-8 via `decodeUtf8'` returns `EthDecodeErr`.
+
+**Zero-owner → `NotFound`**: ENS-style resolvers return zeroed records for non-existent names. After ABI decode, if `nrOwner == NameOwner (B.replicate 20 0)` return `Left NotFound`.
+
+**Errors.**
+
+```haskell
+data ResolveError = NotFound | EthHttpErr | EthRpcErr { rpcCode :: Int, rpcMessage :: Text }
+                  | EthDecodeErr | TimedOut
+```
+
+All collapse to `ERR AUTH`. `EthRpcErr` carries JSON-RPC `error` object — method-not-found (SNRC not deployed at `snrc_address`) is logged immediately on the first error after a recent success: `logError "NAMES: JSON-RPC error from endpoint — check snrc_address: <code> <message>"`. No automatic retry.
+
+**Cache.** TTL + FIFO eviction. `TVar (OrdPSQ LookupKey Word64 NameRecord, Int)` — priority = monotonic-ns at insert; the `Int` is running byte count. `cacheLookup` is one STM transaction (read, expiry-check, expired-delete-with-byte-decrement). `cacheInsert` is one STM transaction: while `size > cacheMaxEntries` OR `bytes + sizeOf(rec) > cacheMaxBytes`, `minView` to drop oldest, then `insert`. Byte counter prevents `100 000 × 9 KB ≈ 900 MB` worst-case blow-up.
+
+**Request coalescing** (async-exception safe via `E.mask`):
+
+```haskell
+resolveName env bs = do
+  let k = LookupKey bs
+  now <- getMonotonicTimeNSec
+  atomically (cacheLookup env k now) >>= \case
+    Just rec -> incStat (rslvCacheHits ...) $> Right rec
+    Nothing  -> do
+      incStat (rslvCacheMiss ...)
+      ticket <- atomically $ TM.lookup k (inflight env) >>= \case
+        Just mv -> pure (Waiter mv)
+        Nothing -> newEmptyTMVar >>= \mv -> TM.insert k mv (inflight env) $> Leader mv
+      case ticket of
+        Waiter mv -> atomically (readTMVar mv)
+        Leader mv -> E.mask $ \restore -> do
+          r <- restore (fetchOnceTimed env bs)
+                 `E.catch` \(e :: E.SomeException) -> pure (Left (mapEthErr e))
+          atomically $ putTMVar mv r >> TM.delete k (inflight env)
+          case r of Right rec -> atomically (cacheInsert env k now rec); Left _ -> pure ()
+          pure r
+
+fetchOnceTimed env bs =
+  System.Timeout.timeout (rpcTimeoutMs (config env) * 1000) (fetchOnce env bs) >>= \case
+    Just r  -> pure r
+    Nothing -> pure (Left TimedOut)
+```
+
+`E.mask` ensures `putTMVar + TM.delete` runs even on async exception; `fetchOnceTimed` runs under `restore` so it remains interruptible. Waiters always see a value; the in-flight TMap entry is always removed.
+
+`fetchOnce`, `mapEthErr`, `scrubUrl`, `cacheLookup`, `cacheInsert` are internal to `Resolver.hs`. `getMonotonicTimeNSec` from `GHC.Clock` — first monotonic-clock use in the codebase; clock-jump safe.
+
+**STM contention.** Cache hits are read-only `readTVar` — STM scales. Cache writes under sustained miss traffic can retry; `CacheSpec` asserts < 5% retry at 4 readers + 1 writer @ 1k RPS. If observed higher, swap `TVar` for `IORef` + `atomicModifyIORef'`.
+
+**Multicoin and text records** are not in `NameRecord`. If Part 1 contract returns them from `getRecord`, extend `NameRecord` and the wire-size budget. **Confirm with Part 1 author before implementing `Eth/SNRC.hs`.**
+
+## Configuration
+
+`ServerConfig` (`Env/STM.hs:142`) gains one field `namesConfig :: Maybe NamesConfig`. `Env` (`Env/STM.hs:261`) gains `namesEnv :: Maybe NamesEnv`. `newEnv` constructs it after `proxyAgent` (line 605) with the co-location guard.
+
+```haskell
+data NamesConfig = NamesConfig
+  { ethereumEndpoint     :: Text          -- http(s), no userinfo, explicit port required
+  , snrcAddress          :: NameOwner     -- 20 bytes
+  , rpcAuth              :: Maybe RpcAuth -- required when https & non-loopback host
+  , cacheSeconds         :: Int           -- 300
+  , cacheMaxEntries      :: Int           -- 100000
+  , cacheMaxBytes        :: Int           -- 67108864 (64 MB)
+  , rpcTimeoutMs         :: Int           -- 3000
+  , rpcMaxResponseBytes  :: Int           -- 262144 (256 KB)
+  , rpcMaxConcurrency    :: Int           -- 8
+  }
+
+data RpcAuth = AuthBearer Text | AuthBasic Text Text
+```
+
+INI parsing in `Server/Main.hs`:
+
+- `validateUrl` (using new `network-uri` dep): accepts only http(s), non-empty host, **explicit port** (rejects `http://localhost` defaulting to 80 while Reth is on 8545), no userinfo, no query/fragment. Rejects `https://...` without `rpc_auth` when host is non-loopback. On rejection: `logError` + `exitFailure`.
+- `parseEthAddr`: accepts `0x[0-9a-fA-F]{40}` and the same without `0x`. Mixed-case → verify EIP-55 checksum and reject mismatch (catches typos).
+- `parseRpcAuth`: reads optional `rpc_auth` key; format `bearer <token>` or `basic <user>:<pass>`.
+- `scrubUrl`: strips userinfo from all log lines mentioning the endpoint, including inside `mapEthErr`.
+- Transition-aware error logging: log immediately on first error after a recent success, then at most hourly while persisting + summary at every stats reset.
+
+Default INI template (`Server/Main/Init.hs`, after `[PROXY]`):
+
+```
+[NAMES]
+# Public-namespace resolution (SNRC on Ethereum).
+# Requires an Ethereum JSON-RPC endpoint (Reth+Nimbus). See deployment guide.
+# Cannot be combined with [PROXY] enable: on by default — see allow_dangerous_colocation.
+# Restart required to change settings.
+enable: off
+# Same-host:
+# ethereum_endpoint: http://127.0.0.1:8545
+# Central Reth via Caddy:
+# ethereum_endpoint: https://eth.simplex.chat:443
+# rpc_auth: basic <username>:<password>
+# snrc_address: 0x0000000000000000000000000000000000000000
+# cache_seconds: 300
+# cache_max_entries: 100000
+# cache_max_bytes: 67108864
+# rpc_timeout_ms: 3000
+# rpc_max_response_bytes: 262144
+# rpc_max_concurrency: 8
+# allow_dangerous_colocation: off
+```
+
+Upgrade from a pre-v6.6 INI: missing `[NAMES]` section → disabled. No operator action required.
+
+## Operator deployment
+
+Two supported topologies. smp-server is agnostic — only `ethereum_endpoint` changes.
+
+**Topology A (same-host)**: smp-server, Caddy (optional), Reth, Nimbus all on one box. `ethereum_endpoint: http://127.0.0.1:8545`.
+
+**Topology B (central Reth, N smp-server hosts — recommended for fleets)**: one operator runs one eth host with Reth+Nimbus behind Caddy on public HTTPS. Each smp-server has its own credential.
+
+```mermaid
+flowchart LR
+  subgraph eth-host
+    Caddy["Caddy<br/>(public :443, basic auth)"]
+    Reth["Reth<br/>(127.0.0.1:8545)"]
+    Nimbus["Nimbus"]
+    Caddy --> Reth
+    Nimbus -- Engine API (jwt.hex) --> Reth
+  end
+  subgraph smp-host-1
+    S1["smp-server #1"]
+  end
+  subgraph smp-host-N
+    SN["smp-server #N"]
+  end
+  S1 -- HTTPS + Authorization --> Caddy
+  SN -- HTTPS + Authorization --> Caddy
+  Reth <-- Ethereum p2p --> internet
+  Nimbus <-- beacon sync --> internet
+```
+
+Sharing one Reth across **multiple operators** is **not** supported — collapses the RFC's two-server resolution privacy.
+
+**Reth + Nimbus**: Reth (execution layer) holds Ethereum state on ~260 GB pruned NVMe; Nimbus (consensus light client) follows beacon-chain headers. Paired via Engine API on `127.0.0.1:8551` with a shared `jwt.hex`. Recommended Reth flags:
+
+```bash
+reth node \
+  --http.addr 127.0.0.1 \
+  --http.api eth \                     # only eth namespace
+  --rpc.gascap 50000000 \              # cap gas per eth_call
+  --rpc.max-response-size 5242880 \    # 5 MB
+  --http.corsdomain none \
+  --authrpc.jwtsecret /opt/eth/jwt.hex \
+  --authrpc.addr 127.0.0.1 --authrpc.port 8551
+```
+
+**Caddy + Let's Encrypt + Basic auth** (Topology B):
+
+```caddy
+eth.simplex.chat {
+  basicauth {
+    smp-server-1 $2a$14$<bcrypt-hash-1>
+    smp-server-2 $2a$14$<bcrypt-hash-2>
+  }
+  log { format filter { wrap json; fields { request>headers>Authorization delete } } }
+  reverse_proxy 127.0.0.1:8545
+}
+```
+
+Caddy auto-fetches Let's Encrypt cert. Each smp-server has its own credential; revoking one = delete the line. `Authorization` stripped from access logs. Port 80 needed for the ACME HTTP-01 challenge (use TLS-ALPN-01 or DNS-01 to drop it). The threat being defended against is DoS (SNRC state is public); mTLS would be overkill. WireGuard/Tailscale are alternative network-layer approaches — both compatible with the plan.
+
+**Capacity.** One Reth+Nimbus box handles a realistic operator fleet by 10–1000× margin. Per-smp-server peak RSLV ≈ 1700 RPS (pessimistic); cache hit rate ≥ 95% → ~85 RPS cache miss per smp-server; 10 smp-servers → ~850 RPS aggregate cache miss reaching Reth; Reth `eth_call` throughput on warm NVMe ≈ 1k–10k RPS. Sizing: 8 vCPU, 32 GB RAM, 1 TB NVMe is comfortable. Scale-out path: more Reth+Nimbus pairs, smp-servers round-robin or shard.
+
+## Implementation
+
+**Order**:
+
+1. Protocol: party/SParty/PartyI, RSLV+tag, NAME+tag, NameRecord + helpers, version constants in `Transport.hs`.
+2. `verifyTransmission`/`verifyLoadedQueue`/`verifyQueueTransmission` `forwarded :: Bool` flag + `vc SResolver` clauses.
+3. Forwarded whitelist + `processCommand` branch + `incStat` move to `Stats.hs`.
+4. Env plumbing: `Server/Env/STM.hs`, `Server/Main.hs` INI parse, `Server/Main/Init.hs` template.
+5. Resolver subtree: `Eth/SNRC.hs` → `Eth/RPC.hs` → `Resolver.hs`.
+6. `NameResolverStats` sub-record + CSV log + Prometheus `names =` block.
+7. Replace stub in (3) with real `resolveName`.
+8. Tests.
+9. `protocol/simplex-messaging.md`: header version line 1 (`19 → 20`), sentence at line 86, version-history list (lines 93–105) v20 entry, TOC (lines 25–68) "Resolver commands" subsection, new section with ABNF + byte layout + error semantics, "Router security requirements" paragraph about names-role outbound HTTP, cross-ref `Transport.hs:226`.
+10. `CHANGELOG.md`: v6.6 entry.
+
+**Cabal** (`simplexmq.cabal`): bump `version: 6.6.0.0`. Add to `if !flag(client_library)` block: `http-client >=0.7 && <0.8`, `http-client-tls >=0.3 && <0.4`, `network-uri >=2.6 && <2.7`, `psqueues >=0.2.7 && <0.3`. Expose 4 new `Server.Names.*` modules in the same block. `crypton` already provides `Keccak_256`.
+
+**Files changed**:
+
+| File | Change |
+|---|---|
+| `Protocol.hs` | Resolver party + RSLV/NAME tags + version guards; `NameRecord` + newtypes + smart ctors; `nameRecBytes`/`parseNameRec`/`smpListPUpTo` helpers (no Encoding NameRecord instance); `LookupKey` parser-side cap |
+| `Transport.hs` | `namesSMPVersion = 20`; bump current/proxied SMP versions |
+| `Server.hs` | Thread `forwarded :: Bool`; `vc SResolver` clauses; whitelist (2132); Resolver branch in `processCommand` (1481); `closeServer` calls `closeNamesEnv`; CSV log (579–618); **remove** local `incStat` |
+| `Server/Env/STM.hs` | `namesConfig` field; `namesEnv` field; `newEnv` constructs `NamesEnv` with co-location guard |
+| `Server/Main.hs` | `[NAMES]` parse: `validateUrl`/`parseEthAddr`/`parseRpcAuth`; `scrubUrl` in logs |
+| `Server/Main/Init.hs` | `[NAMES]` block in default INI |
+| `Server/Stats.hs` | `incStat` moved here + exported; `NameResolverStats` sub-record + helpers; `rslvStats` field |
+| `Server/Prometheus.hs` | `names =` metric block |
+| `Server/Names.hs` (new) | Façade re-exports |
+| `Server/Names/Resolver.hs` (new) | All resolver types + cache + coalescing + `fetchOnceTimed` + `newNamesEnv[With]` + `closeNamesEnv` |
+| `Server/Names/Eth/RPC.hs` (new) | `EthRpcEnv`, `ethCallReal` with bounded body + concurrency semaphore + `Authorization` header |
+| `Server/Names/Eth/SNRC.hs` (new) | `EthAddress`, Keccak namehash, bounded ABI (8 invariants), `getRecord` with zero-owner detection |
+| `simplexmq.cabal` | Bump `6.6.0.0`; 4 new deps + 4 new modules in `if !flag(client_library)` block |
+| `protocol/simplex-messaging.md` | Header version, version-history v20 entry, new "Resolver commands" section |
+| `CHANGELOG.md` | v6.6 entry |
+
+## Testing
+
+`tests/SMPNamesTests/` registered in `tests/Test.hs:112–151`. Build only when `client_library = False`.
+
+1. **ProtocolEncodingSpec** — `nameRecBytes` ↔ `parseNameRec` round-trip; oversized fields rejected at parse; combined-list cap 8 enforced; negative `nrExpiry` rejected; canonical encoding byte-stable.
+2. **MaxSizeSpec** — max `NameRecord` encodes ≤ ~9 KB; `encodeTransmission v ≤ paddedProxiedTLength - 2`; `cbEncrypt` succeeds.
+3. **CommandTagSpec** — `"RSLV"`/`"NAME"` parse; v < 20 sessions reject `RSLV_` at parameter parser.
+4. **ForwardedGateSpec** — direct RSLV → `CMD PROHIBITED`; forwarded RSLV reaches handler.
+5. **ForwardedRslvSpec** — RSLV wrapped in PFWD reaches the handler end-to-end. **Test infra cost**: first protocol-level PFWD test; budget for `runProxiedSmpCommand` helper performing `PRXY`/`PKEY`/`PFWD` manually.
+6. **CacheSpec** — hit avoids RPC; TTL expiry forces re-fetch; bytes cap evicts before entries cap on large records; concurrent same-key callers issue one RPC; leader exception → all waiters get `Left _`, TMap entry removed; leader async-cancel → cleanup STM still runs.
+7. **AbiSpec** — encode/decode against pinned fixtures (`tests/fixtures/snrc/`); QuickCheck fuzz on random buffers ≤ `rpcMaxResponseBytes` must never crash.
+8. **NamehashSpec** — Keccak-256 reference vectors; assert Keccak ≠ SHA3-256.
+9. **MockRpcSpec** — fake HTTP server; missing → `EthHttpErr`; slow → `TimedOut`; multi-GB body truncated → `EthDecodeErr`. `rpcAuth = AuthBasic` sends correct header.
+10. **Uint256OverflowSpec** — `expiry > Int64.maxBound` → `EthDecodeErr`.
+11. **ZeroOwnerSpec** — `owner = 0x000...000` → `NotFound`.
+12. **StartupGuardSpec** — `allowSMPProxy + names.enable` aborts; `allow_dangerous_colocation = on` starts with warning.
+13. **UrlValidationSpec** — userinfo/scheme/host/port edge cases; rejects `https://` without `rpc_auth` for non-loopback.
+14. **EipChecksumSpec** — `parseEthAddr` accepts lower/upper; verifies mixed-case checksum; rejects typos.
+15. **AbiBoundsSpec** — each of 8 ABI invariants triggers `EthDecodeErr` without crash/allocation blow-up.
+
+Integration against real Reth+Nimbus mainnet deferred to ops.
+
+## Threat model, scope, coordination
+
+| Actor | Can | Cannot |
+|---|---|---|
+| Name server | See lookup-key bytes; see query timing; see Eth endpoint URL (operator-self) | See client IP/session; correlate clients across queries |
+| Compromised Eth endpoint | Poison this server's cache for one TTL window; see every lookup key the server queries | Bypass two-server agreement (client-side, out of scope) |
+| Adversarial client (high-rate unique keys) | Cache-thrash DoS; fill `Manager` connection pool up to `managerConnCount = 8` | Bypass `rpcMaxResponseBytes` or `fetchOnceTimed` |
+| Adversarial proxy (slow inner RSLVs) | Block other forwarded commands on that proxy connection up to `rpcTimeoutMs` per miss | Affect other proxy connections |
+| Operator with footgun config (https no auth, public Eth RPC) | (rejected at startup, or operator-acknowledged data leak) | — |
+
+Mitigations: caching + coalescing + `rpcTimeoutMs` + `rpcMaxResponseBytes` + `rpcMaxConcurrency`; co-location refused at startup; URL validation; Caddy + auth in front of Reth; Reth's own gas/size caps. Timing side-channels (cache-hit vs miss latency) not mitigated — flagged for post-MVP. State proofs deferred to post-MVP per RFC.
+
+**Cross-repo coordination.** The `simplex-chat` `ep/namespace` branch currently contains only the RFC commit — no agent-side wire-format code yet. This plan's wire format is validated only by simplexmq's own tests until a matching agent PR lands (structurally weak — encoder/decoder bugs are mutually consistent with themselves). Coordinate with the agent-side implementer **before merging** on: exact `NameRecord` field order and types; `LookupKey` namespace-prefix convention; error-code semantics; Part 1 SNRC contract `getRecord` ABI surface.
@@ -1,8 +1,9 @@
-# SMP server message storage
+
+# SMP router message storage

 ## Problem

-Currently SMP servers store all queues in server memory. As the traffic grows, so does the number of undelivered messages. What is worse, Haskell is not avoiding heap fragmentation when messages are allocated and then de-allocated - undelivered messages use ByteString and GC cannot move them around, as they use pinned memory.
+Currently SMP routers store all queues in router memory. As the traffic grows, so does the number of undelivered messages. What is worse, Haskell is not avoiding heap fragmentation when messages are allocated and then de-allocated - undelivered messages use ByteString and GC cannot move them around, as they use pinned memory.

 ## Possible solutions

@@ -10,7 +11,7 @@ Currently SMP servers store all queues in server memory. As the traffic grows, s

 Move from ByteString to some other primitive to store messages in memory long term, e.g. ShortByteString, or manage allocation/de-allocation of stored messages manually in some other way.

-Pros: the simplest solution that avoids substantial re-engineering of the server.
+Pros: the simplest solution that avoids substantial re-engineering of the router.

 Cons:
 - not a long term solution, as memory growth still has limits.
@@ -22,12 +23,12 @@ Use files or RocksDB to store messages.

 Pros:
 - much lower memory usage.
- no message loss in case of abnormal server termination (important until clients have delivery redundancy).
+- no message loss in case of abnormal router termination (important until clients have delivery redundancy).
 - this is a long term solution, and at some point it might need to be done anyway.

 Cons:
 - substantial re-engineering costs and risks.
- metadata privacy. Currently we only save undelivered messages when server is restarted, with this approach all messages will be stored for some time. this argument is limited, as hosting providers of VMs can make memory snapshots too, on the other hand they are harder to analyze than files. On another hand, with this approach messages will be stored for a shorter time.
+- metadata privacy. Currently we only save undelivered messages when router is restarted, with this approach all messages will be stored for some time. this argument is limited, as hosting providers of VMs can make memory snapshots too, on the other hand they are harder to analyze than files. On another hand, with this approach messages will be stored for a shorter time.

 #### RocksDB and other key-value stores

@@ -67,7 +68,7 @@ queueLogLine =
    %s"write_msg=" digits
 ```

-When queue is first requested by the server:
+When queue is first requested by the router:

 ```c
 if queue folder exists:
@@ -87,7 +88,7 @@ nextReadMsg = read_msg
 open write_file in AppendMode
 ```

-When message is added to the queue (assumes that queue state is loaded to server memory, if not the previous section will be done first):
+When message is added to the queue (assumes that queue state is loaded to router memory, if not the previous section will be done first):

 ```c
 if write_msg > max_queue_messages:
@@ -128,7 +129,7 @@ else
    nextReadByte = current position in file
 ```

-When message delivery is acknowledged, the read queue needs to be advanced, and possibly switched to read from the current write_queue:
+When message delivery is acknowledged, the read queue needs to be advanced, and possibly switched to read from the current write queue:

 ```c
 if nextReadByte == read_byte:
@@ -162,9 +163,9 @@ Most Linux systems use EXT4 filesystem where the file lookup time scales linearl

 So storing all queue folders in one folder won't scale.

-To solve this problem we could use recipient queue ID in base64url format not as a folder name, but as a folder path, splitting it to path fragments of some length. The number of fragments can be configurable and migration to a different fragment size can be supported as the number of queues on a given server grows.
+To solve this problem we could use recipient queue ID in base64url format not as a folder name, but as a folder path, splitting it to path fragments of some length. The number of fragments can be configurable and migration to a different fragment size can be supported as the number of queues on a given router grows.

-Currently, queue ID is 24 bytes random number, thus allowing 2^192 possible queue IDs. If we assume that a server must hold 1b queues, it means that we have ~2^162 possible addresses for each existing queue. 24 bytes in base64 is 32 characters that can be split into say 8 fragments with 4 characters each, so that queue folder path for queue with ID `abcdefghijklmnopqrstuvwxyz012345` would be:
+Currently, queue ID is 24 bytes random number, thus allowing 2^192 possible queue IDs. If we assume that a router must hold 1b queues, it means that we have ~2^162 possible addresses for each existing queue. 24 bytes in base64 is 32 characters that can be split into say 8 fragments with 4 characters each, so that queue folder path for queue with ID `abcdefghijklmnopqrstuvwxyz012345` would be:

 `/var/opt/simplex/messages/abcd/efgh/ijkl/mnop/qrst/uvwx/yz01/2345`

@@ -174,6 +175,6 @@ So we could use an unequal split of path, two letters each and the last being lo

 `/var/opt/simplex/messages/ab/cd/ef/ghijklmnopqrstuvwxyz012345`

-The first three levels in this case can have 4096 subfolders each, and it gives 68b possible subfolders (64^2^3), so the last level will be sparse in case of 1b queues on the server. So we could make it 4 levels with 2 letters to never think about it, accounting for a large variance of the random numbers distribution:
+The first three levels in this case can have 4096 subfolders each, and it gives 68b possible subfolders (64^2^3), so the last level will be sparse in case of 1b queues on the router. So we could make it 4 levels with 2 letters to never think about it, accounting for a large variance of the random numbers distribution:

 `/var/opt/simplex/messages/ab/cd/ef/gh/ijklmnopqrstuvwxyz012345`
@@ -1,6 +1,7 @@
+
 # Sharing protocol ports with HTTPS

-Some networks block all ports other than web ports, including port 5223 used for SMP protocol by default. Running SMP servers on a common web port 443 would allow them to work on more networks. The servers would need to provide an HTTPS page for browsers (and probes).
+Some networks block all ports other than web ports, including port 5223 used for SMP protocol by default. Running SMP routers on a common web port 443 would allow them to work on more networks. The routers would need to provide an HTTPS page for browsers (and probes).

 ## Problem

@@ -8,7 +9,7 @@ Browsers and tools rely on system CA bundles instead of certificate pinning.
 The crypto parameters used by HTTPS are different from what the protocols use.
 Public certificate providers like LetsEncrypt can only sign specific types of keys and Ed25519 isn't one of them.

-This means a server should distinguish browser and protocol clients and adjust its behavior to match.
+This means a router should distinguish browser and protocol clients and adjust its behavior to match.

 ## Solution

@@ -16,15 +17,15 @@ This means a server should distinguish browser and protocol clients and adjust i

 Since LE certificates are only handed out to domain names, TLS client will be sending the SNI.
 However client transports are constructed over connected sockets and the SNI wouldn't be present unless explicitly requested.
-When a client sends SNI, then it's a browser and a web credentials should be used.
+When a client sends SNI, then it's a browser and web credentials should be used.
 Otherwise it's a protocol client to be offered the self-signed ca, cert and key.

 When a transport colocated with a HTTPS, its ALPN list should be extended with `h2 http/1.1`.
 The browsers will send it, and it should be checked before running transport client.
-If HTTP ALPN is detected, then the client connection is served with HTTP `Application` instead (the same "server information" page).
+If HTTP ALPN is detected, then the client connection is served with HTTP `Application` instead (the same "router information" page).

-If some client connects to server IP, doesn't send SNI and doesn't send ALPN, it will look like a pre-handshake client.
-In that case a server will send its handshake first.
+If some client connects to router IP, doesn't send SNI and doesn't send ALPN, it will look like a pre-handshake client.
+In that case a router will send its handshake first.
 This can be mitigated by delaying its handshake and letting the probe to issue its HTTP request.

 ## Implementation plan
@@ -43,7 +44,7 @@ runServer (tcpPort, ATransport t) = do
      else runClient serverSignKey t h `runReaderT` env -- performs serverHandshake etc as usual
 ```

-The web app and server live outside, so `runHttp` has to be provided by the `runSMPServer` caller.
+The web app and router live outside, so `runHttp` has to be provided by the `runSMPServer` caller.
 Additonally, Warp is using its `InternalInfo` object that's scoped to `withII` bracket.

 ```haskell
@@ -65,11 +66,9 @@ The implementation relies on a few modification to upstream code:
 - `warp`: Only the re-export of `serveConnection` is needed.
  Unfortunately the most recent `warp` version can't be used right away due to dependency cascade around `http-5` and `auto-update-2`.
  So a fork containing the backported re-export has to be used until the dependencies are refreshed.
-
-
 ### TLS.ServerParams

-When a server has port sharing enabled, a new set of TLS params is loaded and combined with transport params:
+When a router has port sharing enabled, a new set of TLS params is loaded and combined with transport params:

 ```haskell
 newEnv config = do
@@ -129,7 +128,7 @@ key: /etc/opt/simplex/web.key
 # key: /etc/letsencrypt/live/smp.hostname.tld/privkey.pem
 ```

-When `TRANSPORT.port` matches `WEB.https` the transport server becomes shared.
+When `TRANSPORT.port` matches `WEB.https` the transport router becomes shared.

 Perhaps a more desirable option would be explicit configuration resulting in additional transported to run:

@@ -148,16 +147,16 @@ key: /etc/opt/simplex/web.key

 ## Caveats

-Serving static files and the protocols togother may pose a problem for those who currently use dedicated web servers as they should switch to embedded http handlers.
+Serving static files and the protocols together may pose a problem for those who currently use dedicated web servers as they should switch to embedded http handlers.

 As before, using embedded HTTP server is increasing attack surface.

-Users who want to run everything on a single host will have to add and extra IP address and bind servers to specific IPs instead of 0.0.0.0.
-An amalgamated server binary can be provided that would contain both SMP and XFTP servers, where transport will dispatch connections by handshake ALPN.
+Users who want to run everything on a single host will have to add an extra IP address and bind routers to specific IPs instead of 0.0.0.0.
+An amalgamated router binary can be provided that would contain both SMP and XFTP routers, where transport will dispatch connections by handshake ALPN.

 ## Alternative: Use transports routable with reverse-proxies

 An "industrial" reverse proxy may do the ALPN routing, serving HTTP by itself and delegating `smp` and `xftp` to protocol servers.
 Same with the `websockets`.

-Since this in effect does TLS termination, the protocol servers will have to rely on credentials from protocol handshakes.
+Since this in effect does TLS termination, the protocol routers will have to rely on credentials from protocol handshakes.
@@ -1,8 +1,9 @@
+
 # Expiring messages in journal storage

 ## Problem

-The journal storage servers recently migrated to do not delete delivered or expired messages, they only update pointers to journal file lines. The messages are actually deleted when the whole journal file is deleted (when fully deleted or fully expired).
+The journal storage routers recently migrated to do not delete delivered or expired messages, they only update pointers to journal file lines. The messages are actually deleted when the whole journal file is deleted (when fully deleted or fully expired).

 The problem is that in case the queue stops receiving the new messages then writing of messages won't switch to the new journal file, and the current journal file containing delivered or expired messages would never be deleted.

@@ -0,0 +1,416 @@
+
+# Fix subQ deadlock: blocking writeTBQueue inside connLock
+
+## Problem
+
+Users report that message reception silently and permanently stops across all connections, with no error alerts. The app appears functional but no messages arrive. Recovery requires restart.
+
+Root cause: a deadlock between worker threads holding `connLock` and the `agentSubscriber` (sole `subQ` reader).
+
+### The deadlock mechanism
+
+`subQ` (`TBQueue ATransmission`, capacity 4096 on mobile / 1024 on desktop) is the single pipeline between the agent layer and the chat layer. The `agentSubscriber` thread (`Commands.hs:4373`) is its **sole reader**.
+
+Three code sites hold `connLock` and call blocking `writeTBQueue subQ` without a fullness check. When `subQ` is full, these block while holding the lock. If `agentSubscriber` simultaneously needs the same `connLock` (via `sendMessagesB_` → `withConnLocks`), it blocks too — creating a circular wait:
+
+- **Worker**: holds `connLock(X)`, waits for `subQ` space (needs `agentSubscriber` to read)
+- **agentSubscriber**: sole `subQ` reader, waits for `connLock(X)` (needs worker to release)
+- **Result**: permanent silent deadlock — no exception, no alert, all connections blocked
+
+### Confirmed deadlock scenarios
+
+**Scenario 1**: Delivery worker during queue rotation test
+
+```
+Delivery worker:                    agentSubscriber (sole subQ reader):
+  withConnLock(X) [2187]              readTBQueue subQ → processAgentMessageConn
+  ...DB operations...                 → sendPendingGroupMessages (on CON/SENT/QCONT)
+  notify → writeTBQueue subQ [2238]   → batchSendConnMessages → deliverMessagesB
+  [BLOCKED — subQ full]               → withAgent sendMessagesB [synchronous]
+                                      → sendMessagesB_ → withConnLocks({..X..}) [1708]
+                                      [BLOCKED — connLock(X) held]
+```
+
+**Scenario 2**: Async command worker during message ACK with notification
+
+```
+Async cmd worker:                   agentSubscriber (sole subQ reader):
+  tryWithLock "ICAck" [1930→1824]     readTBQueue subQ → processAgentMessageConn
+  → withConnLock(X)                   → sendPendingGroupMessages
+  → ack → ackQueueMessage [1899]      → sendMessagesB_ → withConnLocks({..X..})
+  → sendMsgNtf [2381]                [BLOCKED — connLock(X) held]
+  → writeTBQueue subQ [2386]
+  [BLOCKED — subQ full]
+```
+
+**Scenario 3**: Synchronous `ackMessage'` API (same mechanism as Scenario 2 but from external API caller)
+
+```
+ackMessage' caller:                 agentSubscriber (sole subQ reader):
+  withConnLock(X) [2254]              → sendMessagesB_ → withConnLocks({..X..})
+  → ack → ackQueueMessage [2267]      [BLOCKED — connLock(X) held]
+  → sendMsgNtf [2381]
+  → writeTBQueue subQ [2386]
+  [BLOCKED — subQ full]
+```
+
+### ConnId overlap verified
+
+No guard prevents a connection undergoing queue rotation (AM_QTEST_) or ACK processing from being included in `sendMessagesB_`'s batch. During these operations, the connection has `connStatus == ConnReady`, passing all filters in `memberSendAction`.
+
+### Cascade amplification
+
+Once any single deadlock triggers, `subQ` never drains. ALL other threads that attempt `writeTBQueue subQ` block progressively — their locks are held forever too. The entire threading system freezes within seconds.
+
+### Affected code sites (blocking `writeTBQueue subQ` inside `connLock`)
+
+| Site | File | Lock line | Write line | Events written |
+|------|------|-----------|------------|----------------|
+| `runSmpQueueMsgDelivery::notify` | Agent.hs | 2187 | 2238 | SWITCH SPCompleted, ERR INTERNAL |
+| `runSmpQueueMsgDelivery::internalErr/notifyDel` | Agent.hs | 2187 | 2238 (via notifyDel→notify) | ERR INTERNAL + delMsg |
+| `ackQueueMessage::sendMsgNtf` | Agent.hs | 2254 or 1930 | 2386 | MSGNTF |
+
+### Safe patterns that already exist in the codebase
+
+1. **`isFullTBQueue` + pending TVar** (used at `runCommandProcessing` lines 1782-1784/1937, and `runProcessSMP` lines 3027-3029/3216):
+   ```haskell
+   -- Before processing (e.g. line 1782):
+   pending <- newTVarIO []
+   -- During processing — safe notify (e.g. line 1937):
+   notify cmd =
+     let t = (corrId, connId, AEvt (sAEntity @e) cmd)
+      in atomically $ ifM (isFullTBQueue subQ) (modifyTVar' pendingCmds (t :)) (writeTBQueue subQ t)
+   -- After processing — flush (e.g. line 1784):
+   mapM_ (atomically . writeTBQueue subQ) . reverse =<< readTVarIO pending
+   ```
+
+2. **`nonBlockingWriteTBQueue`** (used at Client.hs:789, NtfSubSupervisor.hs:507):
+   ```haskell
+   nonBlockingWriteTBQueue q x = do
+     sent <- atomically $ tryWriteTBQueue q x
+     unless sent $ void $ forkIO $ atomically $ writeTBQueue q x
+   ```
+   Note: `nonBlockingWriteTBQueue` does NOT preserve ordering — the spawned background thread may complete out of order relative to subsequent direct writes from the same calling thread.
+
+### Exhaustive proof: no other deadlock scenarios exist
+
+All 15 `withConnLock` sites in Agent.hs were analyzed. Only 3 write to `subQ`:
+
+| withConnLock site | Writes subQ? | Safe? |
+|-------------------|-------------|-------|
+| switchConnectionAsync' (899) | No | ✓ |
+| setConnShortLinkAsync' (995) | No | ✓ |
+| setConnShortLink' (1031) | No | ✓ |
+| deleteConnShortLink' (1075) | No | ✓ |
+| allowConnection' (1407) | No | ✓ |
+| acceptContact' (1417) | No | ✓ |
+| sendMessagesB_ (1708, `withConnLocks`) | No | ✓ |
+| tryWithLock/runSmpCommand (1930) | Yes (1937) | ✓ — `isFullTBQueue` check |
+| tryMoveableWithLock/runSmpCommand (1931) | Yes (1937) | ✓ — `isFullTBQueue` check |
+| **runSmpQueueMsgDelivery AM_QTEST_ (2187)** | **Yes (2238)** | **✗ — DEADLOCK** |
+| **ackMessage' (2254)** | **Yes (2386)** | **✗ — DEADLOCK** |
+| switchConnection' (2298) | No | ✓ |
+| abortConnectionSwitch' (2328) | No | ✓ |
+| synchronizeRatchet' (2351) | No | ✓ |
+| suspendConnection' (2390) | No | ✓ |
+| **processSMP (3037)** | Yes (3216) | ✓ — `isFullTBQueue` check |
+
+Note: `processSMP` (line 3037) holds `connLock` and its local `notify` (line 3216) writes to `subQ`, but it uses the safe `isFullTBQueue` pattern. Its `ack` (line 3196) uses `enqueueCmd` (DB-only), NOT `ackQueueMessage`. The actual `ackQueueMessage` runs later from the async command worker via ICAck/ICAckDel.
+
+Other lock pairs checked — no circular dependencies:
+- `connLock × DB MVar`: DB never acquires connLock
+- `entityLock × connLock`: consistent ordering (entity first in chat, conn in agent)
+- `connLock(X) × connLock(Y)`: single agentSubscriber thread, one `withConnLocks` at a time
+
+---
+
+## Deadlock call graph: agentSubscriber → connLock
+
+All deadlock paths require `agentSubscriber` to synchronously acquire `connLock`. Exhaustive analysis shows that **every such path converges on a single agent function**: `sendMessagesB_` → `withConnLocks` (Agent.hs:1708). No other agent API function called synchronously from the agentSubscriber acquires connLock.
+
+Verified (FACT): `ackMessageAsync` → `enqueueCommand` only (no connLock). `toggleConnectionNtfs` → no lock. `deleteConnectionAsync` → `deleteLock` not `connLock`. `joinConnectionAsync` → `withInvLock` not `connLock`.
+
+Also verified (FACT): `Lock = TMVar Text` (Lock.hs:24) is **non-reentrant** — double acquisition on the same thread deadlocks.
+
+### All 22 trigger paths
+
+Every path goes through `deliverMessage`/`deliverMessages`/`deliverMessagesB` → `withAgent sendMessagesB` → `sendMessagesB_` → `withConnLocks`:
+
+| # | Trigger | Chat function | ConnIds locked | Risk |
+|---|---------|--------------|----------------|------|
+| 1 | Group CON (Invitee) | `introduceToAll` → broadcast XGrpMemNew | **ALL member connIds** | **HIGHEST** |
+| 2 | Group MSG XGrpLinkAcpt | `introduceToRemaining` → broadcast | **ALL member connIds** | **HIGHEST** |
+| 3 | Group CON (Invitee) | `sendIntroductions` → batch intros to new member | new member connId | Medium |
+| 4 | Group CON (Invitee) | `sendHistory` → batch to new member | new member connId | Medium |
+| 5 | Group CON | `sendPendingGroupMessages` | member connId | Medium |
+| 6 | Group SENT | `sendPendingGroupMessages` | member connId | Medium |
+| 7 | Group QCONT | `sendPendingGroupMessages` | member connId | Medium |
+| 8 | Group CON (PendingReview) | `introduceToModerators` → to moderators | moderator connIds | Medium |
+| 9 | Group CON (PreMember) | `sendXGrpMemCon` → to host | host connId | Low |
+| 10 | Group CON (PreMember) | `probeMatchingMemberContact` → probes + hashes | member + N matching connIds | Medium |
+| 11 | Direct CON | `probeMatchingMembers` → probes + hashes | contact + N matching connIds | Medium |
+| 12 | Direct JOINED | `sendAutoReply` | contact connId | Low |
+| 13 | Group JOINED | `sendGroupAutoReply` | member connId | Low |
+| 14 | Group INV | `sendXGrpMemInv` → to host | host connId | Low |
+| 15 | Group INV (legacy) | `sendGrpInvitation` → to contact | contact connId | Low |
+| 16 | Group MSG XGrpMemInv | `xGrpMemInv` → `sendGroupMemberMessage` | re-member connId | Low |
+| 17 | Group MSG XGrpMemDel | `forwardToMember` | deleted member connId | Low |
+| 18 | Group MSG XGrpLinkMem | `probeMatchingMemberContact` | member + N matching connIds | Medium |
+| 19 | Group MSG (dup relay) | `saveGroupRcvMsg` error → `sendDirectMemberMessage` | forwarder connId | Low |
+| 20 | SFDONE | `sendFileDescriptions` → to recipients | recipient connIds | Medium |
+| 21 | Group MSG XGrpLinkAcpt | `sendHistory` → to accepted member | accepted member connId | Medium |
+| 22 | Direct MSG (autoAccept) | `autoAcceptFile` → inline accept reply | contact connId | Low (test-only config) |
+
+### Key observations
+
+1. **Single bottleneck**: All 22 paths converge on `sendMessagesB_` → `withConnLocks` (Agent.hs:1708). The deadlock is between this lock acquisition and any worker thread holding `connLock` + blocking on `writeTBQueue subQ`.
+
+2. **Highest-risk paths** (#1, #2): Broadcasting to ALL group members in `introduceToAll` / `introduceToRemaining` acquires `withConnLocks` on ALL member connIds in a single batch. For large groups, this holds the agentSubscriber thread for a long time, during which subQ fills, which causes worker threads holding connLock on any of those connIds to deadlock.
+
+3. **Medium-risk paths** (#5-7): `sendPendingGroupMessages` fires on every CON/SENT/QCONT. These are frequent and lock the member's connId, which is the SAME connId that a delivery worker or ACK worker may hold while writing to subQ.
+
+---
+
+## Analysis: `withConnLocks` in `sendMessagesB_`
+
+### FACT: the lock protects ratchet encryption state
+
+`sendMessagesB_` (Agent.hs:1708-1713) acquires `withConnLocks` and executes:
+
+1. **`getConn_`** — reads connection metadata, send queues from DB
+2. **`setConnPQSupport`** — updates PQ encryption flag per connection
+3. **`enqueueMessagesB`** → `enqueueMessageB` → `storeSentMsg_` which calls:
+   - **`updateSndIds`** (AgentStore.hs:899) — increments `internalSndId` (sequential send counter)
+   - **`agentRatchetEncryptHeader`** (Agent.hs:3698) — reads current ratchet via `getRatchetForUpdate`, encrypts message header via `rcEncryptHeader`, writes advanced ratchet state via `updateRatchet`
+   - **`createSndMsg`** + **`createSndMsgDelivery`** — inserts message and delivery records
+
+All operations run within `unsafeWithStore` → `withTransaction` (single DB transaction per batch).
+
+### FACT: the lock CANNOT be removed
+
+Without `withConnLocks`, concurrent `sendMessagesB_` calls targeting the same connection would:
+- Read the same ratchet state, both encrypt, one overwrite the other → **ratchet desync** (unrecoverable)
+- Get duplicate `internalSndId` values → **message ID collision**
+- Race on `setConnPQSupport` → **PQ state inconsistency**
+
+The lock serializes ALL operations on the connection's encryption state. Removing it would introduce data corruption.
+
+Note: `sendMessage` (singular, line 530) uses the same `sendMessagesB_` function — there is no lock-free send path.
+
+### Eliminated strategies
+
+- **Strategy C (remove lock)**: The lock protects ratchet encryption. Removing it causes unrecoverable ratchet desync. Eliminated.
+- **Strategy A (async dispatch)**: All 22 chat-layer callers use `deliverMessagesB` return values (delivery IDs, PQ state) synchronously. `forkIO` loses results. Eliminated.
+- **Strategy W (isFullTBQueue + pending TVar)**: The existing pattern (lines 1937, 3216) buffers events in a local TVar and flushes after lock release. Between lock release and flush, another thread can acquire the same connLock and write events to subQ — reordering events within the same connection. This trades a visible deadlock for invisible ordering bugs. Eliminated.
+- **Strategy O (per-connection overflow queues)**: Bounded overflow queues with "drop when full" were analyzed. Drop consequences are unacceptable at 5 of 6 write sites — CONF, INFO, CON cause permanent connection failure after ACK; INV loses connection invitations; SENT/MERR leave messages stuck forever. Unbounded overflow defeats backpressure. Eliminated.
+
+---
+
+## Solution: move subQ writes outside connLock
+
+### Root cause
+
+The `writeTBQueue subQ` calls at the 3 deadlock sites are inside `connLock` by accident of code structure, not necessity. `connLock` protects ratchet encryption state and DB consistency. The `notify` calls write informational events to `subQ` — they do not modify any state that `connLock` protects.
+
+Moving the writes outside the lock scope eliminates the deadlock: blocking `writeTBQueue subQ` without holding `connLock` is safe — agentSubscriber is free to acquire the lock, process events, and drain `subQ`.
+
+### Why reordering doesn't matter at these sites
+
+The chat layer handlers for the 3 deadlock site events do NOT advance the ratchet:
+
+| Event | Chat handler | Calls sendMessagesB_? |
+|-------|-------------|----------------------|
+| SWITCH SPCompleted | Creates internal chat item, updates UI | **No** |
+| ERR INTERNAL | Logs error to view | **No** |
+| MSGNTF | `toView CEvtNtfMessage` → empty output | **No** |
+
+Events that DO trigger ratchet advances (CON, SENT, QCONT → `sendPendingGroupMessages` → `sendMessagesB_`) are all already written OUTSIDE `connLock` in the current code.
+
+Ratchet state lives in the DB, not in subQ events. agentSubscriber processes events sequentially regardless of arrival order. The SENT-before-SWITCH race already exists in the current code (new queue worker writes SENT outside connLock while old queue worker writes SWITCH inside connLock).
+
+### Fix: Site 1 — `runSmpQueueMsgDelivery` AM_QTEST_ (line 2187)
+
+Restructure `withConnLock` to return the event, write outside.
+
+**Current code** (Agent.hs:2187-2214):
+```haskell
+AM_QTEST_ -> withConnLock c connId "runSmpQueueMsgDelivery AM_QTEST_" $ do
+  withStore' c $ \db -> setSndQueueStatus db sq Active
+  SomeConn _ conn <- withStore c (`getConn` connId)
+  case conn of
+    DuplexConnection cData' rqs sqs -> do
+      let addr = qAddress sq
+      case findQ addr sqs of
+        Just SndQueue {dbReplaceQueueId = Just replacedId, primary} ->
+          case removeQP (\sq' -> dbQId sq' == replacedId && not (sameQueue addr sq')) sqs of
+            Nothing -> internalErr msgId "sent QTEST: queue not found in connection"
+            Just (sq', sq'' : sqs') -> do
+              checkSQSwchStatus sq' SSSendingQTEST
+              atomically $ TM.delete (qAddress sq') $ smpDeliveryWorkers c
+              withStore' c $ \db -> do
+                when primary $ setSndQueuePrimary db connId sq
+                deletePendingMsgs db connId sq'
+                deleteConnSndQueue db connId sq'
+              let sqs'' = sq'' :| sqs'
+                  conn' = DuplexConnection cData' rqs sqs''
+              cStats <- connectionStats c conn'
+              notify $ SWITCH QDSnd SPCompleted cStats       -- DEADLOCK
+            _ -> internalErr msgId "sent QTEST: ..."         -- DEADLOCK (via notifyDel → notify)
+        _ -> internalErr msgId "sent QTEST: ..."             -- DEADLOCK
+    _ -> internalErr msgId "QTEST sent not in duplex ..."    -- DEADLOCK
+```
+
+**New code:**
+```haskell
+AM_QTEST_ -> do
+  evt_ <- withConnLock c connId "runSmpQueueMsgDelivery AM_QTEST_" $ do
+    withStore' c $ \db -> setSndQueueStatus db sq Active
+    SomeConn _ conn <- withStore c (`getConn` connId)
+    case conn of
+      DuplexConnection cData' rqs sqs -> do
+        let addr = qAddress sq
+        case findQ addr sqs of
+          Just SndQueue {dbReplaceQueueId = Just replacedId, primary} ->
+            case removeQP (\sq' -> dbQId sq' == replacedId && not (sameQueue addr sq')) sqs of
+              Nothing -> pure $ Left "sent QTEST: queue not found in connection"
+              Just (sq', sq'' : sqs') -> do
+                checkSQSwchStatus sq' SSSendingQTEST
+                atomically $ TM.delete (qAddress sq') $ smpDeliveryWorkers c
+                withStore' c $ \db -> do
+                  when primary $ setSndQueuePrimary db connId sq
+                  deletePendingMsgs db connId sq'
+                  deleteConnSndQueue db connId sq'
+                let sqs'' = sq'' :| sqs'
+                    conn' = DuplexConnection cData' rqs sqs''
+                cStats <- connectionStats c conn'
+                pure $ Right $ SWITCH QDSnd SPCompleted cStats
+              _ -> pure $ Left "sent QTEST: there is only one queue in connection"
+          _ -> pure $ Left "sent QTEST: queue not in connection or not replacing another queue"
+      _ -> pure $ Left "QTEST sent not in duplex connection"
+  -- subQ write is now OUTSIDE connLock — blocking writeTBQueue is safe
+  case evt_ of
+    Right evt -> notify evt
+    Left err -> internalErr msgId err
+```
+
+All DB operations remain inside the lock. Only `notify`/`internalErr` (which write to subQ) move outside. `internalErr` calls `notifyDel` = `notify >> delMsg` — both `notify` (subQ write) and `delMsg` (`deleteSndMsgDelivery`, keyed on unique msgId) are safe outside the lock. The existing double-delete pattern (`delMsg` inside `internalErr` + `delMsgKeep` at line 2216) is preserved.
+
+### Fix: Sites 2 & 3 — `ackQueueMessage::sendMsgNtf` (line 2386)
+
+Change `ackQueueMessage` to return the MSGNTF event instead of writing it to subQ. Callers write to subQ after releasing connLock.
+
+**Current code** (Agent.hs:2371-2386):
+```haskell
+ackQueueMessage :: AgentClient -> RcvQueue -> SMP.MsgId -> AM ()
+ackQueueMessage c rq@RcvQueue {userId, connId, server} srvMsgId = do
+  atomically $ incSMPServerStat c userId server ackAttempts
+  tryAllErrors (sendAck c rq srvMsgId) >>= \case
+    Right _ -> sendMsgNtf ackMsgs
+    Left (SMP _ SMP.NO_MSG) -> sendMsgNtf ackNoMsgErrs
+    Left e -> ...
+  where
+    sendMsgNtf stat = do
+      atomically $ incSMPServerStat c userId server stat
+      whenM (liftIO $ hasGetLock c rq) $ do
+        atomically $ releaseGetLock c rq
+        brokerTs_ <- eitherToMaybe <$> tryAllErrors (withStore c $ \db -> getRcvMsgBrokerTs db connId srvMsgId)
+        atomically $ writeTBQueue (subQ c) ("", connId, AEvt SAEConn $ MSGNTF srvMsgId brokerTs_)
+```
+
+**New code** — return `Maybe ATransmission` instead of writing:
+```haskell
+ackQueueMessage :: AgentClient -> RcvQueue -> SMP.MsgId -> AM (Maybe ATransmission)
+ackQueueMessage c rq@RcvQueue {userId, connId, server} srvMsgId = do
+  atomically $ incSMPServerStat c userId server ackAttempts
+  tryAllErrors (sendAck c rq srvMsgId) >>= \case
+    Right _ -> sendMsgNtf ackMsgs
+    Left (SMP _ SMP.NO_MSG) -> sendMsgNtf ackNoMsgErrs
+    Left e -> ... >> pure Nothing
+  where
+    sendMsgNtf stat = do
+      atomically $ incSMPServerStat c userId server stat
+      ifM (liftIO $ hasGetLock c rq)
+        (do atomically $ releaseGetLock c rq
+            brokerTs_ <- eitherToMaybe <$> tryAllErrors (withStore c $ \db -> getRcvMsgBrokerTs db connId srvMsgId)
+            pure $ Just ("", connId, AEvt SAEConn $ MSGNTF srvMsgId brokerTs_))
+        (pure Nothing)
+```
+
+**Caller 1: `ackMessage'`** (Agent.hs:2253-2267) — return event from `withConnLock`, write after:
+```haskell
+ackMessage' c connId msgId rcptInfo_ = do
+  t_ <- withConnLock c connId "ackMessage" $ do
+    SomeConn _ conn <- withStore c (`getConn` connId)
+    case conn of
+      DuplexConnection {} -> do
+        t_ <- ack
+        sendRcpt conn
+        del
+        pure t_
+      RcvConnection {} -> do
+        t_ <- ack
+        del
+        pure t_
+      SndConnection {} -> throwE $ CONN SIMPLEX "ackMessage"
+      ContactConnection {} -> throwE $ CMD PROHIBITED "ackMessage: ContactConnection"
+      NewConnection _ -> throwE $ CMD PROHIBITED "ackMessage: NewConnection"
+  -- subQ write is OUTSIDE connLock
+  case t_ of
+    Just t -> atomically $ writeTBQueue (subQ c) t
+    Nothing -> pure ()
+```
+
+**Caller 2: `ICAck` / `ICAckDel`** (Agent.hs:1823-1824) — inline `tryWithLock` as `tryCommand` + `withConnLock`, write subQ between the two scopes:
+
+`tryWithLock name = tryCommand . withConnLock c connId name` — by inlining, the subQ write can be placed outside `withConnLock` but inside `tryCommand` (retaining retry/error handling).
+
+```haskell
+ICAck rId srvMsgId -> withServer $ \srv ->
+  tryCommand $ do
+    t_ <- withConnLock c connId "ICAck" $ ack srv rId srvMsgId
+    -- subQ write is OUTSIDE connLock — cannot deadlock with agentSubscriber
+    forM_ t_ $ atomically . writeTBQueue subQ
+
+ICAckDel rId srvMsgId msgId -> withServer $ \srv ->
+  tryCommand $ do
+    t_ <- withConnLock c connId "ICAckDel" $ do
+      t_ <- ack srv rId srvMsgId
+      withStore' c (\db -> deleteMsg db connId msgId)
+      pure t_
+    -- subQ write is OUTSIDE connLock — cannot deadlock with agentSubscriber
+    forM_ t_ $ atomically . writeTBQueue subQ
+```
+
+Where `ack` now returns `AM (Maybe ATransmission)`:
+```haskell
+ack srv rId srvMsgId = do
+  rq <- withStore c $ \db -> getRcvQueue db connId srv rId
+  ackQueueMessage c rq srvMsgId
+```
+
+All subQ writes for MSGNTF are now outside connLock. FIFO ordering is preserved — no `nonBlockingWriteTBQueue`, no forked threads. The same thread that held the lock writes to subQ sequentially after releasing it.
+
+### Race analysis
+
+Window between connLock release and subQ write at Site 1:
+
+| Thread | Can acquire connLock(X)? | Writes subQ? | Consequence |
+|--------|-------------------------|-------------|-------------|
+| agentSubscriber via sendMessagesB_ | Yes | **No** (encrypts only) | No race |
+| processSMP for connId X | Yes | Yes (pending flush) | MSG before SWITCH — cosmetic |
+| runCommandProcessing for connId X | Yes | Yes (pending flush) | Command response before SWITCH — cosmetic |
+| New queue delivery worker | No (SENT outside lock) | Yes | SENT before SWITCH — cosmetic, **already exists in current code** |
+
+All races are cosmetic UI ordering. None affect ratchet state, protocol correctness, or message delivery.
+
+### Summary of changes
+
+| File | Change | Lines affected |
+|------|--------|---------------|
+| Agent.hs | Restructure AM_QTEST_ to return event from `withConnLock`, write outside | ~2187-2214 |
+| Agent.hs | Change `ackQueueMessage` return type to `AM (Maybe ATransmission)`, return event instead of writing | ~2371-2386 |
+| Agent.hs | `ackMessage'`: return event from `withConnLock`, write outside | ~2253-2267 |
+| Agent.hs | `ICAck`/`ICAckDel`: inline `tryCommand` + `withConnLock`, write subQ between scopes | ~1823-1824 |
+| Agent.hs | `ack` helper: propagate new return type | ~1899-1901 |
+
+No new data structures. No new modules. No changes to other write sites (1937, 3216 — already safe). ~25 lines changed total.
@@ -1,4 +1,4 @@
-Version 5, 2024-06-22
+Version 7, 2025-01-24

 # SMP agent protocol - duplex communication over SMP protocol

@@ -6,9 +6,10 @@ Version 5, 2024-06-22

 - [Abstract](#abstract)
 - [SMP agent](#smp-agent)
- [SMP servers management](#smp-servers-management)
+- [SMP routers management](#smp-routers-management)
 - [SMP agent protocol scope](#smp-agent-protocol-scope)
 - [Duplex connection procedure](#duplex-connection-procedure)
+- [Fast duplex connection procedure](#fast-duplex-connection-procedure)
 - [Contact addresses](#contact-addresses)
 - [Communication between SMP agents](#communication-between-smp-agents)
  - [Message syntax](#messages-between-smp-agents)
@@ -20,41 +21,58 @@ Version 5, 2024-06-22
    - [Rotating messaging queue](#rotating-messaging-queue)
 - [End-to-end encryption](#end-to-end-encryption)
 - [Connection link: 1-time invitation and contact address](#connection-link-1-time-invitation-and-contact-address)
- [Appendix A: SMP agent API](#smp-agent-api)
+  - [Full connection link syntax](#full-connection-link-syntax)
+  - [Short connection link syntax](#short-connection-link-syntax)
+- [Short links](#short-links)
+  - [Link key derivation](#link-key-derivation)
+  - [Link data encryption](#link-data-encryption)
+  - [Short link resolution](#short-link-resolution)
+  - [Link data management](#link-data-management)
+- [Appendix A: SMP agent API](#appendix-a-smp-agent-api)
  - [API functions](#api-functions)
  - [API events](#api-events)

 ## Abstract

-The purpose of SMP agent protocol is to define the syntax and the semantics of communications between the client and the agent that connects to [SMP](./simplex-messaging.md) servers.
+The purpose of SMP agent protocol is to define the syntax and the semantics of communications between the client and the agent that connects to [SMP](./simplex-messaging.md) routers.

 It provides:
- API to create and manage bi-directional (duplex) connections between the users of SMP agents consisting of two (or more) separate unidirectional (simplex) SMP queues, abstracting away multiple steps required to establish bi-directional connections and any information about the servers location from the users of the agent protocol.
+- API to create and manage bi-directional (duplex) connections between the users of SMP agents consisting of two (or more) separate unidirectional (simplex) SMP queues, abstracting away multiple steps required to establish bi-directional connections and any information about the routers location from the users of the agent protocol.
 - management of E2E encryption between SMP agents, generating ephemeral asymmetric keys for each connection.
- SMP command authentication on SMP servers, generating ephemeral keys for each SMP queue.
- TCP/TLS transport handshake with SMP servers.
+- SMP command authentication on SMP routers, generating ephemeral keys for each SMP queue.
+- TCP/TLS transport handshake with SMP routers.
 - validation of message integrity.

 SMP agent API provides no security between the agent and the client - it is assumed that the agent is executed in the trusted and secure environment, via the agent library, when the agent logic is included directly into the client application - [SimpleX Chat for terminal](https://github.com/simplex-chat/simplex-chat) uses this approach.

+This document describes SMP agent protocol version 7. The version history:
+
+- v1: initial version
+- v2: duplex handshake - allows including reply queue(s) in the initial confirmation
+- v3: ratchet sync - supports re-negotiating double ratchet encryption
+- v4: delivery receipts - supports acknowledging message delivery to the sender
+- v5: post-quantum - supports post-quantum key exchange in double ratchet (PQDR)
+- v6: sender auth key - supports sender authentication key in confirmations
+- v7: ratchet on confirmation - initializes double ratchet during confirmation
+
 ## SMP agent

-SMP agents communicate with each other via SMP servers using [simplex messaging protocol (SMP)](./simplex-messaging.md) according to the API calls used by the client applications. This protocol is a middle layer in SimpleX protocols (above SMP protocol but below any application level protocol) - it is intended to be used by client-side applications that need secure asynchronous bi-directional communication channels ("connections").
+SMP agents communicate with each other via SMP routers using [simplex messaging protocol (SMP)](./simplex-messaging.md) according to the API calls used by the client applications. This protocol is a middle layer in SimpleX protocols (above SMP protocol but below any application level protocol) - it is intended to be used by client-side applications that need secure asynchronous bi-directional communication channels ("connections").

 The agent must have a persistent storage to manage the states of known connections and of the client-side information of SMP queues that each connection consists of, and also the buffer of the most recent sent and received messages. The number of the messages that should be stored is implementation specific, depending on the error management approach that the agent implements; at the very least the agent must store the hashes and IDs of the last received and sent messages.

-## SMP servers management
+## SMP routers management

-SMP agent API does not use the addresses of the SMP servers that the agent will use to create and use the connections (excluding the server address in queue URIs used in JOIN command). The list of the servers is a part of the agent configuration and can be dynamically changed by the agent implementation:
+SMP agent API does not use the addresses of the SMP routers that the agent will use to create and use the connections (excluding the router address in queue URIs used in JOIN command). The list of the routers is a part of the agent configuration and can be dynamically changed by the agent implementation:
 - by the client applications via any API that is outside of scope of this protocol.
- by the agents themselves based on availability and latency of the configured servers.
+- by the agents themselves based on availability and latency of the configured routers.

 ## SMP agent protocol scope

 SMP agent protocol has 2 main parts:

 - the messages that SMP agents exchange with each other in order to:
-  - negotiate establishing unidirectional (simplex) encrypted queues on SMP servers.
+  - negotiate establishing unidirectional (simplex) encrypted queues on SMP routers.
  - exchange client messages and delivery notifications, providing sequential message IDs and message integrity (by including the hash of the previous message).
  - re-negotiate messaging queues to use and connection e2e encryption.
 - the messages that the clients of SMP agents should send out-of-band (as pre-shared "invitation" including queue URIs) to protect [E2E encryption][1] from active attacks ([MITM attacks][2]).
@@ -67,40 +85,40 @@ SMP agent protocol has 2 main parts:

 ![Duplex connection procedure](./diagrams/duplex-messaging/duplex-creating.svg)

-The procedure of establishing a duplex connection is explained on the example of Alice and Bob creating a bi-directional connection consisting of two unidirectional (simplex) queues, using SMP agents (A and B) to facilitate it, and two different SMP servers (which could be the same server). It is shown on the diagram above and has these steps:
+The procedure of establishing a duplex connection is explained on the example of Alice and Bob creating a bi-directional connection consisting of two unidirectional (simplex) queues, using SMP agents (A and B) to facilitate it, and two different SMP routers (which could be the same router). It is shown on the diagram above and has these steps:

 1. Alice requests the new connection from the SMP agent A using agent `createConnection` api function.
-2. Agent A creates an SMP queue on the server (using [SMP protocol](./simplex-messaging.md) `NEW` command) and responds to Alice with the invitation that contains queue information and the encryption keys Bob's agent B should use. The invitation format is described in [Connection link](connection-link-1-time-invitation-and-contact-address).
+2. Agent A creates an SMP queue on the router (using [SMP protocol](./simplex-messaging.md) `NEW` command) and responds to Alice with the invitation that contains queue information and the encryption keys Bob's agent B should use. The invitation format is described in [Connection link](connection-link-1-time-invitation-and-contact-address).
 3. Alice sends the [connection link](#connection-link-1-time-invitation-and-contact-address) to Bob via any secure channel (out-of-band message) - as a link or as a QR code.
 4. Bob uses agent `joinConnection` api function with the connection link as a parameter to agent B to accept the connection.
-5. Agent B creates Bob's SMP reply queue with SMP server `NEW` command.
-6. Agent B confirms the connection: sends an "SMP confirmation" with SMP server `SEND` command to the SMP queue specified in the connection link - SMP confirmation is an unauthenticated message with an ephemeral key that will be used to authenticate Bob's commands to the queue, as described in SMP protocol, and Bob's info (profile, public key for E2E encryption, and the connection link to this 2nd queue to Agent A - this connection link SHOULD use "simplex" URI scheme). This message is encrypted using key passed in the connection link (or with the derived shared secret, in which case public key for key derivation should be sent in clear text).
-6. Alice confirms and continues the connection:
-  - Agent A receives the SMP confirmation containing Bob's key, reply queue and info as SMP server `MSG`.
+5. Agent B creates Bob's SMP reply queue with SMP router `NEW` command.
+6. Agent B confirms the connection: sends an "SMP confirmation" with SMP router `SEND` command to the SMP queue specified in the connection link - SMP confirmation is an unauthenticated message with an ephemeral key that will be used to authenticate Bob's commands to the queue, as described in SMP protocol, and Bob's info (profile, public key for E2E encryption, and the connection link to this 2nd queue to Agent A - this connection link SHOULD use "simplex" URI scheme). This message is encrypted using key passed in the connection link (or with the derived shared secret, in which case public key for key derivation should be sent in clear text).
+7. Alice confirms and continues the connection:
+  - Agent A receives the SMP confirmation containing Bob's key, reply queue and info as SMP router `MSG`.
  - Agent A notifies Alice sending `CONF` notification with Bob's info.
  - Alice allows connection to continue with agent `allowConnection` api function.
-  - Agent A secures the queue with SMP server `KEY` command.
+  - Agent A secures the queue with SMP router `KEY` command.
  - Agent A sends SMP confirmation with ephemeral sender key, ephemeral public encryption key and profile (but without reply queue).
-7. Agent B confirms the connection:
+8. Agent B confirms the connection:
  - receives the confirmation.
  - sends the notification `INFO` with Alice's information to Bob.
  - secures SMP queue that it sent to Alice in the first confirmation with SMP `KEY` command .
  - sends `HELLO` message via SMP `SEND` command. This confirms that the reply queue is secured and also validates that Agent A secured the first SMP queue
-8. Agent A notifies Alice.
+9. Agent A notifies Alice.
  - receives `HELLO` message from Agent B.
  - sends `HELLO` message to Agent B via SMP `SEND` command.
  - sends `CON` notification to Alice, confirming that the connection is established.
-9. Agent B notifies Bob.
+10. Agent B notifies Bob.
  - Once Agent B receives `HELLO` from Agent A, it sends to Bob `CON` notification as well.

 At this point the duplex connection between Alice and Bob is established, they can use `SEND` command to send messages. The diagram also shows how the connection status changes for both parties, where the first part is the status of the SMP queue to receive messages, and the second part - the status of the queue to send messages.

-The most communication happens between the agents and servers, from the point of view of Alice and Bob there are 4 steps (not including notifications):
+The most communication happens between the agents and routers, from the point of view of Alice and Bob there are 4 steps (not including notifications):

 1. Alice requests a new connection with `createConnection` agent API function and receives the connection link.
 2. Alice passes connection link out-of-band to Bob.
 3. Bob accepts the connection with `joinConnection` agent API function with the connection link to his agent.
-4. Alice accepts the connection with `ACPT` agent API function.
+4. Alice accepts the connection with `allowConnection` agent API function.
 5. Both parties receive `CON` notification once duplex connection is established.

 Clients SHOULD support establishing duplex connection asynchronously (when parties are intermittently offline) by persisting intermediate states and resuming SMP queue subscriptions.
@@ -118,14 +136,14 @@ Faster duplex connection process is possible with the `SKEY` command added in v9
 ![Fast duplex connection procedure](./diagrams/duplex-messaging/duplex-creating-fast.svg)

 1. Alice requests the new connection from the SMP agent A using agent `createConnection` api function
-2. Agent A creates an SMP queue on the server (using [SMP protocol](./simplex-messaging.md) `NEW` command with the flag allowing the sender to secure the queue) and responds to Alice with the invitation that contains queue information and the encryption keys Bob's agent B should use. The invitation format is described in [Connection link](connection-link-1-time-invitation-and-contact-address).
+2. Agent A creates an SMP queue on the router (using [SMP protocol](./simplex-messaging.md) `NEW` command with the flag allowing the sender to secure the queue) and responds to Alice with the invitation that contains queue information and the encryption keys Bob's agent B should use. The invitation format is described in [Connection link](connection-link-1-time-invitation-and-contact-address).
 3. Alice sends the [connection link](connection-link-1-time-invitation-and-contact-address) to Bob via any secure channel (out-of-band message) - as a link or as a QR code. This link contains the flag that the queue can be secured by the sender.
 4. Bob uses agent `joinConnection` api function with the connection link as a parameter to agent B to accept the connection.
 5. Agent B secures Alice's queue with SMP command `SKEY` - this command can be proxied.
-6. Agent B creates Bob's SMP reply queue with SMP server `NEW` command (with the flag allowing the sender to secure the queue).
-7. Agent B confirms the connection: sends an "SMP confirmation" with SMP server `SEND` command to the SMP queue specified in the connection link - SMP confirmation is an unauthenticated message with an ephemeral key that will be used to authenticate Bob's commands to the queue, as described in SMP protocol, and Bob's info (profile, public key for E2E encryption, and the connection link to this 2nd queue to Agent A - this connection link SHOULD use "simplex" URI scheme). This message is encrypted using key passed in the connection link (or with the derived shared secret, in which case public key for key derivation should be sent in clear text).
+6. Agent B creates Bob's SMP reply queue with SMP router `NEW` command (with the flag allowing the sender to secure the queue).
+7. Agent B confirms the connection: sends an "SMP confirmation" with SMP router `SEND` command to the SMP queue specified in the connection link - SMP confirmation is an unauthenticated message with an ephemeral key that will be used to authenticate Bob's commands to the queue, as described in SMP protocol, and Bob's info (profile, public key for E2E encryption, and the connection link to this 2nd queue to Agent A - this connection link SHOULD use "simplex" URI scheme). This message is encrypted using key passed in the connection link (or with the derived shared secret, in which case public key for key derivation should be sent in clear text).
 8. Alice confirms the connection:
-  - Agent A receives the SMP confirmation containing Bob's key, reply queue and info as SMP server `MSG`.
+  - Agent A receives the SMP confirmation containing Bob's key, reply queue and info as SMP router `MSG`.
  - Agent A notifies Alice sending `CONF` notification with Bob's info (that indicates that Agent B already secured the queue).
  - Alice allows connection to continue with agent `allowConnection` api function.
  - Agent A secures Bob's queue with SMP command `SKEY`.
@@ -140,11 +158,11 @@ Faster duplex connection process is possible with the `SKEY` command added in v9

 SMP agents support creating a special type of connection - a contact address - that allows to connect to multiple network users who can send connection requests by sending 1-time connection links to the message queue. 

-This connection address uses a messaging queue on SMP server to receive invitations to connect - see `agentInvitation` message below. Once connection request is accepted, a new connection is created and the address itself is no longer used to send the messages - deleting this address does not disrupt the connections that were created via it.
+This connection address uses a messaging queue on SMP router to receive invitations to connect - see `agentInvitation` message below. Once connection request is accepted, a new connection is created and the address itself is no longer used to send the messages - deleting this address does not disrupt the connections that were created via it.

 ## Communication between SMP agents

-To establish duplex connections and to send messages on behalf of their clients, SMP agents communicate via SMP servers.
+To establish duplex connections and to send messages on behalf of their clients, SMP agents communicate via SMP routers.

 Agents use SMP message client body (the part of the SMP message after header - see [SMP protocol](./simplex-messaging.md)) to transmit agent client messages and exchange messages between each other.

@@ -152,13 +170,13 @@ These messages are encrypted with per-queue shared secret using NaCL crypto_box
 - `agentConfirmation` - used when confirming SMP queues, contains connection information encrypted with double ratchet. This envelope can only contain `agentConnInfo` or `agentConnInfoReply` encrypted with double ratchet.
 - `agentMsgEnvelope` - contains different agent messages encrypted with double ratchet, as defined in `agentMessage`.
 - `agentInvitation` - sent to SMP queue that is used as contact address, does not use double ratchet.
- `agentRatchetKey` - used to re-negotiate double ratchet encryption - can contain additional information in `agentRatchetKey`.
+- `agentRatchetKey` - used to re-negotiate double ratchet encryption - can contain additional information in `agentRatchetInfo`.

 ```abnf
 decryptedSMPClientMessage = agentConfirmation / agentMsgEnvelope / agentInvitation / agentRatchetKey
 agentConfirmation = agentVersion %s"C" ("0" / "1" sndE2EEncryptionParams) encConnInfo
 agentVersion = 2*2 OCTET
-sndE2EEncryptionParams = TODO
+sndE2EEncryptionParams = <sender E2E ratchet parameters, see pqdr.md>
 encConnInfo = doubleRatchetEncryptedMessage

 agentMsgEnvelope = agentVersion %s"M" encAgentMessage
@@ -166,13 +184,25 @@ encAgentMessage = doubleRatchetEncryptedMessage

 agentInvitation = agentVersion %s"I" connReqLength connReq connInfo
 connReqLength = 2*2 OCTET ; Word16
+connReq = *OCTET ; URI text encoding of connection link, length given by connReqLength
+connInfo = *OCTET ; opaque connection information (remaining bytes)

-agentRatchetKey = agentVersion %s"R" rcvE2EEncryptionParams agentRatchetInfo
-rcvE2EEncryptionParams = TODO
+agentRatchetKey = agentVersion %s"R" rcvE2EEncryptionParams ratchetKeyInfo
+rcvE2EEncryptionParams = <receiver E2E ratchet parameters, see pqdr.md>
+ratchetKeyInfo = *OCTET ; additional ratchet renegotiation info (remaining bytes)

-doubleRatchetEncryptedMessage = TODO
+doubleRatchetEncryptedMessage = <double ratchet encrypted message, see pqdr.md>
 ```

+The maximum size of the encrypted connection info and agent message depend on whether post-quantum key exchange is used:
+
+| Constant | PQ on | PQ off |
+|----------|-------|--------|
+| `e2eEncConnInfoLength` | 11106 | 14832 |
+| `e2eEncAgentMsgLength` | 13618 | 15840 |
+
+The PQ-on sizes are smaller because the ratchet header and reply link include larger PQ keys (SNTRUP761).
+
 This syntax of decrypted SMP client message body is defined by `decryptedAgentMessage` below.

 Decrypted SMP message client body can be one of 4 types:
@@ -182,14 +212,15 @@ Decrypted SMP message client body can be one of 4 types:
 - `agentMessage` - all other agent messages.

 `agentMessage` contains these parts:
- `agentMsgHeader` - agent message header that contains sequential agent message ID for a particular SMP queue, agent timestamp (ISO8601) and the hash of the previous message.
+- `agentMsgHeader` - agent message header that contains sequential agent message ID for a particular SMP queue and the hash of the previous message.
 - `aMessage` - a command/message to the other SMP agent:
  - to confirm the connection (`HELLO`).
  - to send and to confirm reception of user messages (`A_MSG`, `A_RCVD`).
  - to confirm that the new double ratchet encryption is agreed (`EREADY`).
  - to notify another party that it can continue sending messages after queue capacity was exceeded (`A_QCONT`).
  - to manage SMP queue rotation (`QADD`, `QKEY`, `QUSE`, `QTEST`).
- `msgPadding` - an optional message padding to make all SMP messages have constant size, to prevent servers from observing the actual message size. The only case the message padding can be absent is when the message has exactly the maximum size, in all other cases the message MUST be padded to a fixed size.
+
+The encoded `agentMessage` is padded to a fixed size by the double ratchet encryption layer (see [ratchet message wire format](./pqdr.md#ratchet-message-wire-format)) to make all SMP messages have constant size, preventing routers from observing the actual message size.

 ### Messages between SMP agents

@@ -200,9 +231,11 @@ decryptedAgentMessage = agentConnInfo / agentConnInfoReply / agentRatchetInfo /
 agentConnInfo = %s"I" connInfo
 connInfo = *OCTET
 agentConnInfoReply = %s"D" smpQueues connInfo
+smpQueues = length 1*newQueueInfo ; NonEmpty list of reply queues
 agentRatchetInfo = %s"R" ratchetInfo
+ratchetInfo = *OCTET

-agentMessage = %s"M" agentMsgHeader aMessage msgPadding
+agentMessage = %s"M" agentMsgHeader aMessage
 agentMsgHeader = agentMsgId prevMsgHash
 agentMsgId = 8*8 OCTET ; Int64
 prevMsgHash = shortString
@@ -213,10 +246,13 @@ aMessage = HELLO / A_MSG / A_RCVD / EREADY / A_QCONT /
 HELLO = %s"H"

 A_MSG = %s"M" userMsgBody
-userMsgBody = *OCTET
+userMsgBody = *OCTET ; remaining bytes

-A_RCVD = %s"V" msgReceipt
+A_RCVD = %s"V" msgReceipts
+msgReceipts = length 1*msgReceipt ; NonEmpty list
 msgReceipt = agentMsgId msgHash rcptLength rcptInfo
+msgHash = shortString
+rcptInfo = *OCTET ; opaque receipt info, length given by rcptLength (Word16)

 EREADY = %s"E" agentMsgId

@@ -224,14 +260,14 @@ A_QCONT = %s"QC" sndQueueAddr

 QADD = %s"QA" sndQueues
 sndQueues = length 1*(newQueueUri replacedSndQueue)
-newQueueUri = clientVRange smpServer senderId dhPublicKey [sndSecure]
+newQueueUri = clientVRange smpRouter senderId dhPublicKey [queueMode]
 dhPublicKey = length x509encoded
-sndSecure = "T"
+queueMode = %s"M" / %s"C" ; M - messaging (sender can secure), C - contact
 replacedSndQueue = "0" / "1" sndQueueAddr

 QKEY = %s"QK" sndQueueKeys
 sndQueueKeys = length 1*(newQueueInfo senderKey)
-newQueueInfo = version smpServer senderId dhPublicKey [sndSecure]
+newQueueInfo = version smpRouter senderId dhPublicKey [queueMode]
 senderKey = length x509encoded

 QUSE = %s"QU" sndQueuesReady
@@ -241,8 +277,8 @@ primary = %s"T" / %s"F"
 QTEST = %s"QT" sndQueueAddrs
 sndQueueAddrs = length 1*sndQueueAddr

-sndQueueAddr = smpServer senderId
-smpServer = hosts port keyHash
+sndQueueAddr = smpRouter senderId
+smpRouter = hosts port keyHash
 hosts = length 1*host
 host = shortString
 port = shortString
@@ -252,7 +288,6 @@ senderId = shortString
 clientVRange = version version
 version = 2*2 OCTET

-msgPadding = *OCTET
 rcptLength = 2*2 OCTET
 shortString = length *OCTET
 length = 1*1 OCTET
@@ -266,11 +301,11 @@ This message is not used with [fast duplex connection](#fast-duplex-connection-p

 #### A_MSG message

-This is the agent envelope used to send client messages once the connection is established. This is different from the MSG sent by SMP server to the agent and MSG event from SMP agent to the client that are sent in different contexts.
+This is the agent envelope used to send client messages once the connection is established. This is different from the MSG sent by SMP router to the agent and MSG event from SMP agent to the client that are sent in different contexts.

 #### A_RCVD message

-This message is sent to confirm the client message reception. It includes received message number and message hash.
+This message is sent to confirm the client message reception. It includes a list of message receipts, each containing the received message number, message hash and receipt info.

 #### EREADY message

@@ -282,7 +317,7 @@ This message is sent to notify the sender client that it can continue sending th

 ### Rotating messaging queue

-SMP agents SHOULD support 4 messages to rotate message reception to another messaging server:
+SMP agents SHOULD support 4 messages to rotate message reception to another messaging router:
 `QADD`: add the new queue address(es) to the connection - sent by the client that initiates rotation.
 `QKEY`: pass sender's key via existing connection (SMP confirmation message will not be used, to avoid the same "race" of the initial key exchange that would create the risk of intercepting the queue for the attacker) - sent by the client accepting the rotation
 `QUSE`: instruct the sender to use the new queue with sender's queue ID as parameter. From this point some messages can be sent to both the new queue and the old queue.
@@ -345,31 +380,191 @@ To summarize, the upgrade to DH+KEM secret happens in a sent message that has PQ

 Connection links are generated by SMP agent in response to `createConnection` api call, used by another party user with `joinConnection` api, and then another connection link is sent by the agent in `agentConnInfoReply` and used by the first party agent to connect to the reply queue (the second part of the process is invisible to the users).

-Connection link syntax:
+### Full connection link syntax

 ```
-connectionLink = connectionScheme "/" connLinkType "#/?smp=" smpQueues "&e2e=" e2eEncryption
+connectionLink = connectionScheme "/" connLinkType "#/?v=" versionRange "&smp=" smpQueues ["&e2e=" e2eEncryption] ["&data=" clientData]
 connLinkType = %s"invitation" / %s"contact"
-connectionScheme = (%s"https://" clientAppServer) | %s"simplex:"
+connectionScheme = (%s"https://" clientAppServer) / %s"simplex:"
 clientAppServer = hostname [ ":" port ]
 ; client app server, e.g. simplex.chat
-e2eEncryption = encryptionScheme ":" publicKey
-encryptionScheme = %s"rsa" ; end-to-end encryption and key exchange protocols,
-                           ; the current hybrid encryption scheme (RSA-OAEP/AES-256-GCM-SHA256)
-                           ; will be replaced with double ratchet protocol and DH key exchange.
-publicKey = <base64url X509 SPKI key encoding>
-smpQueues = smpQueue [ "," 1*smpQueue ] ; SMP queues for the connection
+versionRange = 1*DIGIT / 1*DIGIT "-" 1*DIGIT ; agent version range
+e2eEncryption = <e2e encryption parameters for double ratchet>
+smpQueues = smpQueue *(";" smpQueue) ; SMP queues for the connection (semicolon-separated)
 smpQueue = <URL-encoded queueURI defined in SMP protocol>
+clientData = <URL-encoded application-specific data>
 ```

-All parameters are passed via URI hash to avoid sending them to the server (in case "https" scheme is used) - they can be used by the client-side code and processed by the client application. Parameters `smp` and `e2e` can be present in any order, any unknown additional parameters SHOULD be ignored.
+All parameters are passed via URI hash to avoid sending them to the router (in case "https" scheme is used) - they can be used by the client-side code and processed by the client application. Parameters can be present in any order, any unknown additional parameters SHOULD be ignored.

-`clientAppServer` is not an SMP server - it is a server that shows the instruction on how to download the client app that will connect using this connection link. This server can also host a mobile or desktop app manifest so that this link is opened directly in the app if it is installed on the device.
+`clientAppServer` is not an SMP router - it is a server that shows the instruction on how to download the client app that will connect using this connection link. This server can also host a mobile or desktop app manifest so that this link is opened directly in the app if it is installed on the device.

-"simplex" URI scheme in `connectionProtocol` can be used instead of client app server, to connect without creating any web traffic. Client apps MUST support this URI scheme.
+"simplex" URI scheme in `connectionProtocol` can be used instead of client app router, to connect without creating any web traffic. Client apps MUST support this URI scheme.

 See SMP protocol [out-of-band messages](./simplex-messaging.md#out-of-band-messages) for syntax of `queueURI`.

+### Short connection link syntax
+
+Short links provide a more compact representation by storing connection data on the router:
+
+```
+shortLink = shortLinkScheme "/" linkType "#" [linkId "/"] linkKey ["?" shortLinkParams]
+shortLinkScheme = %s"simplex:" / (%s"https://" serverHost)
+linkType = %s"i" / contactType ; i - invitation, or contact type
+contactType = %s"a" / %s"c" / %s"g" / %s"r" ; a - contact, c - channel, g - group, r - relay
+linkId = base64url ; only for invitation links
+linkKey = base64url ; SHA3-256 hash of fixed data, used to decrypt link data
+shortLinkParams = hostParam ["&" portParam] ["&" keyHashParam]
+hostParam = %s"h=" hostList
+hostList = host *("," host)
+portParam = %s"p=" port
+keyHashParam = %s"c=" base64url ; router certificate fingerprint
+```
+
+Contact types:
+- `a` (CCTContact) - direct contact connection
+- `c` (CCTChannel) - channel connection
+- `g` (CCTGroup) - group connection
+- `r` (CCTRelay) - relay connection
+
+Short links can use either the `simplex:` scheme or `https://` with a router hostname. When using the simplex scheme, router information is included in query parameters.
+
+## Short links
+
+Short links provide a compact representation of connection links by storing encrypted connection data on the SMP router. The link key in the URI fragment (after `#`) is never sent to the router, ensuring the router cannot decrypt the stored connection data.
+
+### Link key derivation
+
+The link key is derived from the fixed link data using SHA3-256 hash function:
+
+```
+linkKey = SHA3-256(fixedLinkData)
+```
+
+The fixed link data includes:
+- Agent version range
+- Root public key (Ed25519) for signing
+- SMP queue connection request (router, queue IDs, encryption keys)
+- Optional link entity ID
+
+For contact links, the link ID and encryption key are derived from the link key using HKDF:
+
+```
+(linkId, encryptionKey) = HKDF(info="SimpleXContactLink", key=linkKey, outputLen=56)
+; linkId = first 24 bytes, encryptionKey = remaining 32 bytes
+```
+
+For invitation links, the link ID is stored separately (usually included in the URI), and only the encryption key is derived:
+
+```
+encryptionKey = HKDF(info="SimpleXInvLink", key=linkKey, outputLen=32)
+```
+
+### Link data encryption
+
+Link data stored on the router consists of two encrypted parts: fixed data and user data. Both are encrypted using NaCl secret_box (XSalsa20-Poly1305) with the derived encryption key:
+
+```abnf
+queueLinkData = encFixedData encUserData
+encFixedData = largeString ; encrypted padded(signedFixedData, 2008)
+encUserData = largeString ; encrypted padded(signedUserData, 13784)
+
+signedFixedData = signature fixedData
+signedUserData = signature userData
+signature = length 64*64 OCTET ; Ed25519 signature
+
+fixedData = agentVersionRange rootKey linkConnReq [linkEntityId]
+agentVersionRange = version version ; min and max agent protocol version
+version = 2*2 OCTET
+rootKey = length x509encoded ; Ed25519 public key
+linkConnReq = invitationConnReq / contactConnReq ; binary encoding of connection request
+invitationConnReq = %s"I" connReqData e2eRatchetParams
+contactConnReq = %s"C" connReqData
+linkEntityId = shortString
+userData = invitationLinkData / contactLinkData
+invitationLinkData = %s"I" agentVersionRange userLinkData
+contactLinkData = %s"C" agentVersionRange userContactData
+userLinkData = shortString / (%xFF largeString) ; opaque application data (e.g., user profile)
+  ; shortString length byte 0x00-0xFE (max 254 bytes); 0xFF is reserved as largeString sentinel
+userContactData = direct ownersList relaysList userLinkData
+direct = %s"T" / %s"F" ; whether direct connection via connReq is allowed
+ownersList = length *ownerAuth
+ownerAuth = shortString ; length-prefixed encoding of (ownerId ownerKey authOwnerSig)
+ownerId = shortString ; application-specific owner ID (e.g., MemberId)
+ownerKey = length x509encoded ; Ed25519 public key
+authOwnerSig = length 64*64 OCTET ; Ed25519 signature of (ownerId || ownerKey) by previous owner
+relaysList = length *connShortLink ; alternative relay short links
+
+; Binary encoding of connection request (used in linkConnReq)
+connReqData = agentVersionRange smpQueueUris clientData
+smpQueueUris = length 1*smpQueueUri
+clientData = %s"0" / (%s"1" largeString) ; Maybe (Large ByteString)
+smpQueueUri = smpClientVersionRange smpServer senderId smpDhPublicKey [queueMode]
+smpClientVersionRange = version version ; min and max SMP client versions
+smpServer = hosts port serverKeyHash
+hosts = length 1*host
+host = shortString ; text-encoded hostname or IP address
+port = shortString ; text-encoded port number
+serverKeyHash = shortString ; CA certificate fingerprint
+senderId = shortString ; queue sender ID
+smpDhPublicKey = length x509encoded ; X25519 DH public key
+queueMode = %s"M" / %s"C" ; messaging or contact (version-dependent trailing field)
+e2eRatchetParams = e2eVersionRange e2eDhKey e2eDhKey kemParams
+e2eVersionRange = version version ; min and max e2e encryption versions
+e2eDhKey = length x509encoded ; X448 DH public key
+kemParams = %s"0" / (%s"1" ratchetKEMParams)
+ratchetKEMParams = %s"P" kemPublicKey / %s"A" kemCiphertext kemPublicKey
+kemPublicKey = largeString ; sntrup761 public key
+kemCiphertext = largeString ; sntrup761 ciphertext
+
+; Binary encoding of short link (used in relaysList)
+connShortLink = invShortLink / contactShortLink
+invShortLink = %s"I" smpServer linkId linkKey
+contactShortLink = %s"C" contactConnType smpServer linkKey
+contactConnType = %s"A" / %s"C" / %s"G" / %s"R" ; contact / channel / group / relay
+linkId = shortString
+linkKey = shortString
+
+x509encoded = *OCTET ; DER-encoded X.509 SubjectPublicKeyInfo
+largeString = 2*2 OCTET *OCTET ; Word16 length prefix
+length = 1*1 OCTET
+shortString = length *OCTET
+```
+
+The fixed data is signed with the root key and its hash becomes the link key. The user data is signed either with the root key (for invitations) or with an owner key (for contact addresses).
+
+### Short link resolution
+
+When a user receives a short link, the agent resolves it as follows:
+
+1. Extract the link key from the URI fragment
+2. Send `LGET` command to the SMP router with the link ID
+3. Receive encrypted link data from the router
+4. Decrypt the link data using the link key
+5. Extract the full connection information (SMP queue URI, encryption keys, profile)
+6. Proceed with the standard connection procedure using `joinConnection`
+
+For invitation links, the `LKEY` command is used to set the sender key when getting link data. Repeated `LKEY` would require using the same key.
+
+### Link data management
+
+The recipient who created the queue can manage the short link data:
+
+- **LSET** - Set or update the link data associated with a queue. This is used when creating a short link or updating the user data (e.g., profile changes).
+- **LDEL** - Delete the link data from the router. This effectively invalidates the short link.
+
+Short links support different connection modes:
+- **invitation** - One-time invitation links that can only be used once
+- **contact** - Reusable contact address links that can be used multiple times
+
+For contact addresses, the link data includes additional information about the contact type:
+- **contact** - Direct contact connection
+- **channel** - Channel connection
+- **group** - Group connection
+- **relay** - Relay connection
+
+The agent maintains the link data and updates it when connection parameters change, ensuring short links remain valid and reflect current connection information.
+
 ## Appendix A: SMP agent API

 The exact specification of agent library API and of the events that the agent sends to the client application is out of scope of the protocol specification.
@@ -380,7 +575,7 @@ The list of some of the API functions and events below is supported by the refer

 The list of APIs below is not exhaustive and provided for information only. Please consult the source code for more information.

-#### Create conection
+#### Create connection

 `createConnection` api is used to create a connection - it returns the connection link that should be sent out-of-band to another protocol user (the joining party). It should be used by the client of the agent that initiates creating a duplex connection (the initiating party).

@@ -408,13 +603,13 @@ Client can `acceptContact` and `rejectContact`, with `OK` and `ERR` events in ca

 #### Send message

-`sendMessage` api is always asynchronous. The api call returns message ID, `SENT` event once the message is sent to the server, `MWARN` event in case of temporary delivery failure that can be resolved by the user (e.g., by connecting via Tor or by upgrading the client) and `MERR` in case of permanent delivery failure.
+`sendMessage` api is always asynchronous. The api call returns message ID, `SENT` event once the message is sent to the router, `MWARN` event in case of temporary delivery failure that can be resolved by the user (e.g., by connecting via Tor or by upgrading the client) and `MERR` in case of permanent delivery failure.

 #### Acknowledge received message

 Messages are delivered to the client application via `MSG` event.

-Client application must always `ackMessage` to receive the next one - failure to call it in reference implementation will prevent the delivery of subsequent messages until the client reconnects to the server.
+Client application must always `ackMessage` to receive the next one - failure to call it in reference implementation will prevent the delivery of subsequent messages until the client reconnects to the router.

 This api is also used to acknowledge message delivery to the sending party - that party client application will receive `RCVD` event.

@@ -426,9 +621,17 @@ This api is also used to acknowledge message delivery to the sending party - tha

 `getNotificationMessage` is used by push notification subsystem of the client application to receive the message from a specific messaging queue mentioned in the notification. The client application would receive `MSG` and any other events from the agent, and then `MSGNTF` event once the message related to this notification is received.

-#### Rotate message queue to another server
+#### Set short link data

-`switchConnection` api is used to rotate connection queues to another messaging server.
+`setConnectionLink` api (`LSET` command) is used to set or update short link data associated with a contact address queue. Returns `LINK` event with the short link URI.
+
+#### Get short link data
+
+`getConnectionLink` api (`LGET` command) is used to retrieve and decrypt the short link data from the router. Returns `LDATA` event with the decrypted link data.
+
+#### Rotate message queue to another router
+
+`switchConnection` api is used to rotate connection queues to another messaging router.

 #### Renegotiate e2e encryption

@@ -436,7 +639,7 @@ This api is also used to acknowledge message delivery to the sending party - tha

 #### Delete connection

-`deleteConnection` api is used to delete connection. In case of asynchronous call, the connection deletion will be confirmed with `DEL_RCVQ` and `DEL_CONN` events.
+`deleteConnection` api is used to delete connection. In case of asynchronous call, the connection deletion will be confirmed with `DEL_RCVQS` and `DEL_CONNS` events.

 #### Suspend connection

@@ -451,25 +654,80 @@ Agent API uses these events dispatch to notify client application about events r
 - `INFO` - information from the party that initiated the connection with `createConnection` sent to the party accepting the connection with `joinConnection`.
 - `CON` - notification that connection is established sent to both parties of the connection.
 - `END` - notification that connection subscription is terminated when another client subscribed to the same messaging queue.  
- `DOWN` - notification that connection server is temporarily unavailable.
- `UP` - notification that the subscriptions made in the current client session are resumed after the server became available.
+- `DOWN` - notification that connection router is temporarily unavailable.
+- `UP` - notification that the subscriptions made in the current client session are resumed after the router became available.
 - `SWITCH` - notification about queue rotation process.
 - `RSYNC` - notification about e2e encryption re-negotiation process.
- `SENT` - notification to confirm that the message was delivered to at least one of SMP servers. This notification contains the same message ID as returned to `sendMessage` api. `SENT` notification, depending on network availability, can be sent at any time later, potentially in the next client session.
+- `SENT` - notification to confirm that the message was delivered to at least one of SMP routers. This notification contains the same message ID as returned to `sendMessage` api. `SENT` notification, depending on network availability, can be sent at any time later, potentially in the next client session.
 - `MWARN` - temporary delivery failure that can be resolved by the user (e.g., by connecting via Tor or by upgrading the client).
 - `MERR` - notification about permanent message delivery failure.
 - `MERRS` - notification about permanent message delivery failure for multiple messages (e.g., when multiple messages expire).
- `MSG` - sent when agent receives the message from the SMP server.
+- `MSG` - sent when agent receives the message from the SMP router.
 - `MSGNTF` - sent after agent received and processed the message referenced in the push notification.
 - `RCVD` - notification confirming message receipt by another party.
 - `QCONT` - notification that the agent continued sending messages after queue capacity was exceeded and recipient received all messages.
- `DEL_RCVQ` - confirmation that message queue was deleted.
- `DEL_CONN` - confirmation that connection was deleted.
+- `LINK` - short link URI created or updated for a contact address.
+- `LDATA` - decrypted short link data received from the router.
+- `DELD` - notification that the connection was deleted.
+- `JOINED` - notification that a member joined via a contact address.
+- `STAT` - connection statistics event.
+- `DEL_RCVQS` - confirmation that receiver message queues were deleted.
+- `DEL_CONNS` - confirmation that connections were deleted.
 - `OK` - confirmation that asynchronous api call was successful.
 - `ERR` - error of asynchronous api call or some other error event.

 This list of events is not exhaustive and provided for information only. Please consult the source code for more information.

+## Threat model
+
+This threat model complements SimpleX Messaging Protocol [threat model](./security.md#threat-model) with agent-level concerns: duplex connections, end-to-end encryption with [post-quantum double ratchet](./pqdr.md), message integrity, connection establishment and queue rotation. Only additional properties not covered in the SMP threat model are listed below.
+
+#### Additional global assumptions
+
+ - The connection link is shared via a trusted out-of-band channel.
+ - Both agents support post-quantum double ratchet (PQDR).
+
+#### A passive adversary
+
+*cannot:*
+ - learn the contents of packets, which are additionally encrypted with the double ratchet independently from per-queue encryption.
+
+#### Destination router (chosen by the receiving client application)
+
+*can:*
+ - correlate queues belonging to the same duplex connection when queue rotation creates a new queue on the same router.
+ - when both peers of a connection chose the same router, correlate the two directions of the duplex connection.
+
+*cannot:*
+ - compromise end-to-end encryption even with full access to the per-queue NaCl DH secret.
+ - correlate queues belonging to the same connection after queue rotation to a different router.
+
+#### An attacker who obtained a client application's (decrypted) database
+
+*can:*
+ - learn the full communication graph: all communication peers, associated router addresses, and queue identifiers.
+
+*cannot:*
+ - decrypt future messages once the client application resumes communication and the double ratchet completes a new ratchet step, provided PQDR is active.
+
+#### A communication peer
+
+*can:*
+ - send malformed agent messages that may affect the client application processing them.
+ - skip message IDs, causing the recipient to generate and store excessive intermediate ratchet keys.
+ - prevent double ratchet advancement by not sending messages, delaying break-in recovery.
+
+*cannot:*
+ - disrupt packet delivery in other queues.
+
+#### An attacker who obtained a connection link
+
+*can:*
+ - learn the initiating party's chosen router address and public keys.
+
+*cannot:*
+ - use the link after the intended recipient has completed the connection.
+
 [1]: https://en.wikipedia.org/wiki/End-to-end_encryption
 [2]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
 [3]: https://tools.ietf.org/html/rfc5234
@@ -1,4 +1,4 @@
-Revision 2, 2024-06-22
+Revision 4, 2026-03-09

 Evgeny Poberezkin

@@ -8,16 +8,17 @@ Evgeny Poberezkin

 - [Introduction](#introduction)
  - [What is SimpleX](#what-is-simplex)
+  - [Network model](#network-model)
+  - [Applications](#applications)
  - [SimpleX objectives](#simplex-objectives)
  - [In Comparison](#in-comparison)
 - [Technical Details](#technical-details)
-  - [Trust in Servers](#trust-in-servers)
-  - [Client -> Server Communication](#client---server-communication)
+  - [Trust in Routers](#trust-in-routers)
+  - [Client -> Router Communication](#client---router-communication)
  - [2-hop Onion Message Routing](#2-hop-onion-message-routing)
  - [SimpleX Messaging Protocol](#simplex-messaging-protocol)
  - [SimpleX Agents](#simplex-agents)
-  - [Encryption Primitives Used](#encryption-primitives-used)
- [Threat model](#threat-model)
+- [Security](#security)
 - [Acknowledgements](#acknowledgements)


@@ -27,27 +28,27 @@ Evgeny Poberezkin

 SimpleX as a whole is a platform upon which applications can be built. [SimpleX Chat](https://github.com/simplex-chat/simplex-chat) is one such application that also serves as an example and reference application.

- - [SimpleX Messaging Protocol](./simplex-messaging.md) (SMP) is a protocol to send messages in one direction to a recipient, relying on a server in-between. The messages are delivered via uni-directional queues created by recipients.
- 
- - SMP protocol allows to send message via a SMP server playing proxy role using 2-hop onion routing (referred to as "private routing" in messaging clients) to protect transport information of the sender (IP address and session) from the server chosen (and possibly controlled) by the recipient.
+ - [SimpleX Messaging Protocol](./simplex-messaging.md) (SMP) is a protocol to send messages in one direction to a recipient, relying on a router in-between. The messages are delivered via uni-directional queues created by recipients.
+
+ - SMP protocol allows to send message via a SMP router playing proxy role using 2-hop onion routing (referred to as "private routing" in messaging clients) to protect transport information of the sender (IP address and session) from the router chosen (and possibly controlled) by the recipient.

 - SMP runs over a transport protocol (shown below as TLS) that provides integrity, server authentication, confidentiality, and transport channel binding.

- - A SimpleX Server is one of those servers.
+ - A SimpleX router is one of those routers.

- - The SimpleX Network is the term used for the collective of SimpleX Servers that facilitate SMP.
+ - The SimpleX Network is the term used for the collective of SimpleX routers that facilitate SMP.

- - SimpleX Client libraries speak SMP to SimpleX Servers and provide a low-level API not generally intended to be used by applications.
+ - SimpleX Client libraries speak SMP to SimpleX routers and provide a low-level API not generally intended to be used by applications.

 - SimpleX Agents interface with SimpleX Clients to provide a more high-level API intended to be used by applications. Typically they are embedded as libraries, but can also be abstracted into local services.

 - SimpleX Agents communicate with other agents inside e2e encrypted envelopes provided by SMP protocol - the syntax and semantics of the messages exchanged by the agent are defined by [SMP agent protocol](./agent-protocol.md)


-*Diagram showing the SimpleX Chat app, with logical layers of the chat application interfacing with a SimpleX Agent library, which in turn interfaces with a SimpleX Client library. The Client library in turn speaks the Messaging Protocol to a SimpleX Server.*
+*Diagram showing the SimpleX Chat app, with logical layers of the chat application interfacing with a SimpleX Agent library, which in turn interfaces with a SimpleX Client library. The Client library in turn speaks the Messaging Protocol to a SimpleX router.*

 ```
-  User's Computer                 Internet                    Third-Party Server
+  User's Computer                 Internet                    Third-Party Router
 ------------------     |   ----------------------     |   -------------------------
                       |                              |
   SimpleX Chat        |                              |
@@ -57,11 +58,43 @@ SimpleX as a whole is a platform upon which applications can be built. [SimpleX
 +----------------+     |                              |
 |  SimpleX Agent |     |                              |
 +----------------+    -------------- TLS ----------------    +----------------+
-| SimpleX Client | ------ SimpleX Messaging Protocol ------> | SimpleX Server |
+| SimpleX Client | ------ SimpleX Messaging Protocol ------> | SimpleX router |
 +----------------+    -----------------------------------    +----------------+
                       |                              |
 ```

+#### Network model
+
+SimpleX is a general-purpose packet routing network built on top of the Internet. Network endpoints — end-user devices, automated services, AI-enabled applications, IoT devices — exchange data packets through SimpleX network nodes (SMP routers), which accept, buffer, and deliver packets. Each router operates independently and can be operated by any party on standard computing hardware.
+
+SimpleX routers use resource-based addressing: each address identifies a resource on a router, similar to how the World Wide Web addresses resources via URLs. Internet routers, by comparison, use endpoint-based addressing, where IP addresses identify destination devices. Because of this design, SimpleX network participants do not need globally unique addresses to communicate.
+
+SimpleX network has two resource-based addressing schemes:
+
+- *Messaging queues* ([SMP](./simplex-messaging.md)). A queue is a unidirectional, ordered sequence of fixed-size data packets (16,384 bytes each). Each queue has a resource address on a specific router, gated by cryptographic credentials that separately authorize sending and receiving.
+
+- *Data packets* ([XFTP](./xftp.md)). A data packet is an individually addressed block in one of the standard sizes. Each packet has a unique resource address on a specific router, gated by cryptographic credentials. Data packet addressing is more efficient for delivery of larger payloads than queues.
+
+Packet delivery follows a two-router path. The sending endpoint submits a packet to a first router, which forwards it to a second router, where the receiving endpoint retrieves it. The sending endpoint's IP address is known only to the first router; the receiving endpoint's IP address is known only to the second router. See [2-hop Onion Message Routing](#2-hop-onion-message-routing) for details.
+
+Routers buffer packets between submission and retrieval — from seconds to days, enabling asynchronous delivery when endpoints are online at different times. Packets are removed after delivery or after a configured expiration period.
+
+
+#### Applications
+
+Applications currently using SimpleX network:
+
+- **SimpleX Chat** — a peer-to-peer messenger using SimpleX network as a transport layer, in the same way that communication applications use WebRTC, Tor, i2p, or Nym. All communication logic — contacts, conversations, groups, message formats, end-to-end encryption — runs on endpoint devices.
+
+- **IoT devices** — using the SimpleX queue protocol directly for sensor data collection and device control.
+
+- **AI-based services** — automated services built on the SimpleX Chat application core.
+
+- **Secure monitoring and control systems** — applications for equipment monitoring and control, including robotics, using the network for command delivery and telemetry collection.
+
+[SimpleGo](https://simplego.dev), developed by an independent organization, is a microcontroller-based device running a SimpleX Chat-compatible messenger directly on a microcontroller without a general-purpose operating system. Running over 20 days on a single battery charge, it demonstrates the energy efficiency of resource-based addressing: the device receives packets without continuous polling. A microcontroller-based router implementation that functions simultaneously as a WiFi router is also in development.
+
+
 #### SimpleX objectives

 1. Provide messaging infrastructure for distributed applications. This infrastructure needs to have the following qualities:
@@ -70,7 +103,7 @@ SimpleX as a whole is a platform upon which applications can be built. [SimpleX

   - Privacy: protect against traffic correlation attacks to determine the contacts that the users communicate with.

-   - Reliability: the messages should be delivered even if some participating network servers or receiving clients fail, with “at least once” delivery guarantee.
+   - Reliability: the messages should be delivered even if some participating network routers or receiving clients fail, with "at least once" delivery guarantee.

   - Integrity: the messages sent in one direction are ordered in a way that sender and recipient agree on; the recipient can detect when a message was removed or changed.

@@ -78,63 +111,63 @@ SimpleX as a whole is a platform upon which applications can be built. [SimpleX

   - Low latency: the delay introduced by the network should not be higher than 100ms-1s in addition to the underlying TCP network latency.

-2. Provide better communication security and privacy than the alternative instant messaging solutions. In particular SimpleX provides better privacy of metadata (who talks to whom and when) and better security against active network attackers and malicious servers.
+2. Provide better communication security and privacy than the alternative instant messaging solutions. In particular SimpleX provides better privacy of metadata (who talks to whom and when) and better security against active network attackers and malicious routers.

 3. Balance user experience with privacy requirements, prioritizing experience of mobile device users.


 #### In Comparison

-SimpleX network has a design similar to P2P networks, but unlike most P2P networks it consists of clients and servers without depending on any centralized component.
+SimpleX network has a design similar to P2P networks, but unlike most P2P networks it consists of clients and routers without depending on any centralized component.
 In comparison to more traditional messaging applications (e.g. WhatsApp, Signal, Telegram) the key differences of SimpleX network are:

 - participants do not need to have globally unique addresses to communicate, instead they use redundant unidirectional (simplex) messaging queues, with a separate set of queues for each contact.

 - connection requests are passed out-of-band, non-optionally protecting key exchange against man-in-the-middle attack.

- simple message queues provided by network servers are used by the clients to create more complex communication scenarios, such as duplex one-to-one communication, transmitting files, group communication without central servers, and content/communication channels.
+- simple message queues provided by network routers are used by the clients to create more complex communication scenarios, such as duplex one-to-one communication, transmitting files, group communication without central routers, and content/communication channels.

- servers do not store any user information (no user profiles or contacts, or messages once they are delivered), and primarily use in-memory persistence.
+- routers do not store any user information (no user profiles or contacts, or messages once they are delivered), and primarily use in-memory persistence.

- users can change servers with minimal disruption - even after an in-use server disappears, simply by changing the configuration on which servers the new queues are created.
+- users can change routers with minimal disruption - even after an in-use router disappears, simply by changing the configuration on which routers the new queues are created.


 ## Technical Details

-#### Trust in Servers
+#### Trust in Routers

-Clients communicate directly with servers (but not with other clients) using SimpleX Messaging Protocol (SMP) running over some transport protocol that provides integrity, server authentication, confidentiality, and transport channel binding. By default, we assume this transport protocol is TLS.
+Clients communicate directly with routers (but not with other clients) using SimpleX Messaging Protocol (SMP) running over some transport protocol that provides integrity, server authentication, confidentiality, and transport channel binding. By default, we assume this transport protocol is TLS.

-Users use multiple servers, and choose where to receive their messages. Accordingly, they send messages to their communication partners' chosen servers either directly, if this is a known/trusted server, or via another SMP server providing proxy functionality to protect IP address and session of the sender.
+Users use multiple routers, and choose where to receive their messages. Accordingly, they send messages to their communication partners' chosen routers either directly, if this is a known/trusted router, or via another SMP router providing proxy functionality to protect IP address and session of the sender.

-Although end-to-end encryption is always present, users place a degree of trust in servers they connect to. This trust decision is very similar to a user's choice of email provider; however the trust placed in a SimpleX server is significantly less. Notably, there is no re-used identifier or credential between queues on the same (or different) servers. While a user *may* re-use a transport connection to fetch messages from multiple queues, or connect to a server from the same IP address, both are choices a user may opt into to break the promise of un-correlatable queues.
+Although end-to-end encryption is always present, users place a degree of trust in routers they connect to. This trust decision is very similar to a user's choice of email provider; however the trust placed in a SimpleX router is significantly less. Notably, there is no re-used identifier or credential between queues on the same (or different) routers. While a user *may* re-use a transport connection to fetch messages from multiple queues, or connect to a router from the same IP address, both are choices a user may opt into to break the promise of un-correlatable queues.

-Users may trust a server because:
+Users may trust a router because:

- They deploy and control the servers themselves from the available open-source code. This has the trade-offs of strong trust in the server but limited metadata obfuscation to a passive network observer. Techniques such as noise traffic, traffic mixing (incurring latency), and using an onion routing transport protocol can mitigate that.
+- They deploy and control the routers themselves from the available open-source code. This has the trade-offs of strong trust in the router but limited metadata obfuscation to a passive network observer. Techniques such as noise traffic, traffic mixing (incurring latency), and using an onion routing transport protocol can mitigate that.

- They use servers from a trusted commercial provider. The more clients the provider has, the less metadata about the communication times is leaked to the network observers.
+- They use routers from a trusted commercial provider. The more clients the provider has, the less metadata about the communication times is leaked to the network observers.

-By default, servers do not retain access logs, and permanently delete messages and queues when requested. Messages persist only in memory until they cross a threshold of time, typically on the order of days.[0] There is still a risk that a server maliciously records all queues and messages (even though encrypted) sent via the same transport connection to gain a partial knowledge of the user’s communications graph and other meta-data.
+By default, routers do not retain access logs, and permanently delete messages and queues when requested. Messages persist in memory or in a database until they cross a threshold of time, typically on the order of days.[0] There is still a risk that a router maliciously records all queues and messages (even though encrypted) sent via the same transport connection to gain a partial knowledge of the user's communications graph and other meta-data.

-SimpleX supports measures (managed transparently to the user at the agent level) to mitigate the trust placed in servers.  These include rotating the queues in use between users, noise traffic, supporting overlay networks such as Tor, and isolating traffic to different queues to different transport connections (and Tor circuits, if Tor is used).
+SimpleX supports measures (managed transparently to the user at the agent level) to mitigate the trust placed in routers.  These include rotating the queues in use between users, noise traffic, supporting overlay networks such as Tor, and isolating traffic to different queues to different transport connections (and Tor circuits, if Tor is used).

-[0] While configurable by servers, a minimum value is enforced by the default software. SimpleX Agents can provide redundant routing over queues to mitigate against message loss.
+[0] While configurable by routers, a minimum value is enforced by the default software. SimpleX Agents can provide redundant routing over queues to mitigate against message loss.


-#### Client -> Server Communication
+#### Client -> Router Communication

 Utilizing TLS grants the SimpleX Messaging Protocol (SMP) server authentication and metadata protection to a passive network observer. But SMP does not rely on the transport protocol for message confidentiality or client authentication. The SMP protocol itself provides end-to-end confidentiality, authentication, and integrity of messages between communicating parties.

-Servers have long-lived, self-signed, offline certificates whose hash is pre-shared with clients over secure channels - either provided with the client library or provided in the secure introduction between clients, as part of the server address.  The offline certificate signs an online certificate used in the transport protocol handshake. [0]
+Routers have long-lived, self-signed, offline certificates whose hash is pre-shared with clients over secure channels - either provided with the client library or provided in the secure introduction between clients, as part of the router address.  The offline certificate signs an online certificate used in the transport protocol handshake. [0]

-If the transport protocol's confidentiality is broken, incoming and outgoing messages to the server cannot be correlated by message contents. Additionally, because of encryption at the SMP layer, impersonating the server is not sufficient to pass (and therefore correlate) a message from a sender to recipient - the only attack possible is to drop the messages. Only by additionally *compromising* the server can one pass and correlate messages.
+If the transport protocol's confidentiality is broken, incoming and outgoing messages to the router cannot be correlated by message contents. Additionally, because of encryption at the SMP layer, impersonating the router is not sufficient to pass (and therefore correlate) a message from a sender to recipient - the only attack possible is to drop the messages. Only by additionally *compromising* the router can one pass and correlate messages.

-It's important to note that the SMP protocol does not do server authentication. Instead we rely upon the fact that an attacker who tricks the transport protocol into authenticating the server incorrectly cannot do anything with the SMP messages except drop them.
+It's important to note that the SMP protocol does not do server authentication. Instead we rely upon the fact that an attacker who tricks the transport protocol into authenticating the router incorrectly cannot do anything with the SMP messages except drop them.

-After the connection is established, the client sends blocks of a fixed size 16KB, and the server replies with the blocks of the same size to reduce metadata observable to a network adversary. The protocol has been designed to make traffic correlation attacks difficult, adapting ideas from Tor, remailers, and more general onion and mix networks. It does not try to replace Tor though - SimpleX servers can be deployed as onion services and SimpleX clients can communicate with servers over Tor to further improve participants privacy.
+After the connection is established, the client sends blocks of a fixed size 16KB, and the router replies with the blocks of the same size to reduce metadata observable to a network adversary. The protocol has been designed to make traffic correlation attacks difficult, adapting ideas from Tor, remailers, and more general onion and mix networks. It does not try to replace Tor though - SimpleX routers can be deployed as onion services and SimpleX clients can communicate with routers over Tor to further improve participants privacy.

-By using fixed-size blocks, oversized for the expected content, the vast majority of traffic is uniform in nature. When enough traffic is transiting a server simultaneously, the server acts as a low-latency mix node. We can't rely on this behavior to make a security claim, but we have engineered to take advantage of it when we can. As mentioned, this holds true even if the transport connection is compromised.
+By using fixed-size blocks, oversized for the expected content, the vast majority of traffic is uniform in nature. When enough traffic is transiting a router simultaneously, the router acts as a low-latency mix node. We can't rely on this behavior to make a security claim, but we have engineered to take advantage of it when we can. As mentioned, this holds true even if the transport connection is compromised.

 The protocol does not protect against attacks targeted at particular users with known identities - e.g., if the attacker wants to prove that two known users are communicating, they can achieve it by observing their local traffic. At the same time, it substantially complicates large-scale traffic correlation, making determining the real user identities much less effective.

@@ -143,39 +176,39 @@ The protocol does not protect against attacks targeted at particular users with

 #### 2-hop Onion Message Routing

-As SimpleX Messaging Protocol servers providing messaging queues are chosen by the recipients, in case senders connect to these servers directly the server owners (who potentially can be the recipients themselves) can learn senders' IP addresses (if Tor is not used) and which other queues on the same server are accessed by the user in the same transport connection (even if Tor is used).
+As SimpleX Messaging Protocol routers providing messaging queues are chosen by the recipients, in case senders connect to these routers directly the router owners (who potentially can be the recipients themselves) can learn senders' IP addresses (if Tor is not used) and which other queues on the same router are accessed by the user in the same transport connection (even if Tor is used).

 While the clients support isolating the messages sent to different queues into different transport connections (and Tor circuits), this is not practical, as it consumes additional traffic and system resources.

-To mitigate this problem SimpleX Messaging Protocol servers support 2-hop onion message routing when the SMP server chosen by the sender forwards the messages to the servers chosen by the recipients, thus protecting both the senders IP addresses and sessions, even if connection isolation and Tor are not used.
+To mitigate this problem SimpleX Messaging Protocol routers support 2-hop onion message routing when the SMP router chosen by the sender forwards the messages to the routers chosen by the recipients, thus protecting both the senders IP addresses and sessions, even if connection isolation and Tor are not used.

 The design of 2-hop onion message routing prevents these potential attacks:

- MITM by proxy (SMP server that forwards the messages).
+- MITM by proxy (SMP router that forwards the messages).

- Identification by the proxy which and how many queues the sender sends messages to (as messages are additionally e2e encrypted between the sender and the destination SMP server).
+- Identification by the proxy which and how many queues the sender sends messages to (as messages are additionally e2e encrypted between the sender and the destination SMP router).

 - Correlation of messages sent to different queues via the same user session (as random correlation IDs and keys are used for each message).

 See more details about 2-hop onion message routing design in [SimpleX Messaging Protocol](./simplex-messaging.md#proxying-sender-commands)

-Also see [Threat model](#threat-model)
+Also see [Security](./security.md)


 #### SimpleX Messaging Protocol

-SMP is initialized with an in-person or out-of-band introduction message, where Alice provides Bob with details of a server (including IP address or host name, port, and hash of the long-lived offline certificate), a queue ID, and Alice's public keys to agree e2e encryption. These introductions are similar to the PANDA key-exchange, in that if observed, the adversary can race to establish the communication channel instead of the intended participant. [0]
+SMP is initialized with an in-person or out-of-band introduction message, where Alice provides Bob with details of a router (including IP address or host name, port, and hash of the long-lived offline certificate), a queue ID, and Alice's public keys to agree e2e encryption. These introductions are similar to the PANDA key-exchange, in that if observed, the adversary can race to establish the communication channel instead of the intended participant. [0]

 Because queues are uni-directional, Bob provides an identically-formatted introduction message to Alice over Alice's now-established receiving queue.

-When setting up a queue, the server will create separate sender and recipient queue IDs (provided to Alice during set-up and Bob during initial connection). Additionally, during set-up Alice will perform a DH exchange with the server to agree upon a shared secret. This secret will be used to re-encrypt Bob's incoming message before Alice receives it, creating the anti-correlation property earlier-described should the transport encryption be compromised.
+When setting up a queue, the router will create separate sender and recipient queue IDs (provided to Alice during set-up and Bob during initial connection). Additionally, during set-up Alice will perform a DH exchange with the router to agree upon a shared secret. This secret will be used to re-encrypt Bob's incoming message before Alice receives it, creating the anti-correlation property earlier-described should the transport encryption be compromised.

-[0] Users can additionally create public 'contact queues' that are only used to receive connection requests.  
+[0] Users can additionally create public 'contact queues' that are only used to receive connection requests.


 #### SimpleX Agents

-SimpleX agents provide higher-level operations compared to SimpleX Clients, who are primarily concerned with creating queues and communicating with servers using SMP.  Agent operations include:
+SimpleX agents provide higher-level operations compared to SimpleX Clients, who are primarily concerned with creating queues and communicating with routers using SMP.  Agent operations include:

 - Managing sets of bi-directional, redundant queues for communication partners

@@ -186,195 +219,21 @@ SimpleX agents provide higher-level operations compared to SimpleX Clients, who
 - Noise traffic


-#### Encryption Primitives Used
+## Security

- Ed25519 or Curve25519 to authorize/verify commands to SMP servers (authorization algorithm is set via client/server configuration).
- Curve25519 for DH exchange to agree:
-  - the shared secret between server and recipient (to encrypt message bodies - it avoids shared cipher-text in sender and recipient traffic)
-  - the shared secret between sender and recipient (to encrypt messages end-to-end in each queue - it avoids shared cipher-text in redundant queues).
- [NaCl crypto_box](https://nacl.cr.yp.to/box.html) encryption scheme (curve25519xsalsa20poly1305) for message body encryption between server and recipient and for E2E per-queue encryption.
- SHA256 to validate server offline certificates.
- [double ratchet](https://signal.org/docs/specifications/doubleratchet/) protocol for end-to-end message encryption between the agents:
-  - Curve448 keys to agree shared secrets required for double ratchet initialization (using [X3DH](https://signal.org/docs/specifications/x3dh/) key agreement with 2 ephemeral keys for each side),
-  - AES-GCM AEAD cipher,
-  - SHA512-based HKDF for key derivation.
+For encryption primitives, threat model, and detailed security analysis, see [Security](./security.md).

+SimpleX provides these security properties:

-## Threat Model
+- **End-to-end encryption** using Double Ratchet algorithm with forward secrecy and post-quantum cryptography.

-#### Global Assumptions
+- **No shared identifiers** across connections — contacts cannot prove they communicate with the same user.

- - A user protects their local database and key material.
- - The user's application is authentic, and no local malware is running.
- - The cryptographic primitives in use are not broken.
- - A user's choice of servers is not directly tied to their identity or otherwise represents distinguishing information about the user.
- - The user's client uses 2-hop onion message routing.
+- **Sender deniability** — neither routers nor recipients can cryptographically prove message origin.

-#### A passive adversary able to monitor the traffic of one user
+- **Transport metadata protection** — fixed-size blocks, 2-hop onion routing, and optional connection isolation frustrate traffic correlation.

-*can:*
-
- - identify that and when a user is using SimpleX.
-
- - determine which servers the user receives the messages from.
-
- - observe how much traffic is being sent, and make guesses as to its purpose.
-
-*cannot:*
-
- - see who sends messages to the user and who the user sends the messages to.
-
- - determine the servers used by users' contacts.
-
-#### A passive adversary able to monitor a set of senders and recipients
-
- *can:*
-
- - identify who and when is using SimpleX.
-
- - learn which SimpleX Messaging Protocol servers are used as receive queues for which users.
-
- - learn when messages are sent and received.
-
- - perform traffic correlation attacks against senders and recipients and correlate senders and recipients within the monitored set, frustrated by the number of users on the servers.
-
- - observe how much traffic is being sent, and make guesses as to its purpose
-
-*cannot, even in case of a compromised transport protocol:*
-
- - perform traffic correlation attacks with any increase in efficiency over a non-compromised transport protocol
-
-#### SimpleX Messaging Protocol server
-
-*can:*
-
- learn when a queue recipient is online
-
- know how many messages are sent via the queue (although some may be noise or not content messages).
-
- learn which messages would trigger notifications even if a user does not use [push notifications](./push-notifications.md).
-
- perform the correlation of the queue used to receive messages (matching multiple queues to a single user) via either a re-used transport connection, user's IP Address, or connection timing regularities.
-
- learn a recipient's IP address, track them through other IP addresses they use to access the same queue, and infer information (e.g. employer) based on the IP addresses, as long as Tor is not used.
-
- drop all future messages inserted into a queue, detectable only over other, redundant queues.
-
- lie about the state of a queue to the recipient and/or to the sender  (e.g. suspended or deleted when it is not).
-
- spam a user with invalid messages.
-
-*cannot:*
-
- undetectably add, duplicate, or corrupt individual messages.
-
- undetectably drop individual messages, so long as a subsequent message is delivered.
-
- learn the contents or type of messages.
-
- distinguish noise messages from regular messages except via timing regularities.
-
- compromise the users' end-to-end encryption with an active attack.
-
- learn a sender's IP address, track them through other IP addresses they use to access the same queue, and infer information (e.g. employer) based on the IP addresses, even if Tor is not used (provided messages are sent via proxy SMP server).
-
- perform senders' queue correlation (matching multiple queues to a single sender) via either a re-used transport connection, user's IP Address, or connection timing regularities, unless it has additional information from the proxy SMP server (provided messages are sent via proxy SMP server).
-
-#### SimpleX Messaging Protocol server that proxies the messages to another SMP server
-
-*can:*
-
- learn a sender's IP address, as long as Tor is not used.
-
- learn when a sender with a given IP address is online.
-
- know how many messages are sent from a given IP address and to a given destination SMP server.
-
- drop all messages from a given IP address or to a given destination server.
-
- unless destination SMP server detects repeated public DH keys of senders, replay messages to a destination server within a single session, causing either duplicate message delivery (which will be detected and ignored by the receiving clients), or, when receiving client is not connected to SMP server, exhausting capacity of destination queues used within the session.
-
-*cannot:*
-
- perform queue correlation (matching multiple queues to a single user), unless it has additional information from the destination SMP server.
-
- undetectably add, duplicate, or corrupt individual messages.
-
- undetectably drop individual messages, so long as a subsequent message is delivered.
-
- learn the contents or type of messages.
-
- learn which messages would trigger notifications.
-
- learn the destination queues of messages.
-
- distinguish noise messages from regular messages except via timing regularities.
-
- compromise the user's end-to-end encryption with another user via an active attack.
-
- compromise the user's end-to-end encryption with the destination SMP servers via an active attack.
-
-#### An attacker who obtained Alice's (decrypted) chat database
-
-*can:*
-
- see the history of all messages exchanged by Alice with her communication partners.
-
- see shared profiles of contacts and groups.
-
- surreptitiously receive new messages sent to Alice via existing queues; until communication queues are rotated or the Double-Ratchet advances forward.
-
- prevent Alice from receiving all new messages sent to her - either surreptitiously by emptying the queues regularly or overtly by deleting them.
-
- send messages from the user to their contacts; recipients will detect it as soon as the user sends the next message, because the previous message hash won’t match (and potentially won’t be able to decrypt them in case they don’t keep the previous ratchet keys).
-
-*cannot:*
-
- impersonate a sender and send messages to the user whose database was stolen. Doing so requires also compromising the server (to place the message in the queue, that is possible until the Double-Ratchet advances forward) or the user's device at a subsequent time (to place the message in the database).
-
- undetectably communicate at the same time as Alice with her contacts. Doing so would result in the contact getting different messages with repeated IDs.
-
- undetectably monitor message queues in realtime without alerting the user they are doing so, as a second subscription request unsubscribes the first and notifies the second.
-
-#### A user’s contact
-
-*can:*
-
- spam the user with messages.
-
- forever retain messages from the user.
-
-*cannot:*
-
- cryptographically prove to a third-party that a message came from a user (assuming the user’s device is not seized).
-
- prove that two contacts they have is the same user.
-
- cannot collaborate with another of the user's contacts to confirm they are communicating with the same user.
-
-#### An attacker who observes Alice showing an introduction message to Bob
-
-*can:*
-
- - Impersonate Bob to Alice.
-
-*cannot:*
-
- - Impersonate Alice to Bob.
-
-#### An attacker with Internet access
-
-*can:*
-
- Denial of Service SimpleX messaging servers.
-
- spam a user's public “contact queue” with connection requests.
-
-*cannot:*
-
- send messages to a user who they are not connected with.
-
- enumerate queues on a SimpleX server.
+- **Out-of-band key exchange** — connection requests passed outside the network protect against MITM attacks.


 ## Acknowledgements
@@ -13,6 +13,11 @@ Version 1, 2024-06-22
  - [Initialization](#initialization)
  - [Encrypting messages](#encrypting-messages)
  - [Decrypting messages](#decrypting-messages)
+- [Ratchet message wire format](#ratchet-message-wire-format)
+  - [Encrypted ratchet message](#encrypted-ratchet-message)
+  - [Encrypted message header](#encrypted-message-header)
+  - [Plaintext message header](#plaintext-message-header)
+  - [KEM state machine](#kem-state-machine)
 - [Implementation considerations](#implementation-considerations)
 - [Chosen KEM algorithm](#chosen-kem-algorithm)
 - [Summary](#summary)
@@ -71,11 +76,10 @@ def RatchetInitAlicePQ2HE(state, SK, bob_dh_public_key, shared_hka, shared_nhkb,
    // below added for post-quantum KEM
    state.PQRs = GENERATE_PQKEM()
    state.PQRr = bob_pq_kem_encapsulation_key
-    state.PQRss = random // shared secret for KEM
-    state.PQRct = PQKEM-ENC(state.PQRr, state.PQRss) // encapsulated additional shared secret
+    state.PQRct, state.PQRss = PQKEM-ENC(state.PQRr) // encapsulate: generates shared secret and ciphertext
    // above added for KEM
    // the next line augments DH key agreement with PQ shared secret
-    state.RK, state.CKs, state.NHKs = KDF_RK_HE(SK, DH(state.DHRs, state.DHRr) || state.PQRss) 
+    state.RK, state.CKs, state.NHKs = KDF_RK_HE(SK, DH(state.DHRs, state.DHRr) || state.PQRss)
    state.CKr = None
    state.Ns = 0
    state.Nr = 0
@@ -176,8 +180,7 @@ def DHRatchetPQ2HE(state, header):
    state.DHRs = GENERATE_DH()
    // below is added for KEM
    state.PQRs = GENERATE_PQKEM() // generate new PQ key pair
-    state.PQRss = random // shared secret for KEM
-    state.PQRct = PQKEM-ENC(state.PQRr, state.PQRss) // encapsulated additional shared secret KEM #1
+    state.PQRct, state.PQRss = PQKEM-ENC(state.PQRr) // encapsulate: generates shared secret and ciphertext KEM #1
    // above is added for KEM
    // use new shared secret with sending ratchet
    state.RK, state.CKs, state.NHKs = KDF_RK_HE(state.RK, DH(state.DHRs, state.DHRr) || state.PQRss)
@@ -191,6 +194,80 @@ Other than augmenting DH key agreements with the shared secrets from KEM, the ab

 It is worth noting that while DH agreements work as ping-pong, when the new received DH key is used for both DH agreements (and only the sent DH key is updated for the second DH key agreement), PQ KEM agreements in the proposed scheme work as a "parallel ping-pong", with two balls in play all the time (two KEM agreements run in parallel).

+## Ratchet message wire format
+
+The pseudocode above describes the algorithm. This section specifies the actual binary encoding used in SimpleX implementation with Curve448 DH keys, sntrup761 KEM and AES-256-GCM AEAD.
+
+The ratchet-encrypted message has three encoding layers, from outermost to innermost:
+
+1. **Encrypted ratchet message** — the complete ratchet message envelope, referenced as an opaque encrypted body in [agent protocol](./agent-protocol.md).
+2. **Encrypted message header** — the encrypted header within the ratchet message, used as associated data for message body encryption.
+3. **Plaintext message header** — the DH and KEM ratchet keys and counters.
+
+### Encrypted ratchet message
+
+The outer envelope contains the encrypted header (used as associated data for body authentication), the body authentication tag, and the encrypted message body.
+
+The message body is encrypted with AES-256-GCM using the message key derived from the sending chain key (`KDF_CK`). The associated data for body encryption is the concatenation of the ratchet associated data and the encoded encrypted header.
+
+```abnf
+encRatchetMessage = versionedLength encMessageHeader msgAuthTag encMsgBody
+; encMessageHeader is used as associated data for body decryption: AD = rcAD || encMessageHeader
+msgAuthTag = 16*16 OCTET ; AES-256-GCM authentication tag for the message body
+encMsgBody = *OCTET ; AES-256-GCM encrypted padded message body (remaining bytes)
+```
+
+### Encrypted message header
+
+The encrypted header wraps the current ratchet e2e encryption version, an initialization vector, an authentication tag, and the encrypted padded header body.
+
+The header body is encrypted with AES-256-GCM using the header key (`HKs`). The associated data for header encryption is the ratchet associated data. The header is padded before encryption to a fixed size to prevent leaking information about the KEM state.
+
+```abnf
+encMessageHeader = currentVersion headerIV headerAuthTag versionedLength encHeaderBody
+currentVersion = 2*2 OCTET ; Word16, current ratchet e2e encryption version
+headerIV = 16*16 OCTET ; AES-256 initialization vector for header encryption
+headerAuthTag = 16*16 OCTET ; AES-256-GCM authentication tag for the header
+encHeaderBody = *OCTET ; AES-256-GCM encrypted padded header (see plaintext format below)
+```
+
+`versionedLength` uses a 2-byte length prefix (Word16) when the current e2e version supports PQ encryption, or a 1-byte length prefix otherwise. The parser distinguishes the two encodings by peeking at the first byte: values below 32 indicate a 2-byte prefix (as the header is always at least 69 bytes).
+
+```abnf
+versionedLength = largeLength / length ; 2-byte for PQ versions, 1-byte for pre-PQ versions
+```
+
+The padded header sizes before encryption are: 2310 bytes when PQ is supported, 88 bytes when PQ is not supported. Padding uses a 2-byte big-endian length prefix followed by the plaintext header and `#` fill bytes.
+
+### Plaintext message header
+
+```abnf
+msgHeader = maxVersion dhPublicKey [kemParams] prevMsgCount msgCount
+maxVersion = 2*2 OCTET ; Word16, max supported e2e encryption version
+dhPublicKey = length x509encoded ; Curve448 public DH ratchet key
+kemParams = noKEM / proposedKEM / acceptedKEM
+  ; present only when current ratchet version >= pqRatchetE2EEncryptVersion
+noKEM = %x30 ; "0" - no KEM parameters
+proposedKEM = %x31 %s"P" kemEncapsulationKey ; KEM proposed, not yet accepted
+acceptedKEM = %x31 %s"A" kemCiphertext kemEncapsulationKey ; KEM accepted
+kemEncapsulationKey = largeLength 1158*1158 OCTET ; sntrup761 encapsulation key
+kemCiphertext = largeLength 1039*1039 OCTET ; sntrup761 ciphertext
+prevMsgCount = 4*4 OCTET ; Word32, number of messages in previous sending chain
+msgCount = 4*4 OCTET ; Word32, message number in current sending chain
+length = 1*1 OCTET
+largeLength = 2*2 OCTET ; Word16
+```
+
+### KEM state machine
+
+PQ encryption can be enabled or disabled during a connection's lifetime. The KEM parameters in the header reflect three states:
+
+- **No KEM** (`noKEM`): PQ encryption is not active. The header contains only the DH key, as in the original double ratchet.
+- **Proposed** (`proposedKEM`): One party generated a KEM key pair and includes the encapsulation key in the header, proposing PQ encryption. No ciphertext is included because the other party has not yet sent its encapsulation key.
+- **Accepted** (`acceptedKEM`): The party received the other's encapsulation key, performed encapsulation (KEM #1), and includes both the ciphertext and its own new encapsulation key (for KEM #2). This is the steady state for active PQ encryption.
+
+The transition from Proposed to Accepted happens when a party receives a message containing KEM parameters (either Proposed or Accepted) and responds with its own Accepted parameters. Once both parties are in Accepted state, the double PQ KEM augmentation described in the algorithm above operates in each DH ratchet step.
+
 ## Implementation considerations for SimpleX Messaging Protocol

 As SimpleX Messaging Protocol pads messages to a fixed size, using 16kb transport blocks, the size increase introduced by this scheme can be compensated for by using ZSTD encryption of JSON bodies and image previews encoded as base64. While there may be some rare cases of random texts that would fail to compress, in all real scenarios it would not cause the message size reduction.
@@ -1,14 +1,19 @@
-Version 2, 2024-06-22
+Version 3, 2025-01-24

-# Overview of push notifications for SimpleX Messaging Servers
+# Overview of push notifications for SimpleX Messaging Routers
+
+This document describes Notification Router protocol version 3. Version history:
+- v1: initial version
+- v2: authenticated commands, command batching
+- v3: detailed invalid token reason

 ## Table of contents

 - [Introduction](#introduction)
- [Participating servers](#participating-servers)
+- [Participating routers](#participating-routers)
 - [Register device token to receive push notifications](#register-device-token-to-receive-push-notifications)
 - [Subscribe to connection notifications](#subscribe-to-connection-notifications)
- [SimpleX Notification Server protocol](#simplex-notification-server-protocol)
+- [SimpleX Notification Router protocol](#simplex-notification-router-protocol)
  - [Register new notification token](#register-new-notification-token)
  - [Verify notification token](#verify-notification-token)
  - [Check notification token status](#check-notification-token-status)
@@ -23,35 +28,35 @@ Version 2, 2024-06-22

 ## Introduction

-SimpleX Messaging servers already operate as push servers and deliver the messages to subscribed clients as soon as they are sent to the servers.
+SimpleX Messaging routers already operate as push routers and deliver the messages to subscribed clients as soon as they are sent to the routers.

 The reason for push notifications is to support instant message notifications on iOS that does not allow background services.

-## Participating servers
+## Participating routers

-The diagram below shows which servers participate in message notification delivery.
+The diagram below shows which routers participate in message notification delivery.

-While push provider (e.g., APN) can learn how many notifications are delivered to the user, it cannot access message content, even encrypted, or any message metadata - the notifications are e2e encrypted between SimpleX Notification Server and the user's device.
+While push provider (e.g., APN) can learn how many notifications are delivered to the user, it cannot access message content, even encrypted, or any message metadata - the notifications are e2e encrypted between SimpleX Notification Router and the user's device.

 ```
-  User's iOS device                Internet                           Servers
+  User's iOS device                Internet                           Routers
 ---------------------   .   ------------------------   .   -----------------------------
                        .                              .
                        .                              .       can be self-hosted now
 +--------------+        .                              .         +----------------+
 | SimpleX Chat |       -------------- TLS ---------------        | SimpleX        |
 |    client    |------> SimpleX Messaging Protocol (SMP) ------> | Messaging      |
-+--------------+       ----------------------------------        | Server         |
+--------------+       ----------------------------------        | Router         |
     ^    |             .                              .         +----------------+
     |    |             .                              .          . . .  |   . . .
     |    |             .                              .               | V |
     |    |             .                              .               |SMP| TLS
     |    |             .                              .               | | |               SimpleX
-     |    |             .                              .          . . .  V   . . .      NTF Server
+     |    |             .                              .          . . .  V   . . .      NTF Router
     |    |             .                              .       +----------------------------------+
     |    |             .                              .       | +---------------+                |
     |    |            -------------- TLS ---------------      | | SimpleX       | can be         | 
-     |    |----------->   Notification Server Protocol  -----> | | Notifications | self-hosted    |
+     |    |----------->   Notification Router Protocol  -----> | | Notifications | self-hosted    |
     |                 ----------------------------------      | | Subscriber    | in the future  |
     |                  .                              .       | +---------------+                |
     |                  .                              .       |         |                        |
@@ -59,7 +64,7 @@ While push provider (e.g., APN) can learn how many notifications are delivered t
     |                  .                              .       | +---------------+                |
     |                  .                              .       | | SimpleX       |                |
     |                  .                              .       | | Push          |                |
-     |                  .                              .       | | Server        |                |
+     |                  .                              .       | | Router        |                |
     |                  .                              .       | +---------------+                |
     |                  .                              .       +----------------------------------+
     |                  .                              .          . . .  |   . . .
@@ -85,25 +90,28 @@ This diagram shows the process of subscription to notifications, notification de

 ![Subscribe to notifications](./diagrams/notifications/subscription.svg)

-## SimpleX Notification Server protocol
+## SimpleX Notification Router protocol

-To manage notification subscriptions to SMP servers, SimpleX Notification Server provides an RPC protocol with a similar design to SimpleX Messaging Protocol server.
+To manage notification subscriptions to SMP routers, SimpleX Notification Router provides an RPC protocol with a similar design to SimpleX Messaging Protocol router.

-This protocol sends requests and responses in a fixed size blocks of 512 bytes over TLS, uses the same [syntax of protocol transmissions](./simplex-messaging.md#smp-transmission-and-transport-block-structure) as SMP protocol, and has the same transport [handshake syntax](./simplex-messaging.md#transport-handshake) (except the server certificate is not included in the handshake).
+This protocol sends requests and responses in a fixed size blocks of 512 bytes over TLS, uses the same [syntax of protocol transmissions](./simplex-messaging.md#smp-transmission-and-transport-block-structure) as SMP protocol, and has the same transport [handshake syntax](./simplex-messaging.md#transport-handshake) (except the router certificate is not included in the handshake).
+
+The client and router use ALPN extension with `ntf/1` protocol name to agree handshake version.

 Protocol commands have this syntax:

-```
-ntfServerTransmission = 
-ntfServerCmd = newTokenCmd / verifyTokenCmd / checkTokenCmd /
+```abnf
+ntfRouterTransmission = authorization corrId entityId ntfRouterCmd
+  ; same transmission structure as SMP, see simplex-messaging.md
+ntfRouterCmd = newTokenCmd / verifyTokenCmd / checkTokenCmd /
               replaceTokenCmd / deleteTokenCmd / cronCmd /
-               newSubCmd / checkSubCmd / deleteSubCmd
+               newSubCmd / checkSubCmd / deleteSubCmd / pingCmd
 ```
 ### Register new notification token

-This command should be used after the client app obtains a token from push notifications provider to register the token with the server.
+This command should be used after the client app obtains a token from push notifications provider to register the token with the router.

-Having received this command the server will deliver a test notification via the push provider to validate that the client has this token.
+Having received this command the router will deliver a test notification via the push provider to validate that the client has this token.

 The command syntax:

@@ -111,23 +119,24 @@ The command syntax:
 newTokenCmd = %s"TNEW" SP newToken
 newToken = %s"T" deviceToken authPubKey clientDhPubKey
 deviceToken = pushProvider tokenString
-pushProvider = apnsDev / apnsProd / apnsNull
+pushProvider = apnsDev / apnsProd / apnsTest / apnsNull
 apnsDev = "AD" ; APNS token for development environment
 apnsProd = "AP" ; APNS token for production environment
-apnsNull = "AN" ; token that does not trigger any notification delivery - used for server testing
+apnsTest = "AT" ; APNS token for test environment (mock server)
+apnsNull = "AN" ; token that does not trigger any notification delivery - used for router testing
 tokenString = shortString
 authPubKey = length x509encoded ; Ed25519 key used to verify clients commands
-clientDhPubKey = length x509encoded ; X25519 key to agree e2e encryption between the server and client
+clientDhPubKey = length x509encoded ; X25519 key to agree e2e encryption between the router and client
 shortString = length *OCTET
 length = 1*1 OCTET
 ```

-The server response syntax:
+The router response syntax:

 ```abnf
-tokenIdResp = %s"IDTKN" SP entityId serverDhPubKey
+tokenIdResp = %s"IDTKN" SP entityId routerDhPubKey
 entityId = shortString
-serverDhPubKey = length x509encoded ; X25519 key to agree e2e encryption between the server and client
+routerDhPubKey = length x509encoded ; X25519 key to agree e2e encryption between the router and client
 ```

 ### Verify notification token
@@ -159,7 +168,9 @@ The response to this command:

 ```abnf
 tokenStatusResp = %s"TKN" SP tokenStatus
-tokenStatus = %s"NEW" / %s"REGISTERED" / %s"INVALID" / %s"CONFIRMED" / %s"ACTIVE" / %s"EXPIRED"
+tokenStatus = %s"NEW" / %s"REGISTERED" / tokenInvalid / %s"CONFIRMED" / %s"ACTIVE" / %s"EXPIRED"
+tokenInvalid = %s"INVALID" ["," invalidReason] ; optional reason added in v3
+invalidReason = %s"BAD" / %s"TOPIC" / %s"EXPIRED" / %s"UNREGISTERED"
 ```

 ### Replace notification token
@@ -200,8 +211,8 @@ After this command all message notification subscriptions will be removed and no
 This command enables or disables periodic notifications sent to the client device irrespective of message notifications.

 This is useful for two reasons:
- it provides better privacy from notification server, as while the server learns the device token, it doesn't learn anything else about user communications.
- it allows to receive messages when notifications were dropped by push provider, e.g. while the device was offline, or lost by notification server, e.g. while it was restarting.
+- it provides better privacy from notification router, as while the router learns the device token, it doesn't learn anything else about user communications.
+- it allows to receive messages when notifications were dropped by push provider, e.g. while the device was offline, or lost by notification router, e.g. while it was restarting.

 The command syntax:

@@ -214,18 +225,18 @@ The interval for periodic notifications is set in minutes, with the minimum of 2

 ### Create SMP message notification subscription

-This command makes notification server subscribe to message notifications from SMP server and to deliver them to push provider:
+This command makes notification router subscribe to message notifications from SMP router and to deliver them to push provider:

 ```abnf
-newSubCmd = %s"SNEW" newSub
-newSub = %s "S" tokenId smpServer notifierId notifierKey
+newSubCmd = %s"SNEW" SP newSub
+newSub = %s"S" tokenId smpRouter notifierId notifierKey
 tokenId = shortString ; returned in response to `TNEW` command
-smpServer = smpServer = hosts port fingerprint
+smpRouter = hosts port fingerprint
 hosts = length 1*host
 host = shortString
 port = shortString
 fingerprint = shortString
-notifierId = shortString ; returned by SMP server in response to `NKEY` SMP command
+notifierId = shortString ; returned by SMP router in response to `NKEY` SMP command
 notifierKey = length x509encoded ; private key used to authorize requests to subscribe to message notifications
 ```

@@ -247,10 +258,10 @@ The response:

 ```abnf
 subStatusResp = %s"SUB" SP subStatus
-subStatus = %s"NEW" / %s"PENDING" / ; e.g., after SMP server disconnect/timeout while ntf server is retrying to connect
-            %s"ACTIVE" / %s"INACTIVE" / %s"END" / ; if another server subscribed to notifications
-            %s"AUTH" / subErrStatus
-subErrStatus = %s"ERR" SP shortString
+subStatus = %s"NEW" / %s"PENDING" / ; e.g., after SMP router disconnect/timeout while ntf router is retrying to connect
+            %s"ACTIVE" / %s"INACTIVE" / %s"END" / ; if another router subscribed to notifications
+            %s"AUTH" / %s"DELETED" / %s"SERVICE" / subErrStatus
+subErrStatus = %s"ERR" SP *OCTET
 ```

 ### Delete notification subscription
@@ -265,6 +276,17 @@ The response to this command is `okResp` or `errorResp`.

 After this command no more message notifications will be sent from this queue.

+### Keep-alive command
+
+To keep the transport connection alive the clients should use `PING` command:
+
+```abnf
+pingCmd = %s"PING"
+pongResp = %s"PONG"
+```
+
+This command is sent unsigned and without entity ID.
+
 ### Error responses

 All commands can return error response:
@@ -277,7 +299,7 @@ Where `errorType` has the same syntax as in [SimpleX Messaging Protocol](./simpl

 ## Threat Model

-This threat model compliments SimpleX Messaging Protocol [threat model](./overview-tjr.md#threat-model)
+This threat model compliments SimpleX Messaging Protocol [threat model](./security.md#threat-model)

 #### A passive adversary able to monitor the traffic of one user

@@ -287,21 +309,21 @@ This threat model compliments SimpleX Messaging Protocol [threat model](./overvi

 *cannot:*

- - determine which servers a user subscribed to the notifications from.
+ - determine which routers a user subscribed to the notifications from.

 #### A passive adversary able to monitor a set of senders and recipients

 *can:*

- - perform more efficient traffic correlation attacks against senders and recipients and correlate senders and recipients within the monitored set, frustrated by the number of users on the servers.
+ - perform more efficient traffic correlation attacks against senders and recipients and correlate senders and recipients within the monitored set, frustrated by the number of users on the routers.

-#### SimpleX Messaging Protocol server
+#### SimpleX Messaging Protocol router

 *can:*

 - learn which messages trigger push notifications.

- learn IP address of SimpleX notification servers used by the user.
+- learn IP address of SimpleX notification routers used by the user.

 - drop message notifications.

@@ -313,13 +335,13 @@ This threat model compliments SimpleX Messaging Protocol [threat model](./overvi

 - learn which queues belong to the same users with any additional efficiency compared with not using push notifications.

-#### SimpleX Notification Server subscribed to message notifications
+#### SimpleX Notification Router subscribed to message notifications

 *can:*

 - learn a user device token.

- learn how many messaging queues and servers a user receives messages from.
+- learn how many messaging queues and routers a user receives messages from.

 - learn how many message notifications are delivered to the user from each queue.

@@ -339,7 +361,7 @@ This threat model compliments SimpleX Messaging Protocol [threat model](./overvi

 - add, duplicate, or corrupt individual messages that will be shown to the user.

-#### SimpleX Notification Server subscribed ONLY to periodic notifications
+#### SimpleX Notification Router subscribed ONLY to periodic notifications

 *can:*

@@ -351,7 +373,7 @@ This threat model compliments SimpleX Messaging Protocol [threat model](./overvi

 *cannot:*

- learn how many messaging queues and servers a user receives messages from.
+- learn how many messaging queues and routers a user receives messages from.

 - learn how many message notifications are delivered to the user from each queue.

@@ -383,7 +405,7 @@ This threat model compliments SimpleX Messaging Protocol [threat model](./overvi

 *cannot:*

- learn which SimpleX Messaging Protocol servers are used by a user (notifications are e2e encrypted).
+- learn which SimpleX Messaging Protocol routers are used by a user (notifications are e2e encrypted).

 - learn which or how many messaging queues a user receives notifications from.

@@ -395,4 +417,4 @@ This threat model compliments SimpleX Messaging Protocol [threat model](./overvi

 - register notification token not present on attacker's device.

- enumerate tokens or subscriptions on a SimpleX Notification Server.
+- enumerate tokens or subscriptions on a SimpleX Notification Router.
@@ -0,0 +1,215 @@
+Revision 1, 2026-03-09
+
+# SimpleX Network: Security
+
+This document describes the cryptographic primitives and threat model for the SimpleX network. For a general introduction, see [SimpleX: messaging and application platform](./overview-tjr.md).
+
+## Table of contents
+
+- [Encryption primitives](#encryption-primitives)
+- [Threat model](#threat-model)
+  - [Global Assumptions](#global-assumptions)
+  - [A passive adversary able to monitor the traffic of one user](#a-passive-adversary-able-to-monitor-the-traffic-of-one-user)
+  - [A passive adversary able to monitor a set of senders and recipients](#a-passive-adversary-able-to-monitor-a-set-of-senders-and-recipients)
+  - [SimpleX Messaging Protocol router](#simplex-messaging-protocol-router)
+  - [SimpleX Messaging Protocol router that proxies the messages to another SMP router](#simplex-messaging-protocol-router-that-proxies-the-messages-to-another-smp-router)
+  - [An attacker who obtained Alice's (decrypted) chat database](#an-attacker-who-obtained-alices-decrypted-chat-database)
+  - [A user's contact](#a-users-contact)
+  - [An attacker who observes Alice showing an introduction message to Bob](#an-attacker-who-observes-alice-showing-an-introduction-message-to-bob)
+  - [An attacker with Internet access](#an-attacker-with-internet-access)
+
+
+## Encryption primitives
+
+- **Router command authorization**: X25519 DH-based authenticated encryption (SMP v7+), providing sender deniability. Ed25519 signatures used for recipient commands and notifier commands.
+
+- **Per-queue key agreement**: Curve25519 DH exchange to agree:
+  - the shared secret between router and recipient (to encrypt message bodies — avoids shared ciphertext in sender and recipient traffic),
+  - the shared secret between sender and recipient (to encrypt messages end-to-end in each queue — avoids shared ciphertext in redundant queues).
+
+- **SMP-layer encryption**: [NaCl crypto_box](https://nacl.cr.yp.to/box.html) (curve25519xsalsa20poly1305) for message body encryption between router and recipient, and for e2e per-queue encryption.
+
+- **Certificate validation**: SHA256 to validate router offline certificates.
+
+- **End-to-end encryption**: [Double ratchet](https://signal.org/docs/specifications/doubleratchet/) protocol:
+  - Curve448 keys for shared secret agreement via [X3DH](https://signal.org/docs/specifications/x3dh/) with 2 ephemeral keys per side,
+  - optional [SNTRUP761](https://ntruprime.cr.yp.to/) post-quantum KEM running in parallel with the DH ratchet (see [PQDR](./pqdr.md)), providing post-quantum forward secrecy,
+  - AES-GCM AEAD cipher,
+  - SHA512-based HKDF for key derivation.
+
+
+## Threat Model
+
+### Global Assumptions
+
+- A user protects their local database and key material.
+- The user's application is authentic, and no local malware is running.
+- The cryptographic primitives in use are not broken.
+- A user's choice of routers is not directly tied to their identity or otherwise represents distinguishing information about the user.
+- The user's client uses 2-hop onion message routing.
+
+### A passive adversary able to monitor the traffic of one user
+
+*can:*
+
+- identify that and when a user is using SimpleX.
+
+- determine which routers the user receives messages from.
+
+- observe how much traffic is being sent, and make guesses as to its purpose.
+
+*cannot:*
+
+- see who sends messages to the user and who the user sends messages to.
+
+- determine the routers used by users' contacts.
+
+### A passive adversary able to monitor a set of senders and recipients
+
+*can:*
+
+- identify who and when is using SimpleX.
+
+- learn which SimpleX Messaging Protocol routers are used as receive queues for which users.
+
+- learn when messages are sent and received.
+
+- perform traffic correlation attacks against senders and recipients and correlate senders and recipients within the monitored set, frustrated by the number of users on the routers.
+
+- observe how much traffic is being sent, and make guesses as to its purpose.
+
+*cannot, even in case of a compromised transport protocol:*
+
+- perform traffic correlation attacks with any increase in efficiency over a non-compromised transport protocol.
+
+### SimpleX Messaging Protocol router
+
+*can:*
+
+- learn when a queue recipient is online.
+
+- know how many messages are sent via the queue (although some may be noise or not content messages).
+
+- learn which messages would trigger notifications even if a user does not use [push notifications](./push-notifications.md).
+
+- perform the correlation of the queue used to receive messages (matching multiple queues to a single user) via either a re-used transport connection, user's IP Address, or connection timing regularities.
+
+- learn a recipient's IP address, track them through other IP addresses they use to access the same queue, and infer information (e.g. employer) based on the IP addresses, as long as Tor is not used.
+
+- drop all future messages inserted into a queue, detectable only over other, redundant queues.
+
+- lie about the state of a queue to the recipient and/or to the sender  (e.g. suspended or deleted when it is not).
+
+- spam a user with invalid messages.
+
+*cannot:*
+
+- undetectably add, duplicate, or corrupt individual messages.
+
+- undetectably drop individual messages, so long as a subsequent message is delivered.
+
+- learn the contents or type of messages.
+
+- distinguish noise messages from regular messages except via timing regularities.
+
+- compromise the users' end-to-end encryption with an active attack.
+
+- learn a sender's IP address, track them through other IP addresses they use to access the same queue, and infer information (e.g. employer) based on the IP addresses, even if Tor is not used (provided messages are sent via proxy SMP router).
+
+- perform senders' queue correlation (matching multiple queues to a single sender) via either a re-used transport connection, user's IP Address, or connection timing regularities, unless it has additional information from the proxy SMP router (provided messages are sent via proxy SMP router).
+
+### SimpleX Messaging Protocol router that proxies the messages to another SMP router
+
+*can:*
+
+- learn a sender's IP address, as long as Tor is not used.
+
+- learn when a sender with a given IP address is online.
+
+- know how many messages are sent from a given IP address and to a given destination SMP router.
+
+- drop all messages from a given IP address or to a given destination router.
+
+- unless destination SMP router detects repeated public DH keys of senders, replay messages to a destination router within a single session, causing either duplicate message delivery (which will be detected and ignored by the receiving clients), or, when receiving client is not connected to SMP router, exhausting capacity of destination queues used within the session.
+
+*cannot:*
+
+- perform queue correlation (matching multiple queues to a single user), unless it has additional information from the destination SMP router.
+
+- undetectably add, duplicate, or corrupt individual messages.
+
+- undetectably drop individual messages, so long as a subsequent message is delivered.
+
+- learn the contents or type of messages.
+
+- learn which messages would trigger notifications.
+
+- learn the destination queues of messages.
+
+- distinguish noise messages from regular messages except via timing regularities.
+
+- compromise the user's end-to-end encryption with another user via an active attack.
+
+- compromise the user's end-to-end encryption with the destination SMP routers via an active attack.
+
+### An attacker who obtained Alice's (decrypted) chat database
+
+*can:*
+
+- see the history of all messages exchanged by Alice with her communication partners.
+
+- see shared profiles of contacts and groups.
+
+- surreptitiously receive new messages sent to Alice via existing queues; until communication queues are rotated or the Double-Ratchet advances forward.
+
+- prevent Alice from receiving all new messages sent to her - either surreptitiously by emptying the queues regularly or overtly by deleting them.
+
+- send messages from the user to their contacts; recipients will detect it as soon as the user sends the next message, because the previous message hash won't match (and potentially won't be able to decrypt them in case they don't keep the previous ratchet keys).
+
+*cannot:*
+
+- impersonate a sender and send messages to the user whose database was stolen. Doing so requires also compromising the router (to place the message in the queue, that is possible until the Double-Ratchet advances forward) or the user's device at a subsequent time (to place the message in the database).
+
+- undetectably communicate at the same time as Alice with her contacts. Doing so would result in the contact getting different messages with repeated IDs.
+
+- undetectably monitor message queues in realtime without alerting the user they are doing so, as a second subscription request unsubscribes the first and notifies the first.
+
+### A user's contact
+
+*can:*
+
+- spam the user with messages.
+
+- forever retain messages from the user.
+
+*cannot:*
+
+- cryptographically prove to a third-party that a message came from a user (assuming the user's device is not seized).
+
+- prove that two contacts they have is the same user.
+
+- cannot collaborate with another of the user's contacts to confirm they are communicating with the same user.
+
+### An attacker who observes Alice showing an introduction message to Bob
+
+*can:*
+
+- Impersonate Bob to Alice.
+
+*cannot:*
+
+- Impersonate Alice to Bob.
+
+### An attacker with Internet access
+
+*can:*
+
+- Denial of Service SimpleX messaging routers.
+
+- spam a user's public "contact queue" with connection requests.
+
+*cannot:*
+
+- send messages to a user who they are not connected with.
+
+- enumerate queues on a SimpleX router.
@@ -1,4 +1,4 @@
-Version 2, 2024-06-22
+Version 3, 2025-01-24

 # SimpleX File Transfer Protocol

@@ -11,12 +11,12 @@ Version 2, 2024-06-22
 - [XFTP procedure](#xftp-procedure)
 - [File description](#file-description)
 - [URIs syntax](#uris-syntax)
-  - [XFTP server URI](#xftp-server-uri)
+  - [XFTP router URI](#xftp-router-uri)
  - [File description URI](#file-description-URI)
 - [XFTP qualities and features](#xftp-qualities-and-features)
 - [Cryptographic algorithms](#cryptographic-algorithms)
- [File chunk IDs](#file-chunk-ids)
- [Server security requirements](#server-security-requirements)
+- [Data packet IDs](#data-packet-ids)
+- [Router security requirements](#router-security-requirements)
 - [Transport protocol](#transport-protocol)
  - [TLS ALPN](#tls-alpn)
  - [Connection handshake](#connection-handshake)
@@ -26,13 +26,14 @@ Version 2, 2024-06-22
  - [Command authentication](#command-authentication)
  - [Keep-alive command](#keep-alive-command)
  - [File sender commands](#file-sender-commands)
-    - [Register new file chunk](#register-new-file-chunk)
-    - [Add file chunk recipients](#add-file-chunk-recipients)
-    - [Upload file chunk](#upload-file-chunk)
-    - [Delete file chunk](#delete-file-chunk)
+    - [Register new data packet](#register-new-data-packet)
+    - [Add data packet recipients](#add-data-packet-recipients)
+    - [Upload data packet](#upload-data-packet)
+    - [Delete data packet](#delete-data-packet)
  - [File recipient commands](#file-recipient-commands)
-    - [Download file chunk](#download-file-chunk)
-    - [Acknowledge file chunk download](#acknowledge-file-chunk-download)
+    - [Download data packet](#download-data-packet)
+    - [Acknowledge data packet download](#acknowledge-data-packet-download)
+  - [Error responses](#error-responses)
 - [Threat model](#threat-model)

 ## Abstract
@@ -45,23 +46,31 @@ It is designed as a application level protocol to solve the problem of secure an

 ## Introduction

-The objective of SimpleX File Transfer Protocol (XFTP) is to facilitate the secure and private unidirectional transfer of files from senders to recipients via persistent file chunks stored by the xftp server.
+The objective of SimpleX File Transfer Protocol (XFTP) is to facilitate the secure and private unidirectional transfer of files from senders to recipients via persistent data packets stored by the xftp router.

 XFTP is implemented as an application level protocol on top of HTTP2 and TLS.

-The protocol describes the set of commands that senders and recipients can send to XFTP servers to create, upload, download and delete file chunks of several pre-defined sizes. XFTP servers SHOULD support chunks of 4 sizes: 64KB, 256KB, 1MB and 4MB (1KB = 1024 bytes, 1MB = 1024KB).
+This document describes XFTP protocol version 3. The version history:

-The protocol is designed with the focus on meta-data privacy and security. While using TLS, the protocol does not rely on TLS security by using additional encryption to achieve that there are no identifiers or ciphertext in common in received and sent server traffic, frustrating traffic correlation even if TLS is compromised.
+- v1: initial version
+- v2: authenticated commands - added basic auth support for commands
+- v3: blocked files - added BLOCKED error type for policy violations

-XFTP does not use any form of participants' identities. It relies on out-of-band passing of "file description" - a human-readable YAML document with the list of file chunk locations, hashes and necessary cryptographic keys.
+The protocol describes the set of commands that senders and recipients can send to XFTP routers to create, upload, download and delete data packets of several pre-defined sizes. XFTP routers SHOULD support packets of 4 sizes: 64KB, 256KB, 1MB and 4MB (1KB = 1024 bytes, 1MB = 1024KB).
+
+The protocol is designed with the focus on meta-data privacy and security. While using TLS, the protocol does not rely on TLS security by using additional encryption to achieve that there are no identifiers or ciphertext in common in received and sent router traffic, frustrating traffic correlation even if TLS is compromised.
+
+XFTP does not use any form of participants' identities. It relies on out-of-band passing of "file description" - a human-readable YAML document with the list of data packet locations, hashes and necessary cryptographic keys.
+
+> **Note:** While this protocol was originally designed for file transfer, it handles generic addressed data packets. File-specific semantics (splitting files into packets, assembly, naming) are application-level concerns defined in the [agent protocol](./agent-protocol.md).

 ## XFTP Model

-The XFTP model has three communication participants: the recipient, the file server (XFTP server) that is chosen and, possibly, controlled by the sender, and the sender.
+The XFTP model has three communication participants: the recipient, the XFTP router that is chosen and, possibly, controlled by the sender, and the sender.

-XFTP server allows uploading fixed size file chunks, with or without basic authentication. The same party that can be the sender of one file chunk can be the recipient of another, without exposing it to the server.
+XFTP router allows uploading fixed size data packets, with or without basic authentication. The same party that can be the sender of one data packet can be the recipient of another, without exposing it to the router.

-Each file chunk allows multiple recipients, each recipient can download the same chunk multiple times. It allows depending on the threat model use the same recipient credentials for multiple parties, thus reducing server ability to understand the number of intended recipients (but server can still track IP addresses to determine it), or use one unique set of credentials for each recipient, frustrating traffic correlation on the assumption of compromised TLS. In the latter case, senders can create a larger number of recipient credentials to hide the actual number of intended recipients from the servers (which is what SimpleX clients do).
+Each data packet allows multiple recipients, each recipient can download the same packet multiple times. It allows depending on the threat model use the same recipient credentials for multiple parties, thus reducing router ability to understand the number of intended recipients (but router can still track IP addresses to determine it), or use one unique set of credentials for each recipient, frustrating traffic correlation on the assumption of compromised TLS. In the latter case, senders can create a larger number of recipient credentials to hide the actual number of intended recipients from the routers (which is what SimpleX clients do).

 ```
           Sender                      Internet                XFTP relays             Internet         Recipient
@@ -69,7 +78,7 @@ Each file chunk allows multiple recipients, each recipient can download the same
                               |                       |                         |                  |
                               |                       |   (can be self-hosted)  |                  |
                               |                       |        +---------+      |                  |
-                  chunk 1     ----- HTTP2 over TLS ------       |  XFTP   |     ---- HTTP2 / TLS -----   chunk 1
+                  packet 1     ----- HTTP2 over TLS ------       |  XFTP   |     ---- HTTP2 / TLS -----   packet 1
                |---> SimpleX File Transfer Protocol (XFTP) --> |  Relay  | --->        XFTP         ------------->|
                |             ---------------------------       +---------+     ----------------------             |
                |              |                       |                         |                  |              | 
@@ -83,21 +92,21 @@ file ---> |   XFTP   | ------>           XFTP            ---->  |  Relay  | --->
                |              |                       |        +---------+      |                  |              |
                |             ------- HTTP2 / TLS -------       |  XFTP   |     ---- HTTP2 / TLS ----              |
                |------------->           XFTP           ---->  |  Relay  | --->        XFTP         ------------->|
-                   chunk N    ---------------------------       +---------+     ---------------------    chunk N
-                               |                       |   (store file chunks)   |                  |
+                   packet N    ---------------------------       +---------+     ---------------------    packet N
+                               |                       |   (store data packets)   |                  |
                               |                       |                         |                  |
                               |                       |                         |                  |
 ```

-When sender client uploads a file chunk, it has to register it first with one sender ID and multiple recipient IDs, and one random unique key per ID to authenticate sender and recipients, and also provide its size and hash that will be validated when chunk is uploaded.
+When sender client uploads a data packet, it has to register it first with one sender ID and multiple recipient IDs, and one random unique key per ID to authenticate sender and recipients, and also provide its size and hash that will be validated when packet is uploaded.

-To send the actual file, the sender client MUST pad it and encrypt it with a random symmetric key and distribute chunks of fixed sized across multiple XFTP servers. Information about chunk locations, keys, hashes and required keys is passed to the recipients as "[file description](#file-description)" out-of-band.
+To send the actual file, the sender client MUST pad it and encrypt it with a random symmetric key and distribute packets of fixed sized across multiple XFTP routers. Information about packet locations, keys, hashes and required keys is passed to the recipients as "[file description](#file-description)" out-of-band.

-Creating, uploading, downloading and deleting file chunks requires sending commands to the XFTP server - they are described in detail in [XFTP commands](#xftp-commands) section.
+Creating, uploading, downloading and deleting data packets requires sending commands to the XFTP router - they are described in detail in [XFTP commands](#xftp-commands) section.

 ## Persistence model

-Server stores file chunk records in memory, with optional adding to append-only log, to allow restoring them on server restart. File chunk bodies can be stored as files or as objects in any object store (e.g. S3).
+Router stores data packet records in memory, with optional adding to append-only log, to allow restoring them on router restart. Data packet bodies can be stored as files or as objects in any object store (e.g. S3).

 ## XFTP procedure

@@ -107,28 +116,28 @@ To send the file, the sender will:

 1) Prepare file
  - compute its SHA512 digest.
-  - prepend header with the name and pad the file to match the whole number of chunks in size. It is RECOMMENDED to use 2 of 4 allowed chunk sizes, to balance upload size and metadata privacy.
+  - prepend header with the name and pad the file to match the whole number of packets in size. It is RECOMMENDED to use 2 of 4 allowed packet sizes, to balance upload size and metadata privacy.
  - encrypt it with a randomly chosen symmetric key and IV (e.g., using NaCL secret_box).
-  - split into allowed size chunks.
+  - split into allowed size packets.
  - generate per-recipient keys. It is recommended that the sending client generates more per-recipient keys than the actual number of recipients, rounding up to a power of 2, to conceal the actual number of intended recipients.

-2) Upload file chunks
-  - register each chunk record with randomly chosen one or more (for redundancy) XFTP server(s).
+2) Upload data packets
+  - register each packet record with randomly chosen one or more (for redundancy) XFTP router(s).
  - optionally request additional recipient IDs, if required number of recipient keys didn't fit into register request.
-  - upload each chunk to chosen server(s).
+  - upload each packet to chosen router(s).

 3) Prepare file descriptions, one per recipient.

-The sending client combines addresses of all chunks and other information into "file description", different for each file recipient, that will include:
+The sending client combines addresses of all packets and other information into "file description", different for each file recipient, that will include:

 - an encryption key used to encrypt/decrypt the full file (the same for all recipients).
 - file SHA512 digest to validate download.
- list of chunk descriptions; information for each chunk:
-  - private Ed25519 key to sign commands for file transfer server.
-  - chunk address (server host and chunk ID).
-  - chunk sha512 digest.
+- list of packet descriptions; information for each packet:
+  - private Ed25519 key to sign commands for file transfer router.
+  - packet address (router host and packet ID).
+  - packet sha256 digest.

-To reduce the size of file description, chunks are grouped by the server host.
+To reduce the size of file description, packets are grouped by the router host.

 4) Send file description(s) to the recipient(s) out-of-band, via pre-existing secure and authenticated channel. E.g., SimpleX clients send it as messages via SMP protocol, but it can be done via any other channel.

@@ -138,16 +147,16 @@ To reduce the size of file description, chunks are grouped by the server host.

 Having received the description, the recipient will:

-1) Download all chunks.
+1) Download all packets.

-The receiving client can fall back to secondary servers, if necessary:
- if the server is not available.
- if the chunk is not present on the server (ERR AUTH response).
- if the hash of the downloaded file chunk does not match the description.
+The receiving client can fall back to secondary routers, if necessary:
+- if the router is not available.
+- if the packet is not present on the router (ERR AUTH response).
+- if the hash of the downloaded data packet does not match the description.

-Optionally recipient can acknowledge file chunk reception to delete file ID from server for this recipient.
+Optionally recipient can acknowledge data packet reception to delete file ID from router for this recipient.

-2) Combine the chunks into a file.
+2) Combine the packets into a file.

 3) Decrypt the file using the key in file description.

@@ -163,35 +172,35 @@ Optionally recipient can acknowledge file chunk reception to delete file ID from

 It includes these fields:
 - `party` - "sender" or "recipient". Sender's file description is required to delete the file.
- `size` - padded file size equal to total size of all chunks, see `fileSize` syntax below.
+- `size` - padded file size equal to total size of all packets, see `fileSize` syntax below.
 - `digest` - SHA512 hash of encrypted file, base64url encoded string.
 - `key` - symmetric encryption key to decrypt the file, base64url encoded string.
 - `nonce` - nonce to decrypt the file, base64url encoded string.
- `chunkSize` - default chunk size, see `fileSize` syntax below.
- `replicas` - the array of file chunk replicas descriptions.
+- `chunkSize` - default packet size, see `fileSize` syntax below.
+- `replicas` - the array of data packet replicas descriptions.
 - `redirect` - optional property for redirect information indicating that the file is itself a description to another file, allowing to use file description as a short URI.

 Each replica description is an object with 2 fields:

- `chunks` - and array of chunk replica descriptions stored on one server.
- `server` - [server address](#xftp-server-uri) where the chunks can be downloaded from.
+- `chunks` - an array of packet replica descriptions stored on one server.
+- `server` - [router address](#xftp-router-uri) where the packets can be downloaded from.

-Each server replica description is a string with this syntax:
+Each router replica description is a string with this syntax:

 ```abnf
-chunkReplica = chunkNo ":" replicaId ":" replicaKey [":" chunkDigest [":" chunkSize]]
-chunkNo = 1*DIGIT
-  ; a sequential 1-based chunk number in the original file.
+packetReplica = packetNo ":" replicaId ":" replicaKey [":" packetDigest [":" packetSize]]
+packetNo = 1*DIGIT
+  ; a sequential 1-based packet number in the original file.
 replicaId = base64url
-  ; server-assigned random chunk replica ID.
+  ; router-assigned random packet replica ID.
 replicaKey = base64url
-  ; sender-generated random key to receive (or to delete, in case of sender's file description) the chunk replica.
-chunkDigest = base64url
-  ; chunk digest that MUST be specified for the first replica of each chunk,
+  ; sender-generated random key to receive (or to delete, in case of sender's file description) the packet replica.
+packetDigest = base64url
+  ; packet digest that MUST be specified for the first replica of each packet,
  ; and SHOULD be omitted (or be the same) on the subsequent replicas
-chunkSize = fileSize
+packetSize = fileSize
 fileSize = sizeInBytes / sizeInUnits
-  ; chunk size SHOULD only be specified on the first replica and only if it is different from default chunk size
+  ; packet size SHOULD only be specified on the first replica and only if it is different from default packet size
 sizeInBytes = 1*DIGIT
 sizeInUnits = 1*DIGIT sizeUnit
 sizeUnit = %s"kb" / %s"mb" / %s"gb"
@@ -204,28 +213,28 @@ Optional redirect information has two fields:

 ## URIs syntax

-### XFTP server URI
+### XFTP router URI

-The XFTP server address is a URI with the following syntax:
+The XFTP router address is a URI with the following syntax:

 ```abnf
-xftpServerURI = %s"xftp://" xftpServer
-xftpServer = serverIdentity [":" basicAuth] "@" srvHost [":" port]
+xftpRouterURI = %s"xftp://" xftpRouter
+xftpRouter = routerIdentity [":" basicAuth] "@" srvHost [":" port]
 srvHost = <hostname> ; RFC1123, RFC5891
 port = 1*DIGIT
-serverIdentity = base64url
+routerIdentity = base64url
 basicAuth = base64url
 ```

 ### File description URI

-This file description URI can be generated by the client application to share a small file description as a QR code or as a link. Practically, to be able to scan a QR code it should be under 1000 characters, so only file descriptions with 1-2 chunks can be used in this case. This is supported with `redirect` property when file description leads to a file which in itself is a larger file description to another file - akin to URL shortener.
+This file description URI can be generated by the client application to share a small file description as a QR code or as a link. Practically, to be able to scan a QR code it should be under 1000 characters, so only file descriptions with 1-2 packets can be used in this case. This is supported with `redirect` property when file description leads to a file which in itself is a larger file description to another file - akin to URL shortener.

 File description URI syntax:

 ```abnf
 fileDescriptionURI = serviceScheme "/file"  "#/?desc=" description [ "&data=" userData ]
-serviceScheme = (%s"https://" clientAppServer) | %s"simplex:"
+serviceScheme = (%s"https://" clientAppServer) / %s"simplex:"
 clientAppServer = hostname [ ":" port ]
 ; client app server, e.g. simplex.chat
 description = <URI-escaped YAML file description>
@@ -240,50 +249,50 @@ clientAppServer is not a server the client connects to - it is a server that sho

 XFTP stands for SimpleX File Transfer Protocol. Its design is based on the same ideas and has some of the qualities of SimpleX Messaging Protocol:

- recipient cannot see sender's IP address, as the file fragments (chunks) are temporarily stored on multiple XFTP relays.
+- recipient cannot see sender's IP address, as the file fragments (packets) are temporarily stored on multiple XFTP relays.
 - file can be sent asynchronously, without requiring the sender to be online for file to be received.
 - there is no network of peers that can observe this transfer - sender chooses which XFTP relays to use, and can self-host their own.
- XFTP relays do not have any file metadata - they only see individual chunks, with access to each chunk authorized with anonymous credentials (using Edwards curve cryptographic signature) that are random per chunk.
- chunks have one of the sizes allowed by the servers - 64KB, 256KB, 1MB and 4MB chunks, so sending a large file looks indistinguishable from sending many small files to XFTP server. If the same transport connection is reused, server would only know that chunks are sent by the same user.
- each chunk can be downloaded by multiple recipients, but each recipient uses their own key and chunk ID to authorize access, and the chunk is encrypted by a different key agreed via ephemeral DH keys (NaCl crypto_box (SalsaX20Poly1305 authenticated encryption scheme ) with shared secret derived from Curve25519 key exchange) on the way from the server to each recipient. XFTP protocol as a result has the same quality as SMP protocol - there are no identifiers and ciphertext in common between sent and received traffic inside TLS connection, so even if TLS is compromised, it complicates traffic correlation attacks.
- XFTP protocol supports redundancy - each file chunk can be sent via multiple relays, and the recipient can choose the one that is available. Current implementation of XFTP protocol in SimpleX Chat does not support redundancy though.
+- XFTP relays do not have any file metadata - they only see individual packets, with access to each packet authorized with anonymous credentials (using Edwards curve cryptographic signature) that are random per packet.
+- packets have one of the sizes allowed by the routers - 64KB, 256KB, 1MB and 4MB packets, so sending a large file looks indistinguishable from sending many small files to XFTP router. If the same transport connection is reused, router would only know that packets are sent by the same user.
+- each packet can be downloaded by multiple recipients, but each recipient uses their own key and packet ID to authorize access, and the packet is encrypted by a different key agreed via ephemeral DH keys (NaCl crypto_box (SalsaX20Poly1305 authenticated encryption scheme ) with shared secret derived from Curve25519 key exchange) on the way from the router to each recipient. XFTP protocol as a result has the same quality as SMP protocol - there are no identifiers and ciphertext in common between sent and received traffic inside TLS connection, so even if TLS is compromised, it complicates traffic correlation attacks.
+- XFTP protocol supports redundancy - each data packet can be sent via multiple relays, and the recipient can choose the one that is available. Current implementation of XFTP protocol in SimpleX Chat does not support redundancy though.
 - the file as a whole is encrypted with a random symmetric key using NaCl secret_box.

 ## Cryptographic algorithms

 Clients must cryptographically authorize XFTP commands, see [Command authentication](#command-authentication).

-To authorize/verify transmissions clients and servers MUST use either signature algorithm Ed25519 algorithm defined in RFC8709 or using deniable authentication scheme based on NaCL crypto_box (see Simplex Messaging Protocol).
+To authorize/verify transmissions clients and routers MUST use either signature algorithm Ed25519 algorithm defined in RFC8709 or using deniable authentication scheme based on NaCL crypto_box (see Simplex Messaging Protocol).

-To encrypt/decrypt file chunk bodies delivered to the recipients, servers/clients MUST use NaCL crypto_box.
+To encrypt/decrypt data packet bodies delivered to the recipients, routers/clients MUST use NaCL crypto_box.

-Clients MUST encrypt file chunk bodies sent via XFTP servers using use NaCL crypto_box.
+Clients MUST encrypt data packet bodies sent via XFTP routers using use NaCL crypto_box.

-## File chunk IDs
+## Data packet IDs

-XFTP servers MUST generate a separate new set of IDs for each new chunk - for the sender (that uploads the chunk) and for each intended recipient. It is REQUIRED that:
+XFTP routers MUST generate a separate new set of IDs for each new packet - for the sender (that uploads the packet) and for each intended recipient. It is REQUIRED that:

- These IDs are different and unique within the server.
+- These IDs are different and unique within the router.
 - Based on random bytes generated with cryptographically strong pseudo-random number generator.

-## Server security requirements
+## Router security requirements

-XFTP server implementations MUST NOT create, store or send to any other servers:
+XFTP router implementations MUST NOT create, store or send to any other routers:

 - Logs of the client commands and transport connections in the production environment.

 - History of retrieved files.

- Snapshots of the database they use to store file chunks (instead clients can manage redundancy by creating chunk replicas using more than one XFTP server). In-memory persistence is recommended for file chunks records.
+- Snapshots of the database they use to store data packets (instead clients can manage redundancy by creating packet replicas using more than one XFTP router). In-memory persistence is recommended for data packets records.

- Any other information that may compromise privacy or [forward secrecy][4] of communication between clients using XFTP servers.
+- Any other information that may compromise privacy or [forward secrecy][4] of communication between clients using XFTP routers.

 ## Transport protocol

- binary-encoded commands sent as fixed-size padded block in the body of HTTP2 POST request, similar to SMP and notifications server protocol transmission encodings.
+- binary-encoded commands sent as fixed-size padded block in the body of HTTP2 POST request, similar to SMP and notifications router protocol transmission encodings.
 - HTTP2 POST with a fixed size padded block body for file upload and download.

-Block size - 4096 bytes (it would fit ~120 Ed25519 recipient keys).
+Block size - 16384 bytes (it would fit ~350 Ed25519 recipient keys).

 The reasons to use HTTP2:

@@ -299,40 +308,41 @@ The reason not to use URI segments / HTTP verbs / REST semantics is to have cons

 ### ALPN to agree handshake version

-Client and server use [ALPN extension][18] of TLS to agree handshake version.
+Client and router use [ALPN extension][18] of TLS to agree handshake version.

-Server SHOULD send `xftp/1` protocol name and the client should confirm this name in order to use the current protocol version. This is added to allow support of older clients without breaking backward compatibility and to extend or modify handshake syntax.
+Router SHOULD send `xftp/1` protocol name and the client should confirm this name in order to use the current protocol version. This is added to allow support of older clients without breaking backward compatibility and to extend or modify handshake syntax.

-If the client does not confirm this protocol name, the server would fall back to v1 of XFTP protocol.
+If the client does not confirm this protocol name, the router would fall back to v1 of XFTP protocol.

 ### Transport handshake

-When a client and a server agree on handshake version using ALPN extension, they should proceed with XFTP handshake.
+When a client and a router agree on handshake version using ALPN extension, they should proceed with XFTP handshake.

-As with SMP, a client doesn't reveal its version range to avoid version fingerprinting. Unlike SMP, XFTP runs a HTTP2 protocol over TLS and the server can't just send its handshake right away. So a session handshake is driven by client-sent requests:
+As with SMP, a client doesn't reveal its version range to avoid version fingerprinting. Unlike SMP, XFTP runs a HTTP2 protocol over TLS and the router can't just send its handshake right away. So a session handshake is driven by client-sent requests:

-1. To pass initiative to the server, the client sends a request with empty body.
-2. Server responds with its `paddedServerHello` block.
+1. To pass initiative to the router, the client sends a request with empty body.
+2. Router responds with its `paddedRouterHello` block.
 3. Clients sends a request containing `paddedClientHello` block,
-4. Server sends an empty response, finalizing the handshake.
+4. Router sends an empty response, finalizing the handshake.

-Once TLS handshake is complete, client and server will exchange blocks of fixed size (16384 bytes).
+Once TLS handshake is complete, client and router will exchange blocks of fixed size (16384 bytes).

 ```abnf
-paddedServerHello = <padded(serverHello, 16384)>
-serverHello = xftpVersionRange sessionIdentifier serverCert signedServerKey ignoredPart
+paddedRouterHello = <padded(routerHello, 16384)>
+routerHello = xftpVersionRange sessionIdentifier routerCerts signedRouterKey ignoredPart
 xftpVersionRange = minXftpVersion maxXftpVersion
 minXftpVersion = xftpVersion
 maxXftpVersion = xftpVersion
 sessionIdentifier = shortString
 ; unique session identifier derived from transport connection handshake
-serverCert = originalLength <x509encoded>
-signedServerKey = originalLength <x509encoded> ; signed by server certificate
+routerCerts = length 1*routerCert ; NonEmpty list of certificates in chain
+routerCert = originalLength <x509encoded>
+signedRouterKey = originalLength <x509encoded> ; signed by router certificate

 paddedClientHello = <padded(clientHello, 16384)>
 clientHello = xftpVersion keyHash ignoredPart
 ; chosen XFTP protocol version - must be the maximum supported version
-; within the range offered by the server
+; within the range offered by the router

 xftpVersion = 2*2OCTET ; Word16 version number
 keyHash = shortString
@@ -342,47 +352,47 @@ originalLength = 2*2OCTET
 ignoredPart = *OCTET
 ```

-In XFTP v2 the handshake is only used for version negotiation, but `serverCert` and `signedServerKey` must be validated by the client.
+In XFTP v2 the handshake is only used for version negotiation, but `routerCert` and `signedRouterKey` must be validated by the client.

-`keyHash` is the CA fingerprint used by client to validate TLS certificate chain and is checked by a server against its own key.
+`keyHash` is the CA fingerprint used by client to validate TLS certificate chain and is checked by a router against its own key.

-`ignoredPart` in handshake allows to add additional parameters in handshake without changing protocol version - the client and servers must ignore any extra bytes within the original block length.
+`ignoredPart` in handshake allows to add additional parameters in handshake without changing protocol version - the client and routers must ignore any extra bytes within the original block length.

-For TLS transport client should assert that `sessionIdentifier` is equal to `tls-unique` channel binding defined in [RFC 5929][14] (TLS Finished message struct); we pass it in `serverHello` block to allow communication over some other transport protocol (possibly, with another channel binding).
+For TLS transport client should assert that `sessionIdentifier` is equal to `tls-unique` channel binding defined in [RFC 5929][14] (TLS Finished message struct); we pass it in `routerHello` block to allow communication over some other transport protocol (possibly, with another channel binding).

 ### Requests and responses

 - File sender:
-  - create file chunk record.
+  - create data packet record.
    - Parameters:
      - Ed25519 key for subsequent sender commands and Ed25519 keys for commands of each recipient.
-      - chunk size.
+      - packet size.
    - Response:
-      - chunk ID for the sender and different IDs for all recipients.
-  - add recipients to file chunk
+      - packet ID for the sender and different IDs for all recipients.
+  - add recipients to data packet
    - Parameters:
-      - sender's chunk ID
+      - sender's packet ID
      - Ed25519 keys for commands of each recipient.
    - Response:
-      - chunk IDs for new recipients.
-  - upload file chunk.
-  - delete file chunk (invalidates all recipient IDs).
+      - packet IDs for new recipients.
+  - upload data packet.
+  - delete data packet (invalidates all recipient IDs).
 - File recipient:
-  - download file chunk:
-    - chunk ID
-    - DH key for additional encryption of the chunk.
-    - command should be signed with the key passed by the sender when creating chunk record.
-  - delete file chunk ID (only for one recipient): signed with the same key.
+  - download data packet:
+    - packet ID
+    - DH key for additional encryption of the packet.
+    - command should be signed with the key passed by the sender when creating packet record.
+  - delete data packet ID (only for one recipient): signed with the same key.

 ## XFTP commands

 Commands syntax below is provided using ABNF with case-sensitive strings extension.

 ```abnf
-xftpCommand = ping / senderCommand / recipientCmd / serverMsg
+xftpCommand = ping / senderCommand / recipientCmd / routerMsg
 senderCommand = register / add / put / delete
 recipientCmd = get / ack
-serverMsg = pong / sndIds / rcvIds / ok / file
+routerMsg = pong / sndIds / rcvIds / ok / file / error
 ```

 The syntax of specific commands and responses is defined below.
@@ -393,11 +403,11 @@ Commands are made via HTTP2 requests, responses to commands are correlated as HT

 ### Command authentication

-XFTP servers must authenticate all transmissions (excluding `ping`) by verifying the client signatures. Command signature should be generated by applying the algorithm specified for the file to the `signed` block of the transmission, using the key associated with the file chunk ID (recipient's or sender's depending on which file chunk ID is used).
+XFTP routers must authenticate all transmissions (excluding `ping`) by verifying the client signatures. Command signature should be generated by applying the algorithm specified for the file to the `signed` block of the transmission, using the key associated with the data packet ID (recipient's or sender's depending on which data packet ID is used).

 ### Keep-alive command

-To keep the transport connection alive and to generate noise traffic the clients should use `ping` command to which the server responds with `pong` response. This command should be sent unsigned and without file chunk ID.
+To keep the transport connection alive and to generate noise traffic the clients should use `ping` command to which the router responds with `pong` response. This command should be sent unsigned and without data packet ID.

 ```abnf
 ping = %s"PING"
@@ -405,21 +415,19 @@ ping = %s"PING"

 This command is always sent unsigned.

-  data FileResponse = ... | FRPong | ...
-
 ```abnf
 pong = %s"PONG"
 ```

 ### File sender commands

-Sending any of the commands in this section (other than `register`, that is sent without file chunk ID) is only allowed with sender's ID.
+Sending any of the commands in this section (other than `register`, that is sent without data packet ID) is only allowed with sender's ID. The `register` command must be signed (using `sndKey` included in `fileInfo` for verification) but must NOT include a data packet ID.

-#### Register new file chunk
+#### Register new data packet

-This command is sent by the sender to the XFTP server to register a new file chunk.
+This command is sent by the sender to the XFTP router to register a new data packet.

-Servers SHOULD support basic auth with this command, to allow only server owners and trusted users to create file chunks on the servers.
+Routers SHOULD support basic auth with this command, to allow only router owners and trusted users to create data packets on the routers.

 The syntax is:

@@ -427,7 +435,7 @@ The syntax is:
 register = %s"FNEW " fileInfo rcvPublicAuthKeys basicAuth
 fileInfo = sndKey size digest
 sndKey = length x509encoded
-size = 1*DIGIT
+size = 4*4 OCTET ; Word32 big-endian
 digest = length *OCTET
 rcvPublicAuthKeys = length 1*rcvPublicAuthKey
 rcvPublicAuthKey = length x509encoded
@@ -438,7 +446,7 @@ x509encoded = <binary X509 key encoding>
 length = 1*1 OCTET
 ```

-If the file chunk is registered successfully, the server must send `sndIds` response with the sender's and recipients' file chunk IDs:
+If the data packet is registered successfully, the router must send `sndIds` response with the sender's and recipients' data packet IDs:

 ```abnf
 sndIds = %s"SIDS " senderId recipientIds
@@ -447,9 +455,9 @@ recipientIds = length 1*recipientId
 recipientId = length *OCTET
 ```

-#### Add file chunk recipients
+#### Add data packet recipients

-This command is sent by the sender to the XFTP server to add additional recipient keys to the file chunk record, in case number of keys requested by client didn't fit into `register` command. The syntax is:
+This command is sent by the sender to the XFTP router to add additional recipient keys to the data packet record, in case number of keys requested by client didn't fit into `register` command. The syntax is:

 ```abnf
 add = %s"FADD " rcvPublicAuthKeys
@@ -457,7 +465,7 @@ rcvPublicAuthKeys = length 1*rcvPublicAuthKey
 rcvPublicAuthKey = length x509encoded
 ```

-If additional keys were added successfully, the server must send `rcvIds` response with the added recipients' file chunk IDs:
+If additional keys were added successfully, the router must send `rcvIds` response with the added recipients' data packet IDs:

 ```abnf
 rcvIds = %s"RIDS " recipientIds
@@ -465,66 +473,100 @@ recipientIds = length 1*recipientId
 recipientId = length *OCTET
 ```

-#### Upload file chunk
+#### Upload data packet

-This command is sent by the sender to the XFTP server to upload file chunk body to server. The syntax is:
+This command is sent by the sender to the XFTP router to upload data packet body to router. The syntax is:

 ```abnf
 put = %s"FPUT"
 ```

-Chunk body is streamed via HTTP2 request.
+Packet body is streamed via HTTP2 request.

-If file chunk body was successfully received, the server must send `ok` response.
+If data packet body was successfully received, the router must send `ok` response.

 ```abnf
 ok = %s"OK"
 ```

-#### Delete file chunk
+#### Delete data packet

-This command is sent by the sender to the XFTP server to delete file chunk from the server. The syntax is:
+This command is sent by the sender to the XFTP router to delete data packet from the router. The syntax is:

 ```abnf
 delete = %s"FDEL"
 ```

-Server should delete file chunk record, invalidating all recipient IDs, and delete file body from file storage. If file chunk was successfully deleted, the server must send `ok` response.
+Router should delete data packet record, invalidating all recipient IDs, and delete file body from file storage. If data packet was successfully deleted, the router must send `ok` response.

 ### File recipient commands

 Sending any of the commands in this section is only allowed with recipient's ID.

-#### Download file chunk
+#### Download data packet

-This command is sent by the recipient to the XFTP server to download file chunk body from the server. The syntax is:
+This command is sent by the recipient to the XFTP router to download data packet body from the router. The syntax is:

 ```abnf
 get = %s"FGET " rDhKey
 rDhKey = length x509encoded
 ```

-If requested file is successfully located, the server must send `file` response. File chunk body is sent as HTTP2 response body.
+If requested file is successfully located, the router must send `file` response. Data packet body is sent as HTTP2 response body.

 ```abnf
 file = %s"FILE " sDhKey cbNonce
 sDhKey = length x509encoded
-cbNonce = <nonce used in NaCl crypto_box encryption scheme>
+cbNonce = 24*24 OCTET ; NaCl crypto_box nonce
 ```

-Chunk is additionally encrypted on the way from the server to the recipient using a key agreed via ephemeral DH keys `rDhKey` and `sDhKey`, so there is no ciphertext in common between sent and received traffic inside TLS connection, in order to complicate traffic correlation attacks, if TLS is compromised.
+Packet is additionally encrypted on the way from the router to the recipient using a key agreed via ephemeral DH keys `rDhKey` and `sDhKey`, so there is no ciphertext in common between sent and received traffic inside TLS connection, in order to complicate traffic correlation attacks, if TLS is compromised.

-#### Acknowledge file chunk download
+#### Acknowledge data packet download

-This command is sent by the recipient to the XFTP server to acknowledge file reception, deleting file ID from server for this recipient. The syntax is:
+This command is sent by the recipient to the XFTP router to acknowledge file reception, deleting file ID from router for this recipient. The syntax is:

 ```abnf
 ack = %s"FACK"
 ```

-If file recipient ID is successfully deleted, the server must send `ok` response.
+If file recipient ID is successfully deleted, the router must send `ok` response.

-In current implementation of XFTP protocol in SimpleX Chat clients don't use FACK command. Files are automatically expired on servers after configured time interval.
+In current implementation of XFTP protocol in SimpleX Chat clients don't use FACK command. Files are automatically expired on routers after configured time interval.
+
+### Error responses
+
+The router responds with `ERR` followed by the error type:
+
+```abnf
+error = %s"ERR " errorType
+errorType = %s"BLOCK" / %s"SESSION" / %s"HANDSHAKE" /
+            %s"CMD" SP cmdError / %s"AUTH" / %s"BLOCKED" SP blockingInfo /
+            %s"SIZE" / %s"QUOTA" / %s"DIGEST" / %s"CRYPTO" /
+            %s"NO_FILE" / %s"HAS_FILE" / %s"FILE_IO" /
+            %s"TIMEOUT" / %s"INTERNAL"
+cmdError = %s"UNKNOWN" / %s"SYNTAX" / %s"PROHIBITED" / %s"NO_AUTH" / %s"HAS_AUTH" / %s"NO_ENTITY"
+blockingInfo = %s"reason=" blockingReason ["," %s"notice=" jsonNotice]
+blockingReason = %s"spam" / %s"content"
+jsonNotice = *OCTET ; JSON-encoded notice object
+```
+
+Error types:
+- `BLOCK` - incorrect block format, encoding or signature size.
+- `SESSION` - incorrect session ID (TLS Finished message / tls-unique binding).
+- `HANDSHAKE` - incorrect handshake command.
+- `CMD` - command syntax errors (UNKNOWN, SYNTAX, PROHIBITED, NO_AUTH, HAS_AUTH, NO_ENTITY).
+- `AUTH` - command authorization error - bad signature or non-existing data packet.
+- `BLOCKED` - data packet was blocked due to policy violation (added in v3). Contains blocking reason and optional notice.
+- `SIZE` - incorrect file size.
+- `QUOTA` - storage quota exceeded.
+- `DIGEST` - incorrect file digest.
+- `CRYPTO` - file encryption/decryption failed.
+- `NO_FILE` - no expected file body in request/response or no file on the router.
+- `HAS_FILE` - unexpected file body.
+- `FILE_IO` - file IO error.
+- `TIMEOUT` - file sending or receiving timeout.
+- `INTERNAL` - internal router error.

 ## Threat model

@@ -533,7 +575,7 @@ In current implementation of XFTP protocol in SimpleX Chat clients don't use FAC
 - A user protects their local database and key material.
 - The user's application is authentic, and no local malware is running.
 - The cryptographic primitives in use are not broken.
- - A user's choice of servers is not directly tied to their identity or otherwise represents distinguishing information about the user.
+ - A user's choice of routers is not directly tied to their identity or otherwise represents distinguishing information about the user.

 #### A passive adversary able to monitor the traffic of one user

@@ -541,7 +583,7 @@ In current implementation of XFTP protocol in SimpleX Chat clients don't use FAC

 - identify that and when a user is sending files over XFTP protocol.

- - determine which servers the user sends/receives files to/from.
+ - determine which routers the user sends/receives files to/from.

 - observe how much traffic is being sent, and make guesses as to its purpose.

@@ -553,11 +595,11 @@ In current implementation of XFTP protocol in SimpleX Chat clients don't use FAC

 *can:*

- - learn which XFTP servers are used to send and receive files for which users.
+ - learn which XFTP routers are used to send and receive files for which users.

 - learn when files are sent and received.

- - perform traffic correlation attacks against senders and recipients and correlate senders and recipients within the monitored set, frustrated by the number of users on the servers.
+ - perform traffic correlation attacks against senders and recipients and correlate senders and recipients within the monitored set, frustrated by the number of users on the routers.

 - observe how much traffic is being sent, and make guesses as to its purpose.

@@ -567,31 +609,31 @@ In current implementation of XFTP protocol in SimpleX Chat clients don't use FAC

 - perform traffic correlation attacks.

-#### XFTP server
+#### XFTP router

 *can:*

 - learn when file senders and recipients are online.

- know how many file chunks and chunk sizes are sent via the server.
+- know how many data packets and packet sizes are sent via the router.

- perform the correlation of the file chunks as belonging to one file via either a re-used transport connection, user's IP address, or connection timing regularities.
+- perform the correlation of the data packets as belonging to one file via either a re-used transport connection, user's IP address, or connection timing regularities.

 - learn file senders' and recipients' IP addresses, and infer information (e.g. employer) based on the IP addresses, as long as Tor is not used.

- delete file chunks, preventing file delivery, as long as redundant delivery is not used.
+- delete data packets, preventing file delivery, as long as redundant delivery is not used.

- lie about the state of a file chunk to the recipient and/or to the sender  (e.g. deleted when it is not).
+- lie about the state of a data packet to the recipient and/or to the sender  (e.g. deleted when it is not).

 - refuse deleting the file when instructed by the sender.

 *cannot:*

- undetectably corrupt file chunks.
+- undetectably corrupt data packets.

 - learn the contents, name or the exact size of sent files.

- learn approximate size of sent files, as long as more than one server is used to send file chunks.
+- learn approximate size of sent files, as long as more than one router is used to send data packets.

 - compromise the users' end-to-end encryption of files with an active attack.

@@ -603,7 +645,7 @@ In current implementation of XFTP protocol in SimpleX Chat clients don't use FAC

 - receive all files sent and received by Alice that did not expire yet, as long as information about these files was not removed from the database.

- prevent Alice's contacts from receiving the files she sent by deleting all or some of the file chunks from XFTP servers.
+- prevent Alice's contacts from receiving the files she sent by deleting all or some of the data packets from XFTP routers.

 #### A user's contact

@@ -625,10 +667,10 @@ In current implementation of XFTP protocol in SimpleX Chat clients don't use FAC

 *can:*

- Denial of Service XFTP servers.
+- Denial of Service XFTP routers.

 *cannot:*

 - send files to a user who they are not connected with.

- enumerate file chunks on an XFTP server.
+- enumerate data packets on an XFTP router.
@@ -10,7 +10,7 @@ Version 1, 2024-06-22
  - [Session invitation](#session-invitation)
  - [Establishing TLS connection](#establishing-tls-connection)
  - [Session verification and protocol negotiation](#session-verification-and-protocol-negotiation)
-  - [Controller/host session operation](#сontrollerhost-session-operation)
+  - [Controller/host session operation](#controllerhost-session-operation)
 - [Key agreement for announcement packet and for session](#key-agreement-for-announcement-packet-and-for-session)
 - [Threat model](#threat-model)

@@ -104,12 +104,11 @@ Multicast session announcement is a binary encoded packet with this syntax:
 ```abnf
 sessionAddressPacket = dhPubKey nonce encrypted(unpaddedSize sessionAddress packetPad)
 dhPubKey = length x509encoded ; same as announced
-nonce = length *OCTET
-sessionAddress = largeLength sessionAddressUri ; as above
+nonce = 24*24 OCTET ; NaCl 192-bit nonce, no length prefix
+sessionAddress = sessionAddressUri ; length given by unpaddedSize
 length = 1*1 OCTET ; for binary data up to 255 bytes
 largeLength = 2*2 OCTET ; for binary data up to 65535 bytes
-packetPad = <pad packet size to 1450 bytes> ; possibly, we may need to move KEM agreement one step later,
-; with encapsulation key in HELLO block and KEM ciphertext in reply to HELLO.
+packetPad = <pad invitation content to 900 bytes before encryption>
 ```

 ### Establishing TLS connection
@@ -143,7 +142,7 @@ hostHello = %s"HELLO " dhPubKey nonce encrypted(unpaddedSize hostHelloJSON hello
 unpaddedSize = largeLength
 dhPubKey = length x509encoded
 pad = <pad block size to 16384 bytes>
-helloPad = <pad hello size to 12888 bytes>
+helloPad = <pad hello size to 12288 bytes>
 largeLength = 2*2 OCTET
 ```

@@ -157,10 +156,7 @@ The controller decrypts (including the first session) and validates the received
 {
  "definitions": {
    "version": {
-      "type": "string",
-      "metadata": {
-        "format": "[0-9]+"
-      }
+      "type": "uint16"
    },
    "base64url": {
      "type": "string",
@@ -172,9 +168,7 @@ The controller decrypts (including the first session) and validates the received
  "properties": {
    "v": {"ref": "version"},
    "ca": {"ref": "base64url"},
-    "kem": {"ref": "base64url"}
-  },
-  "optionalProperties": {
+    "kem": {"ref": "base64url"},
    "app": {"properties": {}, "additionalProperties": true}
  },
  "additionalProperties": true
@@ -190,7 +184,7 @@ ctrlHello = %s"HELLO " kemCiphertext encrypted(unpaddedSize ctrlHelloJSON helloP
 unpaddedSize = largeLength
 kemCiphertext = largeLength *OCTET
 pad = <pad block size to 16384 bytes>
-helloPad = <pad hello size to 12888 bytes>
+helloPad = <pad hello size to 12288 bytes>
 largeLength = 2*2 OCTET

 ctrlError = %s"ERROR " nonce encrypted(unpaddedSize ctrlErrorMessage helloPad) pad
@@ -206,7 +200,7 @@ JTD schema for the encrypted part of controller HELLO block `ctrlHelloJSON`:
 }
 ```

-Controller `hello` block and all subsequent protocol messages are encrypted with the chain keys derived from the hybrid key (see key exchange below) - that is why conntroller hello block does not include nonce. That provides forward secrecy within the XRCP session. Receiving this `hello` block allows host to compute the same hybrid keys and to derive the same chain keys.
+Controller `hello` block and all subsequent protocol messages are encrypted with the chain keys derived from the hybrid key (see key exchange below) - that is why controller hello block does not include nonce. That provides forward secrecy within the XRCP session. Receiving this `hello` block allows host to compute the same hybrid keys and to derive the same chain keys.

 Once the controller replies HELLO to the valid host HELLO block, it should stop accepting new TCP connections.

@@ -261,7 +255,7 @@ kemCiphertext(1) = enc(kemSecret(1), kemEncKey(1))
 kemSecret(1) = dec(kemCiphertext(1), kemDecKey(1))

 // multicast announcement for session n
-announcementSecret(n) = sha256(dhSecret(n'))
+announcementSecret(n) = dhSecret(n')
 dhSecret(n') = dh(hostHelloDhKey(n - 1), controllerDhKey(n))

 // session n
@@ -277,11 +271,11 @@ If controller fails to store the new host DH key after receiving HELLO block, th

 To decrypt a multicast announcement, the host should try to decrypt it using the keys of all known (paired) remote controllers.

-Once kemSecret is agreed for the session, it is used to derive two chain keys, to receive and to send messages:
+Once sessionSecret is agreed for the session, it is used to derive two chain keys, to receive and to send messages:

 ```
-host: sndKey, rcvKey = HKDF(kemSecret, "SimpleXSbChainInit", 64)
-controller: rcvKey, sndKey  = HKDF(kemSecret, "SimpleXSbChainInit", 64)
+controller: sndKey, rcvKey = HKDF(sessionSecret, "SimpleXSbChainInit", 64)
+host: rcvKey, sndKey = HKDF(sessionSecret, "SimpleXSbChainInit", 64)
 ```

 where HKDF is based on SHA512, with empty salt.
@@ -3,9 +3,9 @@
 ## Problem

 When sending an SMP confirmation a network timeout can lead to the following race condition:
- server receives the confirmation while the joining party fails to receive the server's response;
+- router receives the confirmation while the joining party fails to receive the router's response;
 - joining party deletes the connection together with credentials sent in the confirmation for securing the queue;
- initiating party will receive the confirmation from the server and secure the queue;
+- initiating party will receive the confirmation from the router and secure the queue;
 - on subsequent attempt to join via the same invitation link initiating party will generate new credentials and fail authorization.

 This renders the joining party permanently unable to join via that invitation link and complete the connection.
@@ -3,12 +3,12 @@
 ## Problem

 iOS notifications may fail to deliver for several reasons, but there are two important reasons that we could address:
- when notification server is not subscribed to SMP server(s), the notifications can be dropped - it can happen because either notification server restarts or becuase SMP server restarted and some messages are received before notification server resubscribed. We lose approximately 3% of notifications because of this reason.
+- when notification router is not subscribed to SMP router(s), the notifications can be dropped - it can happen because either notification router restarts or becuase SMP router restarted and some messages are received before notification router resubscribed. We lose approximately 3% of notifications because of this reason.
 - when user device is offline or has low power condition, Apple does not deliver notification, but puts them to storage. If while the notification is in storage a new one arrives it would overwrite the previous notification. If it was the message to the same message queue, the client will download messages anyway, up to a limit, but if the message was to another queue, it will not be delivered until the app is opened. Apple delivers about 88% of notifications that should be delivered (not accounting for uninstalled apps), the rest is replaced with the newer notifications.

 ## Solution

-The first problem can be solved by preserving notifications for a limited time (say 1 hour) in case there is no subscription to notification from notification server. At the very least, they can be preserved in SMP server memory but can also be stored to a file on restart, similar to messages, and be delivered when notification server resubscribes. It is sufficient to store one notification per messaging queue.
+The first problem can be solved by preserving notifications for a limited time (say 1 hour) in case there is no subscription to notification from notification router. At the very least, they can be preserved in SMP router memory but can also be stored to a file on restart, similar to messages, and be delivered when notification router resubscribes. It is sufficient to store one notification per messaging queue.

 The second problem is both more damaging and more complex to solve. The solution could be to always deliver several last notifications to different queues in one packet (Apple allows up to ~4-5kb notification size, and we are sending packets of fixed size 512 bytes, so we could fit up to 8-10 of them in each notification).

@@ -8,7 +8,7 @@ See [Short invitation links](./2024-06-21-short-links.md).

 2) clients only delete queue records based on some user action, pending connections do not expire.

-While part 2 should be improved in the client, indefinite storage of queue records becomes a much bigger issue if each of them would result in a permanent storage of 4-16kb blob in server memory, without server-side expiration for short invitation links.
+While part 2 should be improved in the client, indefinite storage of queue records becomes a much bigger issue if each of them would result in a permanent storage of 4-16kb blob in router memory, without router-side expiration for short invitation links.

 ## Possible solutions

@@ -16,15 +16,15 @@ While part 2 should be improved in the client, indefinite storage of queue recor

 The problem with this approach is that contact addresses are also unsecured queues, and they should not be expired.

-We could set really large expiration time, and require that clients "update" the unsecured queues they need at least every 1-2 years, but it would not solve the problem of storing a large number of blobs in the server memory for unused/abandoned 1-time invitations.
+We could set really large expiration time, and require that clients "update" the unsecured queues they need at least every 1-2 years, but it would not solve the problem of storing a large number of blobs in the router memory for unused/abandoned 1-time invitations.

-2) Do not store blobs in memory / append-only log, and instead use something like RocksDB. While it may be a correct long term solution, it may be not expedient enough at the current POC stage for this feature. Also, the lack of expiration is wrong in any case and would indefinitely grow server storage.
+2) Do not store blobs in memory / append-only log, and instead use something like RocksDB. While it may be a correct long term solution, it may be not expedient enough at the current POC stage for this feature. Also, the lack of expiration is wrong in any case and would indefinitely grow router storage.

-3) Add flag allowing the server to differentiate permanent queues used as contact addresses, also using different blob sizes for them. In this case, messaging queues will be expired if not secured after 3 weeks, and contact address queues would be expired if not "updated" by the owner within 2 years.
+3) Add flag allowing the router to differentiate permanent queues used as contact addresses, also using different blob sizes for them. In this case, messaging queues will be expired if not secured after 3 weeks, and contact address queues would be expired if not "updated" by the owner within 2 years.

 Probably all three solutions need to be used, to avoid creating a non-expiring blob storage in memory, as in case too many of such blobs are created it would not be possible to differentiate between real users and resource exhaustion attacks, and unlike with messages, they won't be expiring too.

-Servers already can differentiate messaging queues and contact address queues, if they want to:
+Routers already can differentiate messaging queues and contact address queues, if they want to:
 - with the old 4-message handshake, the confirmation message on a normal queue was different, and also KEY command was eventually used.
 - with the fast 2-message handshake, while the confirmation message has the same syntax, and the differences are inside encrypted envelope, the client still uses SKEY command.
 - in both cases, the usual messaging queues are secured, and contact addresses are not, so this difference is visible in the storage as well (although it is not easy to differentiate between abandoned 1-time invitations and contact addresses).
@@ -33,7 +33,7 @@ Differentiating these queues can also allow different message retention times -

 ## Proposed solution

-1. Add queue updated_at date into queue records. While it adds some metadata, it seems necessary to manage retention and quality of service. It will not include exact time, only date, and the time of creation will be replaced by the time of any update - queue secured, a message is sent, or queue owner subscribes to the queue. To avoid the need to update store log on every message this information can be appended to store log on server termination. Or given that only one update per day is needed it may be ok to make these updates as they happen (temporarily making the sequence and time of these events available in storage).
+1. Add queue updated_at date into queue records. While it adds some metadata, it seems necessary to manage retention and quality of service. It will not include exact time, only date, and the time of creation will be replaced by the time of any update - queue secured, a message is sent, or queue owner subscribes to the queue. To avoid the need to update store log on every message this information can be appended to store log on router termination. Or given that only one update per day is needed it may be ok to make these updates as they happen (temporarily making the sequence and time of these events available in storage).

 2. Add flag to indicate the queue usage - messaging queue or queue for contact address connection requests. This would result in different queue size and different retention policy for queue and its messages. We already have "sender can secure flag" which is, effectively, this flag - contact address queues are never secured. So this does not increase stored metadata in any way.

@@ -41,11 +41,11 @@ Differentiating these queues can also allow different message retention times -

 This is a design considerations and a concept, not a design yet.

-Instead of implementing a generic blob storage that can be used as an attack vector, and adds additional failure point (another server storing blob that is necessary to connect to the queue on the current server), but instead adds an extended queue information blobs, most of which could be dropped without the loss of connectivity, so that the attack can be mitigated by deleting these blobs without users losing the ability to connect, as long as the queue and minimal extended information is retained.
+Instead of implementing a generic blob storage that can be used as an attack vector, and adds additional failure point (another router storing blob that is necessary to connect to the queue on the current router), but instead adds an extended queue information blobs, most of which could be dropped without the loss of connectivity, so that the attack can be mitigated by deleting these blobs without users losing the ability to connect, as long as the queue and minimal extended information is retained.

 So, to make the connection there need to be these elements:

- queue server and queue ID - mandatory part, that can be included in short link
+- queue router and queue ID - mandatory part, that can be included in short link
 - SMP key - mandatory part for all queues. We are considering initializing ratchets earlier for contact addresses, and include ratchet keys and pre-keys into queue data as well, but it is out of scope here.
 - Ratchet keys - mandatory part for 1-time invitation that won't fit in short link.
 - PQ key - optional part that can be stored with addresses if ratchet keys are added and with 1-time invitations.
@@ -56,8 +56,8 @@ So rather that storing one blob with a large address inside it, not associated w
 Also, we need the address shared with the sender (party accepting the connection) to be short. We could use a similar approach that was proposed for data blobs, using a single random seed per queues to derive multiple keys and IDs from it. For example:

 1. The queue owner:
-  - generates Ed25529 key pair `(sk, spk)` and X25519 key pair `(dhk, dhpk)` to use with the server, same as now sent in NEW command.
-  - generates queue recipient ID (this ID can still be server-generated).
+  - generates Ed25529 key pair `(sk, spk)` and X25519 key pair `(dhk, dhpk)` to use with the router, same as now sent in NEW command.
+  - generates queue recipient ID (this ID can still be router-generated).
  - generates X25519 key pair `(k, pk)` to use with the accepting party.
  - derives from `k`:
    - sender ID.
@@ -73,9 +73,9 @@ The algorithm used to derive key and ID from `k` needs to be cryptographically s
 So, coupling blob storage with messaging queues has these pros/cons:

 Cons:
- no additional layer of privacy - the server used for connection is visible in the link, even after the blobs are removed from the server.
+- no additional layer of privacy - the router used for connection is visible in the link, even after the blobs are removed from the router.

 Pros:
- no additional point of failure in the connection process - the same server will be used to retrieve necessary blobs as for connection.
+- no additional point of failure in the connection process - the same router will be used to retrieve necessary blobs as for connection.
 - queue blobs of messaging blobs will be automatically removed once the queue is secured or expired, without additional request from the recipient - reducing the storage and the time these blobs are available.
 - queue blobs for contact addresses will be structured and some of the large blobs can be removed in case of resource exhaustion attack (and recreated by the client if needed), with the only downside that PQ handshake will be postponed (which is the case now) and profile will not be available at a point of connection.
@@ -2,25 +2,25 @@

 ## Problem

-Our current handshake protocol is open to this attack: whoever observes the link exchange, knows on which server connection is being made, and if the traffic on this server is observed, then it can confirm communication between parties. Further, even with the [last proposal](./2024-09-09-smp-blobs.md#possible-privacy-improvement), having real-time access to the server data allows to establish the exact messaging queue that is used to send messages.
+Our current handshake protocol is open to this attack: whoever observes the link exchange, knows on which router connection is being made, and if the traffic on this router is observed, then it can confirm communication between parties. Further, even with the [last proposal](./2024-09-09-smp-blobs.md#possible-privacy-improvement), having real-time access to the router data allows to establish the exact messaging queue that is used to send messages.

 ## Solution

-We could make the initial link exchange more private by making it harder for any observer to discover which server will be used for messaging by hiding this information from the server that hosts the initial link.
+We could make the initial link exchange more private by making it harder for any observer to discover which router will be used for messaging by hiding this information from the router that hosts the initial link.

 Preliminary, the protocol could be the following:

-1. Connection initiator stores 224-256 bytes of encrypted connection link on a rendezvous server (link contains server host and linkId on another messaging server, not a rendezvous one).
+1. Connection initiator stores 224-256 bytes of encrypted connection link on a rendezvous router (link contains router host and linkId on another messaging router, not a rendezvous one).

-2. Rendezvous server adds these links to buckets, up to 64 links per bucket. Bucket ID is the timestamp when the bucket was created + a sequential bucket number, in case more than one bucket is created per second.
+2. Rendezvous router adds these links to buckets, up to 64 links per bucket. Bucket ID is the timestamp when the bucket was created + a sequential bucket number, in case more than one bucket is created per second.

-3. The server responds to the link creator with a bucket ID where this link was added. That bucket ID is its timestamp + a number prevents server "fingerprinting" clients and using say one bucket for each client. If timestamp is different or a bucket number within this timestamp is too large, the client can refuse to use it, depending on the client settings.
+3. The router responds to the link creator with a bucket ID where this link was added. That bucket ID is its timestamp + a number prevents router "fingerprinting" clients and using say one bucket for each client. If timestamp is different or a bucket number within this timestamp is too large, the client can refuse to use it, depending on the client settings.

-4. The initiating party will pass to the accepting party the rendezvous server host, the hash of this bucket ID (bucket link) and the passphrase to derive the key from. The initiating party has an option to pass a link and passphrase via two channels - in which case the link will only contain the bucket ID.
+4. The initiating party will pass to the accepting party the rendezvous router host, the hash of this bucket ID (bucket link) and the passphrase to derive the key from. The initiating party has an option to pass a link and passphrase via two channels - in which case the link will only contain the bucket ID.

-5. The accepting party would then request the bucket via its ID hash (the server would store hashes to be able to look up - hash is used to prevent showing time in the link) and attempt to decrypt all contained links using the provided key.
+5. The accepting party would then request the bucket via its ID hash (the router would store hashes to be able to look up - hash is used to prevent showing time in the link) and attempt to decrypt all contained links using the provided key.
 The accepting party then will continue the connection via the decrypted link.

-This obviously does not protect accepting party from the initiating party, if it can choose rendezvous server it controls. It also does not protect from the malicious rendezvous server that would collaborate with link observers. I think reunion doesn’t protect from it too.
+This obviously does not protect accepting party from the initiating party, if it can choose rendezvous router it controls. It also does not protect from the malicious rendezvous router that would collaborate with link observers. I think reunion doesn’t protect from it too.

 But it does protect connection from whoever observes the link, particularly if this link only contains the bucket and the key is passed separately, via some other channel.
@@ -2,7 +2,7 @@

 ## Problem

-For iOS notifications to be delivered the client has to create credentials for notification subscription on SMP server using NKEY command and after that create a subscription on notification server using SNEW command. These two commands are sent in sequence, after the connections are created, and for it to happen the client needs to be online and in foreground.
+For iOS notifications to be delivered the client has to create credentials for notification subscription on SMP router using NKEY command and after that create a subscription on notification router using SNEW command. These two commands are sent in sequence, after the connections are created, and for it to happen the client needs to be online and in foreground.

 iOS users tend to close the app when it is not used, and iOS has very limited permissions for background activities, so these notification subscriptions are created with a substantial delay, and notifications do not work.

@@ -12,19 +12,19 @@ This problem is distinct from and probably more common than other problems affec

 1. When the new connection is created, the client already knows if it needs to create notification subscription or not, based on the conversation setting (e.g., if the group is muted, the client will not create notification subscription as well.). We should extend NEW command to avoid the need to send additional NKEY command with an option to create notification subscription at the point where connection is created. NDEL would still be used to disable this notification, and NKEY will be used to re-enable it.

-2. In the same way we stopped using SDEL command (NDEL sends notification DELD to subscribed notification server) to delete notificaiton subscriptions from notification server, we should delegate creating notification subscription on notification server to SMP servers. Clients could use keys agreed with ntf server for e2e encryption and for command authorization to encrypt and sign instruction to create notification subscription that will be forwarded to notification server using protocol similar to SMP proxies. This will avoid the need for clients to separately contact notification servers that won't happen until they are online.
+2. In the same way we stopped using SDEL command (NDEL sends notification DELD to subscribed notification router) to delete notificaiton subscriptions from notification router, we should delegate creating notification subscription on notification router to SMP routers. Clients could use keys agreed with ntf router for e2e encryption and for command authorization to encrypt and sign instruction to create notification subscription that will be forwarded to notification router using protocol similar to SMP proxies. This will avoid the need for clients to separately contact notification routers that won't happen until they are online.

-3. Instead of making Ntf server trust DELD notifications, we could send deletion instructions signed by the client, which will only fail to send in case notification server is down (and they won't be sent later after server restart).
+3. Instead of making Ntf router trust DELD notifications, we could send deletion instructions signed by the client, which will only fail to send in case notification router is down (and they won't be sent later after router restart).

 Cons:
- If SMP servers were to retain in the storage the information about which notification server is used for which queue, it would reduce metadata privacy. While currently it is not an issue, as all notification servers are known and operated by us, once there are other client apps, this can be used for app users fingerprinting, which would act as a deterrence from using new apps – but only if app users use servers of operators who are different from the app provider. To mitigate it, we could only store it in server memory and include notification instruction in subscription commands (SUB) and include notification subscription status in SUB responses. We don't need to mitigate the problem of server being able to store this information, as messaging servers can observe which notification servers connect to them anyway.
- If SMP server is restarted before the subscription request is forwared to the notification server, then it will have to be forwarded again, once the client subscribes. The problem here is that if the client is offline, it will neither subscribe to the queue to send notification subscription request, nor receive notifications from this queue. Storing notification server and subscription request would mitigate that, as in this case we could send all pending requests on server start, without depending on client subscriptions.
- "Small" agent will need to support connections to ntf servers and manage workers that retry sending pending subscription requests.
- Until the client learns the public keys of notification server, it will not be able to decrypt notifications. It potentially can be mitigated by using the public key of the server returned when token is created, in this way different client keys (per-queue) will be combined with the same ntf server key (per-token).
+- If SMP routers were to retain in the storage the information about which notification router is used for which queue, it would reduce metadata privacy. While currently it is not an issue, as all notification routers are known and operated by us, once there are other client apps, this can be used for app users fingerprinting, which would act as a deterrence from using new apps – but only if app users use routers of operators who are different from the app provider. To mitigate it, we could only store it in router memory and include notification instruction in subscription commands (SUB) and include notification subscription status in SUB responses. We don't need to mitigate the problem of router being able to store this information, as messaging routers can observe which notification routers connect to them anyway.
+- If SMP router is restarted before the subscription request is forwared to the notification router, then it will have to be forwarded again, once the client subscribes. The problem here is that if the client is offline, it will neither subscribe to the queue to send notification subscription request, nor receive notifications from this queue. Storing notification router and subscription request would mitigate that, as in this case we could send all pending requests on router start, without depending on client subscriptions.
+- "Small" agent will need to support connections to ntf routers and manage workers that retry sending pending subscription requests.
+- Until the client learns the public keys of notification router, it will not be able to decrypt notifications. It potentially can be mitigated by using the public key of the router returned when token is created, in this way different client keys (per-queue) will be combined with the same ntf router key (per-token).

 ## Implementation details

-1. NEW and NKEY commands will need to be extended to include notification subscription request. As the notifier ID needs to be sent to notification server, this notifier ID will have to be client-generated and supplied as part of NEW command.
+1. NEW and NKEY commands will need to be extended to include notification subscription request. As the notifier ID needs to be sent to notification router, this notifier ID will have to be client-generated and supplied as part of NEW command.

 now:

@@ -46,4 +46,4 @@ NKEY :: NtfPublicAuthKey -> RcvNtfPublicDhKey -> Maybe NtfServerRequest -> Comma
 -- NotifierID is passed in entity ID field of the transmission
 ```

-2. Notification server will need to support an additional command to receive "proxied" subscription commands, `SFWD`, that would include `NtfServerRequest`. This command can include both `SNEW` and `SDEL` commands.
+2. Notification router will need to support an additional command to receive "proxied" subscription commands, `SFWD`, that would include `NtfServerRequest`. This command can include both `SNEW` and `SDEL` commands.
@@ -5,7 +5,7 @@ This document evolves the design proposed [here](./2024-09-09-smp-blobs.md).
 ## Problems

 In addition to problems in the first doc, we have these issues with in-memory queue record storage:
- many queues are idle or rarely used, but they are loaded to memory, and currently just loading all queues uses 20gb RAM on each server, and takes 10 min to process, increasing downtimes during restarts.
+- many queues are idle or rarely used, but they are loaded to memory, and currently just loading all queues uses 20gb RAM on each router, and takes 10 min to process, increasing downtimes during restarts.
 - adding blobs to memory would make this problem much worse.

 ## Proposed solution
@@ -1,255 +0,0 @@
-# Protocol changes for creating and connecting to SMP queues
-
-## Problems
-
-This change is related to these problems:
- differentiating queue retention time,
- supporting MITM-resistant short connection links,
- improving notifications.
-
-This RFC is based on the previous discussions about short links, blob storage and notifications ([1](./2024-06-21-short-links.md), [2](./2024-09-09-smp-blobs.md), [3](./2024-11-25-queue-blobs-2.md), [4](./2024-09-25-ios-notifications-2.md)).
-
-SMP protocol supports two types of queues - queues to communicate over and queues to send invitations. While SMP protocol was originally "unaware" of these queue types, it could differentiate it by message flow, and with the recent addition of SKEY command to allow securing the queue by the sender this difference became persistent.
-
-Simply designating queue types would allow to use this information to decide for how long to retain queues, and potentially extending it:
- unsecured 1-time invitation queues with sndSecure (support of securing by sender) - e.g., 3 months.
- contact address queues without sndSecure - e.g., 3 years without activity.
- Possibly, "queues" that prohibit messages and used only as blob storage - they would be used to store group profiles and superpeer addresses for the group.
-
-This proposal also combines NEW and NKEY command to streamline notifications in preparation to reworking of the notifications protocol.
-
-## Design objectives
-
-We want to achieve these objectives:
-1. no possibility to provide incorrect SenderId inside link data (e.g. from another queue).
-2. link data cannot be accessed by the server unless it has the link.
-3. prevent MITM attack by the server, including the server that obtained the link.
-4. prevent changing of connection request by the user (to prevent MITM via break-in attack in the originating client).
-5. for one-time links, prevent accessing link data by link observers who did not compromise the server.
-6. allow changing the user-defined part of link data.
-7. avoid changing the link when user-defined part of link data changes, while preventing MITM attack by the server on user-defined part, even if it has the link.
-8. retain the quality that it is impossible to check the existense of secured queue from having any of its temporary visible IDs (sender ID and link ID in 1-time invitations) - it requires that these IDs remain server-generated (contrary to the previous RFCs).
-
-To achieve these objectives the queue data must have immutable part and mutable part.
-
-Immutable part would include:
- full conection request (the current long link with all keys, including PQ keys). This includes SenderId that must match server response.
- public signature key to verify mutable part of link data.
-
-Signed mutable part would inlcude:
- any links to chat relays that should be contacted instead of this queue (not in this RFC), but would allow delegating group connections and contact request connections to prevent spam, hiding online presense, etc.
- and user-defined data - user profile or group profile.
-
-The link itself should include both the key and auth tag from the encryption of immutable part. Accessing one-time link data should require providing sender key and signing the command (`LKEY`).
-
-## Solution
-
-Current NEW and NKEY commands:
-
-```haskell
-NEW :: RcvPublicAuthKey -> RcvPublicDhKey -> Maybe BasicAuth -> SubscriptionMode -> SenderCanSecure -> Command Recipient
-
-NKEY :: NtfPublicAuthKey -> RcvNtfPublicDhKey -> Command Recipient
-
-- | Queue IDs and keys, returned in IDS response
-data QueueIdsKeys = QIK
-  { rcvId :: RecipientId,
-    sndId :: SenderId,
-    rcvPublicDhKey :: RcvPublicDhKey,
-    sndSecure :: SenderCanSecure
-  }
-```
-
-Proposed NEW command replaces SenderCanSecure with QueueMode, adds link data, and combines NKEY command:
-
-```haskell
-NEW :: NewQueueRequest -> Command Recipient
-
-data NewQueueRequest = NewQueueRequest
-  { rcvAuthKey :: RcvPublicAuthKey,
-    rcvDhKey :: RcvPublicDhKey,
-    basicAuth :: Maybe BasicAuth,
-    subMode :: SubscriptionMode,
-    ntfRequest :: Maybe NtfRequest,
-    queueLink :: Maybe QueueLink -- it is Maybe to allow testing and staged roll-out
-  }
-
-- To allow updating the existing contact addresses without changing them.
-- This command would fail on queues that support sndSecure and also on new queues created with QLMessaging.
-- RecipientId is entity ID.
-- The response to this command is `OK`.
-LNEW :: LinkId -> QueueLinkData -> Command Recipient
-
-- Replaces NKEY command
-- This avoids additional command required from the client to enable notifications.
-- Further changes would move NotifierId generation to the client, and including a signed and encrypted command to be forwarded by SMP server to notification server.
-data NtfRequest = NtfRequest NtfPublicAuthKey RcvNtfPublicDhKey
-
-- QLMessaging implies that sender can secure the queue.
-- LinkId is not used with QLMessaging, to prevent the possibility of checking when connection is established by re-using the same link ID when creating another queue – the creating would have to fail if it is used.
-- LinkId is required with QLContact, to have shorter link - it will be derived from the link_uri. And in this case we do not need to prevent checks that this queue exists.
-data QueueLink = QLMessaging QueueLinkData | QLContact LinkId QueueLinkData
-
-data QueueLinkData = QueueLinkData EncImmutableDataBytes EncUserDataBytes
-
-newtype EncImmutableDataBytes = EncImmutableDataBytes ByteString
-
-newtype EncUserDataBytes = EncUserDataBytes ByteString
-
-- We need to use binary encoding for AConnectionRequestUri to reduce its size
-- connReq including the full link allows connection redundancy.
-- The clients would reject changed immutable data (based on auth tag in the link) and
-- AConnectionRequestUri where SenderId of the queue does not match.
-data ImmutableLinkData = ImmutableLinkData
-  { signature :: SignatureEd25519, -- signature of the remaining part of immutable data
-    connReq :: AConnectionRequestUri,
-    sigKey :: PublicKeyEd25519
-  }
-
-- This part of link data can also include any relays, but possibly we need a separate blob for it
-data UserLinkData = UserLinkData
-  { signature :: SignatureEd25519, -- signs the remaining part of the data
-    userData :: ByteString -- the max size needs to be estimated, but it is likely to be ~ 14kb
-  }
-
-- | Updated queue IDs and keys, returned in IDS response
-data QueueIdsKeys = QIK
-  { rcvId :: RecipientId, -- server-generated
-    sndId :: SenderId, -- server-generated
-    rcvPublicDhKey :: RcvPublicDhKey,
-    sndSecure :: SenderCanSecure, -- possibly, can be removed? or implied?
-    linkId :: Maybe LinkId, -- server-generated
-    serverNtfCreds :: Maybe ServerNtfCreds -- currently returned in NID response
-  }
-
-data ServerNtfCreds = ServerNtfCreds NotifierId RcvNtfPublicDhKey -- NotifierId is server-generated.
-```
-
-In addition to that we add the command allowing to update and also to retrieve and, optionally, secure the queue and get link data in one request, to have only one request:
-
-```haskell
-- With RecipientId as entity ID, the command to update mutable part of link data
-- The response is OK here.
-LSET :: EncUserDataBytes -> Command Recipient
-
-- To be used with 1-time links.
-- Sender's key provided on the first request prevents observers from undetectably accessing 1-time link data.
-- If queue mode is QLContact (and queue does NOT allow sndSecure) the command will fail, same as SKEY.
-- Once queue is secured, the key must be the same in subsequent requests - to allow retries in case of network failures, and to prevent passive attacks.
-- The difference with securing queues is that queues allow sending unsecured messages to queues that allow sndSecure (for backwards compatibility), and 1-time links will NOT allow retrieving link data without securing the queue at the same time, preventing undetected access by observers.
-- Entity ID is LinkId here
-LKEY :: SndPublicAuthKey -> Command Sender
-
-- If queue mode is QLMessaging the command will fail.
-- Entity ID is LinkId here
-LGET :: Command Sender
-
-- Response to LKEY and LGET
-- Entity ID is LinkId here
-LINK :: SenderId -> QueueLinkData -> BrokerMsg
-```
-
-## Algorithm to prepare and to interpret queue link data.
-
-For contact addresses this approach follows the design proposed in [Short links](./2024-06-21-short-links.md) RFC - when link id is derived from the same random binary as key. For 1-time invitations link ID is independent and server-generated, to prevent existense checks.
-
-**Prepare queue link data**
-
- the queue owner generates a random 256 bit `link_key` that will be used in the link URI.
- for 1-time links: crypto_box key and 2 nonces to encrypt link data are derived from link_uri using HKDF: `cb_key <> nonce1 <> nonce2 = HKDF(link_key, 80 bytes)` (nonce1 is used for immutable and nonce2 for user-defined parts).
- for contact address links: key and 2 nonces and linkId will be derived: `link_id <> cb_key <> nonce1 <> nonce2 = HKDF(link_key, 104 bytes)`
- both parts of link data are encrypted with crypto_box, and included into `NEW` or `LNEW` commands.
-
-**Retrieving queue link data**
-
- the sender uses `LinkId` from URI (or derived from URI) as entity ID to retrieve link data.
- for one time links the sender must authorize the request to retrieve the data, the key is provided with the first request, preventing undetected access by link observers.
- having received the link data, the client can now decrypt it using secret_box.
-
-## Threat model
-
-**Compromised SMP server**
-
-can:
- delete link data.
- hide link selectively from some requests.
-
-cannot:
- undetectably replace link data, even if they have the link (objective 3).
- access unencrypted link data, whether it was or was not accessed by the accepting party, provided it has no link (objective 2).
- observe IP addresses of the users accessing link data, if private routing is used.
-
-**Passive observer who observed short link**:
-
-can:
- access original unencrypted link data for contact address links.
-
-cannot:
- undetectably access observed 1-time link data, accessing the link would make the link inaccessible to the sender (objective 5).
- undetectbly check the existense of messaging queue or 1-time link (objective 8).
- replace or delete the link data.
-
-**Queue owner who did not comprmise the server**:
-
-cannot:
- redirect connecting user to another queue, on the same or on another server (objective 1).
- replace connection request in the link (objective 4).
-
-## Correlation of design objectives with design elements
-
-1. The presense of `SenderId` in `LINK` response from the server.
-2. Encryption of link data with crypto_box.
-3. Auth tag in the link prevents server modification of immutable part of link data. Signature verification key in immutable part, and signing of mutable part prevents server modification of mutable part of link data.
-4. No server command to change immutable part of link data once it's set.
-5. 1-time link data can only be accessed with `LKEY` command, that while allows retries to mitigate network failures, will require the same key for retries.
-6. `LSET` command.
-7. The link only includes auth tag for immutable part, mutable part includes signature.
-8. Temporarily public IDs (SenderId and LinkId for 1-time invitations) are generated server-side, and cannot be provided by the clients when creating the queues to check if these IDs are free.
-
-## Syntax for short links
-
-The proposed syntax:
-
-```abnf
-shortConnectionLink = %s"https://" smpServerHost "/" linkUri [ "?" param *( "&" param ) ]
-smpServerHost = <hostname> ; RFC1123, RFC5891
-linkUri = %s"i#" serverInfo oneTimeLinkBytes / %s"c#" serverInfo contactLinkBytes
-oneTimeLinkBytes = <base64url(linkId | linkKey | linkAuthTag)> ; 60 bytes / 80 base64 encoded characters
-contactLinkBytes = <base64url(linkKey | linkAuthTag)> ; 48 bytes / 64 base64 encoded characters
-; linkId - 96 bits/24 bytes
-; linkKey - 256 bits/32 bytes
-; linkAuthTag - 128 bits/16 bytes auth tag from encryption of immutable link data>
-
-serverInfo = [fingerprint "@" [hostnames "/"]] ; not needed for preset servers, required otherwise - the clients must refuse to connect if they don't have fingerprint in the code.
-
-fingerprint = <base64url(server offline certificate fingerprint)>
-hostnames = "h=" <hostname> *( "," <hostname> ) ; additional hostnames, e.g. onion
-```
-
-To have shorter links fingerpring and additional server hostnames do not need to be specified for preconfigured servers, even if they are disabled - they can be used from the client code. Any user defined servers will require including additional hosts and server fingerprint.
-
-Example one-time link for preset server (108 characters):
-
-```
-https://smp12.simplex.im/i#abcdefghij0123456789abcdefghij0123456789abcdefghij0123456789abcdefghij0123456789
-```
-
-Example contact link for preset server (92 characters):
-
-```
-https://smp12.simplex.im/c#abcdefghij0123456789abcdefghij0123456789abcdefghij0123456789abcd
-```
-
-Example contact link for user-defined server (with fingerprint, but without onion hostname - 136 characters):
-
-```
-https://smp1.example.com/c#0YuTwO05YJWS8rkjn9eLJDjQhFKvIYd8d4xG8X1blIU@abcdefghij0123456789abcdefghij0123456789abcdefghij0123456789abcd
-```
-
-Example contact link for user-defined server (with fingerprint ant onion hostname - 199 characters):
-
-```
-https://smp1.example.com/c#0YuTwO05YJWS8rkjn9eLJDjQhFKvIYd8d4xG8X1blIU@beccx4yfxxbvyhqypaavemqurytl6hozr47wfc7uuecacjqdvwpw2xid.onion/abcdefghij0123456789abcdefghij0123456789abcdefghij0123456789abcd
-```
-
-For the links to work in the browser the servers must provide server pages.
@@ -0,0 +1,93 @@
+# New notifications protocol
+
+## Problem
+
+iOS notifications have these problems:
+- iOS notification service crashes exceeding memory limit. This is being addressed by changes in GHC RTS.
+- there is a large number of connections, because each member in a group requires individual connection. This will improve with chat relays when each group would require 2-3 connections.
+- some notification may be not shown if notification with reply/mention is skipped, and instead some other message is delivered, which may be muted. This would not improve without some changes, as notifications may be skipped anyway.
+- client devices delay communication with ntf router because it is done in background, and by that time the app may be suspended.
+- notification router represents a bottleneck, as it has to be owned by the app vendor, and the current design when ntf router subscribes to notifications scales very badly.
+
+This RFC is based on the previous [RFC related to notifications](./2024-09-25-ios-notifications-2.md).
+
+## Solution
+
+As notification router has to know client token and currently it associates subscriptions with this token anyway, we are not gaining any privacy and security by using per-subscription keys - both authorization and encryption keys of notification subscription can be dropped.
+
+We still need to store the list of queue IDs associated with the token on the notification router, but we do not need any per-queue keys on the notification router, and we don't need subscriptions - it's effectively a simple set of IDs, with no other information.
+
+In this case, when queue is created the client would supply notifier ID - it has to be derived from correlation ID, to prevent existense check (see previous RFC). As we also supply sender ID, instead of deriving it as sha3-192 of correlation ID, they both can be derived as sha3-384 and split to two IDs - 24 bytes each.
+
+The notification router will maintain a rotating list of router keys with the latest key communicated to the client every time the token is registered and checked. The keys would expire after, say, 1 week or 1 month, and removed from notification router on expiration.
+
+The packet containing association between notifier queue ID and token will be crypto_box encrypted using key agreement between identified notification router master key and an ephemeral per packet (effectively, per-queue) client-key.
+
+Deleting the queue may also include encrypted packet that would verify that the client deleted the queue.
+
+Instead of notification router subscribing to the notifications creating a lot of traffic for the queues without messages, the SMP router would push notifications via NTF router connection (whether via NTF or via SMP protocol). This could be used as a mechanism to migrate existing queues when with the next subscription the notification router would communicate it's address to SMP router and this association would be stored together with the queue.
+
+## Protocol design
+
+Additional/changed SMP commands:
+
+```haskell
+-- register notification router
+-- should be signed with router key
+NSRV :: NtfServerCreds -> Command NtfServer
+
+-- response
+NSID :: NtfServerId -> BrokerMsg
+
+-- to communicate which router is responsible for the queue
+-- should be signed with queue key
+NSUB :: Maybe NtfServerId -> Command Notifier
+
+-- subscribe to notificaions from all queues associated with the router
+-- should be signed with router key
+-- entity ID - NtfServerId
+NSSUB :: Command NtfServer
+
+data NtfServerCreds = NtfServerCreds
+  { server :: NtfServer,
+    -- NTF router certificate chain that should match fingerpring in address
+    cert :: X.CertificateChain,
+    -- router autorizatio key to sign router subscription requests
+    authKey :: X.SignedExact X.PubKey
+  }
+
+-- entity ID is recipient ID
+NSKEY :: NtfSubscription -> Command Recipient
+
+data NtfSubscription = NtfSubscription
+  -- key to encrypt notifications e2e with the client
+  { ntfPubDbKey :: RcvNtfPublicDhKey,
+    ntfServer :: NtfServer,
+    -- should be linked to correlation ID to prevent existense check
+    -- the ID sent to notification router could be its hash?
+    ntfId :: NotifierId,
+    encNtfTokenAssoc :: EncDataBytes
+  }
+
+-- before the encryption - equivalent to NSUB command, but without key to authorize requests to specific queue
+data NtfTokenAssoc = NtfTokenAssoc
+  { signature :: SignatureEd25519,
+    tknId :: NtfTokenId,
+    ntfQueue :: SMPQueueNtf
+  }
+```
+
+SMP router will need to maintain the list of Ntf routers and their credentials, and when NSSUB arrives to make only one subscription. When message arrives it would deliver notification to the correct connection via queue / ntf router association.
+
+Ntf router needs to maintain three indices to the same data:
+- `(smpServer, queueId) -> tokenId` - to deliver notification to the correct token
+- `tokenId -> [smpServer -> [queueId]]` - to remove all queues when token is removed, and to store/update these associations effficiently - store log may have one compact line per token (after compacting), or per token/router combination.
+- `[smpServer]` - array of SMP routers to subscribe to.
+
+## Mention notifications
+
+Currently we are marking messages with T (true) for messages that require notifications and F (false) for messages that don't require. Sender does not know whether the recipient has notifications disabled, enabled or in mentions-only mode.
+
+The proposal is to:
+- add additional values to this metadata, e.g. 2 (priority) and 3 (high priority) (and T/F could be sent as 0/1 respectively) - that is, to deliver notifications even if notifications are generally disabled (they can still be further filtered by the client).
+- instead of deleting notification credentials when notifications are disabled - which is costly - communicate to SMP router the change of notificaion priority level, e.g. the client could set minimal notification priority to deliver notifications, where 0 would mean disabling it completely, 1 enable for all, 2 for priority 2+, 3 for priority 3. The downside here is that it could be used for timing correlation of queues in the group, but it already can be used on bulk deletions of ntf credentials for these queues and when sending messages.
@@ -0,0 +1,159 @@
+# Using short links as group links
+
+## Problem
+
+To use the short links for groups these problems has to be / can be solved:
+1. recognizing link as a group link.
+2. permanent link with the ability to change chat relays.
+3. binding owners signatures to the link.
+4. allowing to add/remove owners, both to share ownership and for reliability in case of one owner losing keys/access.
+
+While current short links solve problems 1-3 (via contact type, and via extension of user data in the link), the problem 4 is solved only partially.
+
+We could include the current list of root owners in the user data, and we could send any history of ownership changes from this baseline as a short blockchain on joining the group, we still requrie one master owner to retain access to the queue associated with the group.
+
+## Possible solution approaches
+
+1. "Kick this can down the road" - ignore this problem until there is a namespace, and a group name can be associated with multiple queues.
+
+Pros: simple and reasonable, and it suggests postponing multisig for owners too. The users can still see the list of owners and their keys in user data of the link, and receive admin roster signed by owners on joining.
+
+Cons: if this "master owner" loses the access to the device, no further changes to group profile will be possible.
+
+2. The queue access can be shared by sharing the key and recipient IDs with all owners.
+
+The problems:
+- preventing MITM attack between owners (this protect exists for other solutions too).
+- protecting these credentials from chat relays. So somehow there should be direct key agreement between members allowing to send e2e encrypted message inaccessible to chat relays.
+
+Pros: simpler than alternatives, and still provides protection against losing the key.
+Cons:
+- quite clunky, and requires the new primitive anyway (e2e encryption).
+- no multisig
+
+This could possibly be evolved into the requirement to have a direct connection with other owners, and verifying the security code before they have access to group.
+
+3. Allow "joint management" of SMP queues.
+
+SMP routers can support multiple recipients for contact queues:\
+- subscription would be possible to the "subscriber recipient".
+- all other changes (update data, change subscriber recipient, add or remove recipients) would require multiple recipient signatures on SMP command in line with n-of-m multisig rules, that the command sender would have to collect out-of-band (from SMP protocol point of view).
+
+Pros: allows joint ownership, and protects from losing access to master owner device.
+Cons:
+- complicates queue abstraction with approach that is not needed for most queues.
+- still retains the router as a single point of failure.
+
+4. Introduce "group" as a new type of entity managed by SMP routers.
+
+SMP routers would provide a separate set of commands for managing group records that would include in an encrypted container:
+- the group profile
+- the list of chat relay links
+- the list of owner member IDs with their public keys
+- multisig rules
+- alternative group entity locations
+- possibly, a globally unique group identity (as the hash of the initial/seed group data).
+
+While the router domain would be used as the hostname in group link, it may contain alternative hosts (not just hostnames of the same router), both in the link and in the group record data.
+
+Pros: separates additional complexity to where it is needed, allowing reliability and redundancy for group ownership.
+Cons: complexity, coupling between SMP and chat protocol.
+
+## Design for channel/group as a separate queue mode
+
+Option 1.
+
+A queue mode "channel" when owners are represented by their individual queues (either a separate mode, or a submode of "channel", or just normal contact address queues). In this case sending message to channel queue would broadcast message to queue owners, without exposing even the number of owners.
+
+Pros:
+- allows chat relays to send messages to all owners (e.g., channel can be secured with the list of snd keys, one per relay).
+- quite easy to evolve from the current design.
+- extensible.
+Cons:
+- close to "solution in search of a problem".
+- does not require data model changes - channel queue would simply have a list of owner "recipient IDs", and each owner queue would also point to channel.
+
+Option 2.
+
+Also a separate queue mode "channel", but instead of having a linked owner queues, it would simply maintain a list of owner keys to maintain the data. In this case, messages cannot be sent to this "queue" at all.
+
+Pros:
+- simpler design.
+- we could allow sending messages to it too, with the "main" owner receiving them. This could be negotiated in the protocol.
+- it may be easier to migrate the current groups, as the admin link would be this queue (although for public groups in directory it would have to be recreated anyway).
+- Possibly, when queue is created there should be a flag whether it should accept unsigned messages - then contact addresses would be created with unsigned messages ON, messages queues, once SKEY is universally supported, with unsigned messages OFF, and channel queues with unsigned messages OFF too for new public queues.
+Cons:
+- if no messages are accepted, this is not even a queue.
+- no way to directly contact owners (maybe it is not a downside, as for relays there would be a communication channel anyway as part of the group).
+
+Option 2 looks more simple and attractive, implementing router broadcast for SMP seems unnecessary, as while it could have been used for simple groups, it does not solve such problems as spam and pre-moderation anyway - it requires a higher level protocol.
+
+The command to update owner keys would be `RKEY` with the list of keys, and we can make `NEW` accept multiple keys too, although the use case here is less clear.
+
+## Multiple owners managing queue data.
+
+Option 1: Use the same keys in SMP as when signing queue data.
+
+Option 2: Use different keys.
+
+The value here could be that the router could validate these signatures too, and also maintain the chain of key changes. While tempting, it is probably unnecessary, and this chain of ownership is better to be maintained on chat relay level, as there are no size constraints on the size of this chain. Also, it is better for metadata privacy to not couple transport and chat protocol keys.
+
+We still need to bind the mutable data updates to the "genesis" signature key (the one included in the immutable data).
+
+The proposed design:
+
+- when mutable data is signed by genesis key, then it is bound, and no changes is needed.
+- mutable data may be signed by the key of the new owner, in which case mutable part itself must contain the binding. We could also use ring signature to sign the mutable data, concealing which owner signed the data - that would increase the signature size from 64 bytes to `32 * (n + 1)` bytes.
+
+Current mutable data:
+
+```haskell
+data UserLinkData = UserLinkData
+  { agentVRange :: VersionRangeSMPA,
+    userData :: ConnInfo
+  }
+```
+
+Proposed mutable data:
+
+```haskell
+data UserLinkData = UserLinkData
+  { agentVRange :: VersionRangeSMPA,
+    owners :: [OwnerInfo]
+    userData :: ConnInfo
+  }
+
+type OwnerId = ByteString
+
+data OwnerInfo = OwnerInfo
+  { ownerId :: OwnerId, -- unique in the list, application specific - e.g., MemberId
+    ownerKey :: PublicKeyEd25519,
+    -- owner signature of sender ID,
+    -- confirms that the owner agreed with being the owner,
+    -- prevents a member being added as an owner without consent.
+    ownerSig :: SignatureEd25519,
+    -- owner authorization, sig(ownerId || ownerKey, prevKey), where prevKey is either a "genesis key" or some other key previously signed by the genesis key.
+    authOwnerId :: OwnerId, -- null for "genesis"
+    authOwnerSig :: SignatureEd25519
+  }
+```
+
+The size of the OwnerInfo record encoding is:
+- ownerId: 1 + 12
+- ownerKey: 1 + 32
+- ownerSig: 1 + 64
+- ownerAuthId: 1 + 12
+- ownerAuthSig: 1 + 64
+
+~189 bytes, so we should practically limit the number of owners to say 8 - 1 original + 7 addiitonal. Original creator could use a different key as a "genesis" key, to conceal creator identity from other members, and it needs to include the record with memberId anyway.
+
+The structure is simplified, and it does not allow arbitrary ownership changes. Its purpose is not to comprehensively manage ownership changes - while it is possible with a generic blockchain, it seems not appropriate at this stage, - but rather to ensure access continuity and that the router cannot modify the data (although nothing prevents the router from removing the data completely or from serving the previous version of the data).
+
+For example it would only allow any given owner to remove subsequenty added owners, preserving the group link and identity, but it won't allow removing owners that signed this owner authorization. So owners are not equal, with the creator having the highest rank and being able to remove all additional owners, and owners authorise by creator can remove all other owners but themselves and creator, and so on - they have to maintain the chain that authorized themselves, at least. We could explicitely include owner rank into OwnerInfo, or we could require that they are sorted by rank, or the rank can be simply derived from signatures.
+
+When additional owners want to be added to the group, they would have to provide any of the current owners:
+- the key for SMP commands authorization - this will be passed to SMP router together with other keys. There could be either RKEY to pass all keys (some risk to miss some, or of race conditions), or RADD/RGET/RDEL to add and remove recipient keys, which has no risk of race conditions.
+- the signature of the immutable data by their member key included in their profile.
+- the current owner would then include their member key into the queue data, and update it with LSET command. In any case there should be some simple consensus protocol between owners for owner changes, and it has to be maintained as a blockchain by owners and by chat relays, as otherwise it may lead to race conditions with LSET command.
+
+Potentially, there could be one command to update keys and link data, so that they are consistent.
@@ -0,0 +1,104 @@
+# Using the same profile from multiple devices
+
+## Problem
+
+Double Ratchet algorithm makes it hard to send/receive messages sent to the user from different devices, as each message changes the state of Double Ratchet keys, and these state changes must be strictly sequential and they cannot be reversed (although skipping is possible).
+
+Traditional approach for multi-device converts each direct conversation into a group, where each device participates as a member. Likewise, for group conversations each device also participates as a member. While these members *look* as if they are the same user to others, a very simple client app modification may show device ID for each message, and the communication peers, both in direct chats and in groups would know how many devices a user has and which device the user sent the message from. In addition to that, with this approach communication peers can send different messages to different devices (it can be prevented by provider who would request that only message key is encrypted with DR, while the encrypted message is the same) or withheld from some devices (it cannot be prevented by provider, as it cannot add key to the communication in case it is missing, and cannot withhold the message completely too). These opens various vectors for targeted attacks, e.g.:
+- tracking movements of the user: once each devices is identified as "desk" and "phone" it would allow to know where the user is at a given time.
+- manipulating information by sending messages to one device (to have proof it was sent) and withholding from others, or sending different messages if the protocol allows it.
+
+In addition to that, the specific implementation of this approach in Signal compromises break-in recovery property (aka post-compromise security) of Double-Ratchet algorithm, making its design ineffective - the only reason to have the second ratchet in DR algorithm is to provide break-in recovery, without it a much simpler design with a single ratchet is sufficient. See [this paper](https://eprint.iacr.org/2021/626.pdf) for details.
+
+While this limitation can be addressed with notifications when a new device is added and per-device keys, we still find the remaining attack vectors on user security and privacy to be unacceptable, and opening unsuspecting users to various criminal actions - and it is wrong to say that would only affect security conscious users, and most people would not be affected by these risks. Allowing potential criminals in groups to know which device you are currently using is a real risk for all users.
+
+Another approach was offered by Threema that is ["mediator" router](https://threema.com/en/blog/md-architectural-overview) where the state of encryption ratchets is stored router-side. While it protects the user from their communication peers, it increases required level of trust to the routers, and in case of SimpleX network it would expose the knowledge of who communicates to whom. So while the idea of router-side storage of encryption state is promising, it has to be per-connection, to retain "no-accounts" property of SimpleX messaging network.
+
+Also see [FAQ](https://simplex.chat/faq/#why-cant-i-use-the-same-profile-on-different-devices) and [this issue](https://github.com/simplex-chat/simplex-chat/issues/444#issuecomment-3066968358).
+
+## Proposed solution
+
+One of the ideas presented in FAQ - to store the state of Double Ratchet algorithm in the encrypted container on the router seems promising. The RFC develops this idea.
+
+### Considerations for the design
+
+1. The largest ratchet state size with the current implementation is less than 8kb (which is achieved when both sides shared PQ keys and ciphertexts), so while it cannot fit in the same transport blocks together with sent and received messages, it would fit in one transport block.
+
+2. Protocol commands and events may be changed (even if at the cost of slightly reducing message size) can fit the hash of the ratchet state (32 bytes sha256 would be sufficient), so that the client can determine whether it has the most recent ratchet state or if it needs to retrieve the latest copy. Message size reduction won't affect the users because we use compression, and there is a substantial reserve.
+
+3. Client commands that modify ratchet state would include the hash of the previous ratchet state so that the router can reject or ignore the command in case the previous ratchet state is different or in case command is repeated in case of lost response).
+
+4. The client does not need to retrieve message state for each encryption and decryption operation - it can "speculatively" use the ratchet state it has, and receive correct ratchet state in the "error" response after attempting encryption based on incorrect ratchet state.
+
+## Proposed protocol design
+
+Ratchet state will be stored on the same router that stores message queue, as part of message queue record. 8kb is a sufficient size for this blob (the actual max size is 7800 bytes). The router would also store the hashes of the current and, possibly, the previous ratchet states (TBC).
+
+While ratchet is used for duplex connection, the connection still has primary queue, and with redundancy the same ratchet state can be stored on all secondary queues.
+
+Ratchet state will be encrypted using secret_box - a symmetric encryption scheme, so PQ-resistant. If ratchet state is stored on more than one router, it has to be encrypted with a different key for each router.
+
+Questions: how to rotate the key used to store ratchet? Should key used to encrypt ratchet rotate at the same time when queue is rotated? The latter is a logical option, as it prevents additional complexity and solves the problem anyway. A possible option is to have "ratchet version" that will be used to advance the key used to encrypt ratchet via HKDF.
+
+Security considerations: the scheme may reduce break-in recovery to the points queues are rotated, unless there is some randomness mixed-in into the key derivation (the key used to encrypt ratchet state). But including randomness would defeat the purpose, as other devices wouldn't be able to access the ratchets. Another approach would be to have each device use its own key for encryption, and encrypt to all keys of all devices (or to encrypt key, to avoid size increase). Having multiple encryptions would show how many devices use the queue, but routers already can observe it, so it is a better tradeoff. Another idea would be to rotate the key used to authorize queue commands - we already support multiple recipient keys, and it can be used for multi-device scenario. That would partially mitigate break-in attacks as the attacker who obtained the key from ratchet state would be able to decrypt it, but won't be able to decrypt it (the attacker collusion with the router is not mitigated). Yet another idea would be for each party (device) to share its private (or encapsulation) key and to have a symmetric key (used to encrypt the ratchet state) encrypted (encapsulated) separately for each device. This would reduce the size of the stored data to `ratchet size` + `encrypted key size` * N, so even in case of PQ encryption (e.g. sntrup) the size required to store the ratchet would be under transport block size, while limiting it to say 4-8 devices, which is sufficient.
+
+To participate in multi-device scheme the devices would join the usual group that will be used to share public (encapsulation) device keys and to communicate updates to conversations that were received by the currently "active" device. "Active" means the device that received or sent and processed the message, and while only one device can receive messages from a given queue, device "active" state may be determined per queue, allowing concurrent usage.
+
+The scheme must be resilient to state updates being lost, and in case of direct messages it would result in some messages not being shown (or shown as skipped), while conversation preference and profile updates can be re-requested from peers, while the current profile of the user would become the latest. Likewise, for groups state updates ca be requested from super-peers or for decentralized groups - from owners. Maintaining chat state consistency is an important consideration, but is not a focus of this RFC - the focus is managing message delivery and DR encryption for multiple devices. Other multi-device schemes have the same issues with state consistency. Partially, the profile state consistency can be improved by using a single shared queue (or set of queues) to store user's profile and chat preferences to synchronize profile updates asynchronously between the devices.
+
+## The protocol to send the message
+
+`rsi` - ratchet state on device `i`.
+
+`enc(rs)` - current authoritative ratchet state on the router.
+
+`pt` and `ct` - plaintext and ciphertext messages.
+
+Encryption is a state transition function ratchetEnc: `(ct, rs') = ratchetEnc(pt, rs)`.
+
+1. Device encrypts the message using the stored ratchet state: `(ct, rsi') = ratchetEnc(pt, rsi)`
+
+2. Device sends modified encrypted ratchet state and the hash of the previous encrypted state to the router that stores the queue: `RSET (hash(enc(rsi)), enc(rsi'))`.
+
+3. If the hash of the previous state matches state stored on the router (`hash(enc(rsi)) == hash(enc(rs))`), the router updates the state and responds with `ratchet_ok` (that may include the current state or it's hash, for validation). If the hash is different, the router responds with `bad_ratchet(enc(rs))` message that includes the correct ratchet state. These updates must be atomic. In this case device has to update the local ratchet state (provided it can decrypt it), and repeat encryption attempt. If device cannot decrypt the provided ratchet state, it means that the connection is disrupted (possibly, device is removed from device group, but missed the notifications).
+
+4. After successful state update in primary receiving queue, the device would update it in secondary receiving queues.
+
+5. Device sends encrypted message as usual, via proxy that must be different both from the router that stores the ratchet and from the destination router.
+
+6. Device broadcasts sent message and new ratchet state to other devices in the device group.
+
+This protocol is simple, and it minimizes requests when sending the message to one additional request to update ratchet state in most cases, only requiring two requests when device state was not updated via device group prior to message sending attempt.
+
+## The protocol to receive the message
+
+Decryption is also a state transition function: `(pt, rs') = ratchetDec(ct, rs)`
+
+1. Router sends the message to the device (can be in response to SUB or ACK commands, or with active subscription). Pushed message would include the hash of the currently stored ratchet state: `hash(enc(rs))`.
+
+2. If device has the ratchet state with the same hash (`hash(enc(rs)) == hash(enc(rsi))`), it decrypts the message: `(pt, rsi') = ratchetDec(ct, rsi)`.
+
+3. If device has ratchet state with a different hash, it requests ratchet from the router with additional protocol command `RGET` with response `RCHT (enc(rs))` and updates the local state.
+
+4. Device decrypts the message `(pt, rsi') = ratchetDec(ct, rsi)` and processes it as usual.
+
+5. Device sends acknowledgement to the router as usual, but now it includes the new ratchet state and the hash of the previous state: `ACK msgId (hash(enc(rsi)), enc(rsi'))`
+
+6. The router compares ratchet state with stored state hash, and in case it matches it processes `ACK` and responds with `OK` as usual (or `NO_MSG` in case msgId is incorrect, also as usual - it would happen in repeated ACK requests). If ratchet state hash does not match, the router would respond with `bad_ratchet(enc(rs))` - which means that the message was already processed by another device and ratchet was advanced. This is a complex scenario, as the client has to either revert the change from message processing or somehow combine the change with the updates communicated via device group (as a side note, device group can simply re-broadcast messages, not state updates, but it will result in state divergence between devices when different messages are lost).
+
+Unlike sending messages, this flow does not require any additional requests in most cases, only requiring requesting message state reconciliation when the same message was received and processed by more than one client, but it does not require re-acknowledgement.
+
+## Challenges
+
+This is an idea of the design rather than the actual design, as it requires more thinking about:
+- how to handle concurrent ratchet state updates,
+- "active" status transitions per queue,
+- avoiding concurrent subscriptions to queues from multiple devices,
+- state updates and synchronization between devices,
+- handling skipped messages,
+- costs to update ratchets in bulk send scenario - this scheme would substantially increase costs of preparing large broadcasts, and it makes this scheme not acceptable for chat relays. Which means that "profile" on desktop used as chat relay won't be synched to other devices.
+- etc.
+
+## Advantages
+
+The communication peers won't know how many devices the user has, and which device was used to send the message. Also, the communication peers won't be able to send different messages to different user's devices, or to withhold messages from some devices.
@@ -0,0 +1,101 @@
+# Detecting and fixing state with service subscriptions
+
+## Problem
+
+While service certificates and subscriptions hugely decrease startup time and delivery delays on router restarts, they introduce the risk of losing subscriptions in case of state drifts. They also do not provide efficient mechanism for validating that the list of subscribed queues is in sync.
+
+How can the state drift happen?
+
+There are several possibilities:
+- lost broker response would make the broker consider that the queue is associated, but the client won't know it, and will have to re-associate. While in itself it is not a problem, as it'll be resolved, it would make drift detected more frequently (regardless of the detection logic used). That service certificates are used on clients with good connection would make it less likely though.
+- router state restored from the backup, in case of some failure. Nothing can be done to recover lost queues, but we may restore lost service associations.
+- queue blocking or removal by router operator because of policy violation.
+- router downgrade (when it loses all service associations) with subsequent upgrade - the client would think queues are associated, while they are not, and won't receive any messages at all in this scenario.
+- any other router-side error or logic error.
+
+In addition to the possibility of the drift, we simply need to have confidence that service subscriptions work as intended, without skipping queues. We ignored this consideration for notifications, as the tolerance to lost notifications is higher, but we can't ignore it for messages.
+
+## Solution
+
+Previously considered approach of sending NIL to all queues without messages is very expensive for traffic (most queues don't have messages), and it is also very expensive to detect and validate drift in the client because of asynchronous / concurrent events.
+
+We cannot read all queues into memory, and we cannot aggregate all responses in memory, and we cannot create database writes on every single service subscription to say 1m queues (a realistic number), as it simply won't work well even at the current scale.
+
+An approach of having an efficient way to detect drift, but load the full list of IDs when drift is detected, also won't work well, as drifts may be common, so we need both efficient way to detect there is diff and also to reconcile it.
+
+### Drift detection
+
+Both client and router would maintain the number of associated queues and the "symmetric" hash over the set of queue IDs. The requirements for this hash algorithm are:
+- not cryptographically strong, to be fast.
+- 128 bits to minimize collisions over the large set of millions of queues.
+- symmetric - the result should not depend on ID order.
+- allows fast additions and removals.
+
+In this way, every time association is added or removed (including queue marked as deleted), both peers would recompute this hash in the same transaction.
+
+The client would suspend sending and processing any other commands on the router and the queues of this router until SOKS response is received from this router, to prevent drift. It can be achieved with per-router semaphores/locks in memory. UI clients need to become responsive sooner than these responses are received, but we do not service certificates on UI clients, and chat relays may prevent operations on router queues until SOKS response is received.
+
+SOKS response would include both the count of associated queues (as now) and the hash over all associated queue IDs (to be added). If both count and hash match, the client will not do anything. If either does not match the client would perform full sync (see below).
+
+There is a value from doing the same in notification router as well to detect and "fix" drifts.
+
+The algorithm to compute hashes can be the following.
+
+1. Compute hash of each queue ID using xxHash3_128 ([xxhash-ffi](https://hackage.haskell.org/package/xxhash-ffi) library). They don't need to be stored or loaded at once, initially, it can be done with streaming if it is detected on start that there is no pre-computed hash.
+2. Combine hashes using XOR. XOR is both commutative and associative, so it would produce the same aggregate hash irrespective of the ID order.
+3. Adding queue ID to pre-computed hash requires a single XOR with ID hash: `new_aggregate = aggregate XOR hash(queue_id)`.
+4. Removing queue ID from pre-computed hash also requires the same XOR (XOR is involutory, it undoes itself): `new_aggregate = aggregate XOR hash(queue_id)`.
+
+These hashes need to be computed per user/router in the client and per service certificate in the router - on startup both have to validate and compute them once if necessary.
+
+There can be also a start-up option to recompute hashe(s) to detect and fix any errors.
+
+This is all rather simple and would help detecting drifts.
+
+### Synchronization when drift is detected
+
+The assumption here is that in most cases drifts are rare, and isolated to few IDs (e.g., this is the case with notification router).
+
+But the algorithm should be resilient to losing all associations, and it should not be substantially worse than simply restoring all associations or loading all IDs.
+
+We have `c_n` and `c_hash` for client-side count and hash of queue IDs and `s_n` and `s_hash` for router-side, which are returned in SOKS response to SUBS command.
+
+1. If `c_n /= s_n || c_hash /= s_hash`, the client must perform sync.
+
+2. If `abs(c_n - s_n) / max(c_n, s_n) > 0.5`, the client will request the full list of queues (more than half of the queues are different), and will perform diff with the queues it has. While performing the diff the client will continue block operations with this user/router.
+
+3. Otherwise would perform some algorithm for determining the difference between queue IDs between client and router. This algorithm can be made efficient (`O(log N)`) by relying on efficient sorting of IDs and database loading of ranges, via computing and communicating hashes of ranges, and performing a binary search on ranges, with batching to optimize network traffic.
+
+This algorithm is similar to Merkle tree reconcilliation, but it is optimized for database reading of ordered ranges, and for our 16kb block size to minimize network requests.
+
+The algorithm:
+1. The client would request all ranges from the router.
+2. The router would compute hashes for N ranges of IDs and send them to the client. Each range would include start_id, optional end_id (for single ID ranges) and XOR-hash of the range. N is determined based on the block size and the range size.
+3. The client would perform the same computation for the same ranges, and compare them with the returned ranges from the router, while detecting any gaps between ranges and missing range boundaries.
+4. If more than half of the ranges don't match, the client would request the full list. Otherwise it would repeat the same algorithm for each mismatched range and for gaps.
+
+It can be further optimized by merging adjacent ranges and by batching all range requests, it is quite simple.
+
+Once the client determines the list of missing and extra queues it can:
+- create associations (via SUB) for missing queues,
+- request removal of association (a new command, e.g. BUS) for extra queues on the router.
+
+The pseudocode for the algorightm:
+
+For the router to return all ranges or subranges of requested range:
+
+```haskell
+getSubRanges :: Maybe (RecipientId, RecipientId) -> [(RecipientId, Maybe RecipientId, Hash)]
+getSubRanges range_ = do
+  ((min_id, max_id), s_n) <- case range_ of
+    Nothing -> getAssociatedQueueRange -- with the certificate in the client session.
+    Just range -> (range,) <$> getAssociatedQueueCount range
+    if
+      | s_n <= max_N -> reply_with_single_queue_ranges
+      | otherwise -> do
+          let range_size = s_n `div` max_N
+          read_all_ranges -- in a recursive loop, with max_id, range_hash and next_min_id in each step
+          reply_ranges
+```
+
+We don't need to implement this synchronization logic right now, so not including client logic here, it's sufficient to implement drift detection, and the action to fix the drift would be to disable and to re-enable certificates via some command-line parameter of CLI.
@@ -0,0 +1,90 @@
+# Subscription performance
+
+No protocol changes. This is an implementation RFC addressing subscription performance bottlenecks in both the SMP router and the agent.
+
+## Problem
+
+Subscribing large numbers of queues is slow. A messaging client with ~300K queues per router across 3 routers takes over 1 hour to subscribe. For comparison, the NTF server with ~1M queues per router across 12 routers took 20-30 minutes (prior to NTF client services, now in master).
+
+Even on fast networks (cloud VMs), a client with 1.1M active subscriptions needed ~1.5M attempts (commands sent) to fully subscribe - ~36% retry rate caused by the timeout cascade described below.
+
+### Root causes
+
+#### 1. Router: per-command processing in batches
+
+Batch verification and queue lookups are already done efficiently for the whole batch in `Server.hs`. But `processCommand` is called per-command in a loop - each SUB does its own individual DB query for message peek/delivery. With ~135 SUBs per batch (current SMP version), that's 135 individual DB queries per batch instead of 1 batched query.
+
+For 300K queues, that's ~2200 batches x 135 queries = ~300K individual DB queries on the router, which is the dominant bottleneck when using PostgreSQL storage.
+
+NSUB is cheaper because it just registers for notifications without message delivery - no per-queue DB query.
+
+#### 2. Agent: all queues read and sent at once
+
+`getUserServerRcvQueueSubs` reads all queues for a `(userId, server)` pair in one query with no LIMIT. For 300K queues, the entire result set is loaded into memory, then all ~2200 batches are queued to send without waiting for responses.
+
+The NTF server agent uses cursor-style reading with configurable batch sizes (900 subs per chunk, 90K per DB fetch) and waits for each chunk to be processed before fetching the next.
+
+#### 3. No backpressure on sends
+
+`nonBlockingWriteTBQueue` bypasses the `sndQ` bound by forking a thread when the queue is full. All batches are queued immediately, and all their response timers start simultaneously. A 30-second per-response timeout means later batches time out not because the router is slow to respond to them specifically, but because they're waiting in the router's receive queue behind thousands of earlier commands.
+
+This causes cascading timeouts: timed-out responses trigger `resubscribeSMPSession`, which retries all pending subs. Three consecutive timeouts can trigger connection drop via the monitor thread, causing a full reconnection and retry of everything.
+
+## Solution
+
+### Part 1: Router - batched command processing
+
+Move the per-command processing loop inside command handlers so that commands of the same type within a batch can be processed together.
+
+Current flow:
+```
+receive batch -> verify all -> lookup queues all -> for each command: processCommand (individual DB query)
+```
+
+Proposed flow:
+```
+receive batch -> verify all -> lookup queues all -> group by command type -> process group:
+  SUB group: one batched message peek query for all queues
+  NSUB group: batch registration (already cheap, but can batch DB writes)
+  other commands: process individually as before
+```
+
+For SUB, the batched processing would:
+1. Collect all queue IDs from the SUB group
+2. Perform a single DB query to peek messages for all queues
+3. Distribute results back to individual responses
+
+This reduces ~135 DB queries per batch to 1, cutting router-side DB load by ~100x for subscriptions.
+
+Commands where batching doesn't matter (SEND, ACK, KEY, etc.) continue to be processed individually.
+
+### Part 2: Agent - cursor-based subscription with backpressure
+
+Replace the all-at-once fetch-and-send pattern with cursor-style batching, similar to what the NTF server agent does.
+
+Changes to `subscribeUserServer`:
+1. Fetch queues in fixed-size batches (e.g., configurable, default ~1000) using LIMIT/OFFSET or cursor-based pagination.
+2. Send each batch and wait for responses before sending the next.
+3. Remove the use of `nonBlockingWriteTBQueue` for subscription batches - use blocking writes or structured backpressure so response timers don't start until the batch is actually sent.
+
+This ensures:
+- Memory usage is bounded (not 300K queue records in memory at once)
+- Response timeouts are meaningful (timer starts when the router receives the batch, not when it's queued locally)
+- Retries are scoped to the failed batch, not all pending subs
+- Works on slow/lossy networks by naturally pacing sends
+
+### Part 3: Response timeout for batches
+
+The current per-response 30-second timeout doesn't account for batch processing time. Options:
+
+1. **Stagger deadlines**: later responses in a batch get proportionally more time. The `rcvConcurrency` field was designed for this but is never used.
+2. **Per-batch timeout**: instead of timing individual responses, timeout the entire batch with a budget proportional to batch size.
+3. **No timeout for subscription responses**: since subscriptions are sent as batches with backpressure (Part 2), and the connection is monitored by pings, individual response timeouts may not be needed. A subscription that doesn't get a response will be retried on reconnect.
+
+## Priority and ordering
+
+Part 1 (router batching) gives the biggest improvement and is independent of Parts 2/3.
+
+Part 2 (agent cursor + backpressure) eliminates the retry cascade and is critical for slow networks.
+
+Part 3 (timeout handling) is a refinement that can be addressed after Parts 1 and 2.
@@ -0,0 +1,150 @@
+# SimpleX Network Protocol Specifications — Governance and Evolution (draft)
+
+## Why this document exists
+
+SimpleX Network protocol specifications must evolve as the network grows. This document defines how specifications change, who governs those changes, and how the history of changes is preserved.
+
+### Lessons from the web: why ratcheted governance matters
+
+The web's governance history demonstrates both the necessity of consortium governance and the dangers of getting the transition wrong.
+
+[Tim Berners-Lee invented the web in 1991](https://home.cern/science/computing/birth-web/short-history-web). [Netscape took over in 1994](https://en.wikipedia.org/wiki/Netscape_Navigator), driving rapid innovation as a single company — SSL, cookies, JavaScript, and the features that made the web commercially viable. In 1994, [W3C was founded](https://www.w3.org/about/history/) as a consortium hosted across multiple independent institutions (MIT in the US, INRIA/ERCIM in Europe, Keio University in Japan, later Beihang University in China) to govern web standards.
+
+The transition from company-led innovation to consortium governance was abrupt rather than gradual. Netscape's decline (accelerated by the [browser wars](https://en.wikipedia.org/wiki/Browser_wars) and [AOL acquisition](https://cybercultural.com/p/1999-the-fall-of-netscape-and-the-rise-of-mozilla/)) transferred control to a standards body that prioritized process over progress. The result was [a lost decade of web stagnation](https://eev.ee/blog/2020/02/01/old-css-new-css/): CSS 2.0 shipped in 1998; CSS 2.1 didn't reach Candidate Recommendation until 2004 and wasn't finalized until 2011. W3C pursued XHTML and rejected proposed enhancements to HTML, until frustrated engineers from Apple, Mozilla, and Opera formed [WHATWG in 2004](https://en.wikipedia.org/wiki/WHATWG) to build HTML5 outside W3C's process. The abrupt governance transition, without a mechanism to balance community guarantees against the imperative to continue evolving the product at pace, dramatically slowed web evolution at the time it was needed most.
+
+Then in 2023, [W3C restructured from a multi-host consortium into a single 501(c)(3) nonprofit entity](https://www.w3.org/press-releases/2023/w3c-le-launched/) — W3C Inc, incorporated in the US. The previous structure distributed governance across four independent university hosts in different countries, making capture by any single entity structurally difficult. The new structure concentrates governance in a single legal entity with a board of directors. While presented as modernization, this effectively ended the decentralized consortium model that had protected web standards for nearly three decades.
+
+### The governance double ratchet
+
+SimpleX follows the same Netscape-to-consortium evolution path, but with two ratchets designed to prevent both failure modes — stagnation from premature governance transfer, and capture from governance centralization:
+
+- **Licensing ratchet**: all contributed IP is licensed under AGPLv3 (software) and Creative Commons (documentation), perpetually and irrevocably. What is licensed cannot be unlicensed. If a Party transfers Licensed IP, the licensing obligations transfer with it.
+
+- **Governance ratchet**: power can be given to the SimpleX Network Consortium, but never taken back. The Consortium Agreement requires majority decision of all Governing Parties for changes to the agreement itself, IP policy, and admission or removal of parties.
+
+The ratcheted transition is historically proven to be necessary. It allows the company to continue driving rapid product innovation (as Netscape did for the web) while incrementally and irreversibly transferring governance to the consortium, without the abrupt handover that stalled web evolution or the centralization that later undermined it.
+
+### Specification governance via the Consortium Agreement
+
+The SimpleX Network Consortium Agreement (being deployed in 2026) establishes two levels of intellectual property governance: **Licensed IP** (all contributed protocol specifications, software, and documentation, licensed perpetually and irrevocably) and **Core IP** (the subset essential to the network, requiring consortium governance to change). The distinction between these levels and how they map to the RFC process is described in [Standard vs Core specifications](#standard-vs-core-specifications) below.
+
+## Specification change process: protocol specifications and RFCs
+
+Protocol knowledge lives in two places:
+
+### `protocol/` — Consolidated specifications
+
+Each file is a complete, self-contained description of a protocol as it exists today. Like consolidated legislation in the UK legal system: the full current law in one document, not a patchwork of amendments.
+
+Consolidated specifications are maintained on every code change that affects protocol behavior. With LLMs, the cost of maintaining consolidated documents collapses — reworking prose to incorporate a new RFC is now inexpensive relative to the value of a single authoritative document per protocol.
+
+Implementers read `protocol/`. They should never need to reconstruct current behavior from a base spec plus a chain of RFCs.
+
+### `rfcs/` — Protocol evolution commits
+
+Each RFC describes a single change to a protocol specification. RFCs are the atomic unit of protocol evolution — analogous to commits in version control, or amending acts in legislation.
+
+An RFC is not part of the protocol specification. It becomes part of the specification only when embedded into the consolidated `protocol/` document. The RFC itself remains as a permanent historical record of what changed, when, and why.
+
+## RFC lifecycle
+
+```
+                  ┌——> done/ ——> standard/
+draft (root) ——>──┤
+                  └——> rejected/
+```
+
+### Draft — `rfcs/*.md`
+
+A proposal for a protocol change. Not yet implemented. Active proposals live in the `rfcs/` root directory.
+
+Named by proposal date: `YYYY-MM-DD-topic.md`.
+
+A draft may be rejected if the proposal is considered but not accepted for implementation.
+
+### Done — `rfcs/done/`
+
+Implemented in code. The protocol change described by this RFC exists in the codebase, but the RFC has not yet been verified against the actual implementation (code may have diverged from the proposal during implementation).
+
+### Standard — `rfcs/standard/`
+
+Verified against the actual implementation and synchronized with code. The RFC accurately describes what was implemented. This is a permanent historical record — standard RFCs are never modified or removed.
+
+On promotion to standard, the RFC is:
+1. Renamed from proposal date to standardization date: `YYYY-MM-DD-topic.md` (new date, same topic slug)
+2. Updated with a document history header capturing the full lifecycle
+3. Embedded into the corresponding `protocol/` consolidated specification
+
+The `protocol/` document references embedded RFCs by name (e.g., "Private message routing added by RFC 2023-09-12-second-relays, standardized 2026-XX-XX"), similar to UK legislation citing the amending act for each clause.
+
+Protocol version numbers make it clear which RFCs are included in which protocol revision — no separate tracking is needed.
+
+### Rejected — `rfcs/rejected/`
+
+Draft proposals that were considered but not accepted for implementation. Only drafts move to rejected — once an RFC is implemented (done/), it proceeds to standard/ after verification. Preserved for historical record of design decisions.
+
+### Document history header
+
+Every RFC in `standard/` carries a history header:
+
+```
+---
+Proposed: YYYY-MM-DD
+Implemented: YYYY-MM-DD
+Standardized: YYYY-MM-DD
+Protocol: simplex-messaging v9 (or whichever protocol this amends)
+---
+```
+
+## Governance
+
+SimpleX Network follows the Netscape-to-W3C evolution path, with ratcheted rather than abrupt transitions:
+
+| Phase | Period | Governance | Development process |
+|-------|--------|-----------|-------------------|
+| Protocol invented | 2020 | Two people | Prototype developed |
+| SimpleX Chat Ltd | 2022 | One company | Product-first: code leads, specs follow |
+| SimpleX Network Consortium | 2026 | Agreement of SimpleX Chat Ltd and non-profit entities | Product-first for standard; standards-first for core |
+| Decentralized governance | Future | TBD (DAO research ongoing) | Standards-first |
+
+### Current: product-first development
+
+SimpleX protocols currently follow a product-first development process: requirements drive code, code drives specification. RFCs are written as design proposals before implementation, but implementation details are figured out in code. Consolidated protocol specifications in `protocol/` are then amended to match the implementation.
+
+This process is governed by SimpleX Chat Ltd as the IP Holding Party under the Consortium Agreement.
+
+Any Specification Author (as defined in the Consortium Agreement) may propose RFCs. Acceptance and standardization decisions are made by SimpleX Chat Ltd during the current product-first phase.
+
+### Standard vs Core specifications
+
+The distinction between standard and core maps directly to the two levels of IP governance in the Consortium Agreement, and reflects the difference between product-first and standards-first development:
+
+**Standard** — Licensed IP, not yet under consortium governance. Governed by the company.
+
+All contributed protocol specifications are Licensed IP under the Consortium Agreement. Standard specifications follow product-first development: the company can evolve them with product needs, and they must be maintained on every code change that affects protocol behavior.
+
+Standard specifications live in `rfcs/standard/` and `protocol/`.
+
+**Core** — Governed IP, governed by the consortium.
+
+A subset of standard specifications will be designated as Core IP under the Consortium Agreement. Core specifications will follow standards-first development: specification changes must be agreed via Governing Decision before code changes.
+
+This is a legally binding commitment. Once Licensed IP is included in Core IP, the company that owns the code cannot unilaterally change it — even though they own the code, the Consortium Agreement requires a Governing Decision for any change to Core IP. This protects the fundamental properties of the network (privacy, security, decentralization) from unilateral modification by any single party.
+
+The designation of specific specifications as Core IP is itself a Governing Decision that requires Consortium vote. The transition will happen incrementally as protocols stabilize — the governance ratchet ensures that each designation is irreversible.
+
+The exact mechanism for distinguishing core from standard within the RFC and protocol folder structure is TBD — it will be decided as the first protocols are designated as Core IP.
+
+### Future: standards-first development
+
+As more protocols are designated as Core IP, development naturally transitions to a standards-first process for a growing portion of the protocol suite. The governance ratchet ensures this transition is gradual and irreversible — each protocol that becomes core gains the protection of consortium governance permanently, while remaining standard protocols continue to evolve at product pace.
+
+## Current state
+
+| Location | Contents | Count |
+|----------|----------|-------|
+| `protocol/` | Consolidated specs (SMP v19, Agent v7, XFTP v3, XRCP v1, NTF v3, PQDR v1) | 6 specs + overview |
+| `rfcs/` root | Active draft proposals | 10 |
+| `rfcs/done/` | Implemented, not yet verified | 1 (+10 sub-RFCs) |
+| `rfcs/standard/` | Verified against implementation | 31 |
+| `rfcs/rejected/` | Draft proposals not accepted | 7 |
@@ -0,0 +1,154 @@
+# XFTP Router: SNI, CORS, and Web Support
+
+Implementation details for Phase 3 of `rfcs/2026-01-30-send-file-page.md` (sections 6.1-6.4).
+
+## 1. Overview
+
+The XFTP router is extended to support web browser clients by:
+
+1. **SNI-based TLS certificate switching** — Present a CA-issued web certificate (e.g., Let's Encrypt) to browsers, while continuing to present the self-signed XFTP identity certificate to native XFTP clients.
+2. **CORS headers** — Add CORS response headers on SNI connections so browsers allow cross-origin XFTP requests.
+3. **Configuration** — `[WEB]` INI section for HTTPS cert/key paths; opt-in (commented out by default).
+
+Web handshake (challenge-response identity proof, §6.3 of parent RFC) is not yet implemented and will be added separately.
+
+## 2. SNI Certificate Switching
+
+### 2.1 Reusing the SMP Pattern
+
+The SMP router already implements SNI-based certificate switching via `TLSServerCredential` and `runTransportServerState_` (see `rfcs/2024-09-15-shared-port.md`). The XFTP router applies the same pattern with one key difference: both native and web XFTP clients use HTTP/2 transport, whereas SMP switches between raw SMP protocol and HTTP entirely.
+
+### 2.2 Approach
+
+When `httpServerCreds` is configured, the XFTP router bypasses `runHTTP2Server` and uses `runTransportServerState_` directly to obtain the per-connection `sniUsed` flag. It then sets up HTTP/2 manually on each TLS connection using `withHTTP2` (same internals as `runHTTP2ServerWith_`). The `sniUsed` flag is captured in the closure and shared by all HTTP/2 requests on that connection.
+
+When `httpServerCreds` is absent, the existing `runHTTP2Server` path is unchanged.
+
+```
+Native client (no SNI)  ──TLS──> XFTP identity cert ──HTTP/2──> processRequest (no CORS)
+Browser client (SNI)    ──TLS──> Web CA cert        ──HTTP/2──> processRequest (+ CORS)
+```
+
+### 2.3 Certificate Chain
+
+The web certificate file (e.g., `web.crt`) must contain the full chain: leaf certificate followed by the signing CA certificate. `loadServerCredential` uses `T.credentialLoadX509Chain` which reads all PEM blocks from the file.
+
+The client validates the chain by comparing `idCert` fingerprint (the CA cert, second in the 2-cert chain) against the known `keyHash`. This is the same validation as for XFTP identity certificates — the CA that signed the web cert must match the XFTP router's identity.
+
+## 3. CORS Support
+
+### 3.1 Design
+
+CORS headers are only added when both conditions are true:
+- `addCORSHeaders` is `True` in `TransportServerConfig` (set in XFTP `Main.hs`)
+- `sniUsed` is `True` for the current TLS connection
+
+This ensures native clients never see CORS headers.
+
+### 3.2 Response Headers
+
+All POST responses on SNI connections include:
+```
+Access-Control-Allow-Origin: *
+Access-Control-Expose-Headers: *
+```
+
+### 3.3 OPTIONS Preflight
+
+OPTIONS requests are intercepted at the HTTP/2 dispatch level, before `processRequest`. This is necessary because `processRequest` rejects bodies that don't match `xftpBlockSize`.
+
+Preflight response:
+```
+HTTP/2 200
+Access-Control-Allow-Origin: *
+Access-Control-Allow-Methods: POST, OPTIONS
+Access-Control-Allow-Headers: *
+Access-Control-Max-Age: 86400
+```
+
+### 3.4 Security
+
+`Access-Control-Allow-Origin: *` is safe because:
+- All XFTP commands require Ed25519 authentication (per-packet keys from file description).
+- No cookies or browser credentials are involved.
+- File content is end-to-end encrypted.
+
+## 4. Configuration
+
+### 4.1 INI Template
+
+```ini
+[WEB]
+# cert: /etc/opt/simplex-xftp/web.crt
+# key: /etc/opt/simplex-xftp/web.key
+```
+
+Commented out by default — web support is opt-in.
+
+### 4.2 Behavior
+
+- `[WEB]` section not configured: silently ignored, router operates normally for native clients only.
+- `[WEB]` section configured with valid cert/key paths: SNI + CORS enabled.
+- `[WEB]` section configured with missing cert files: warning + continue (non-fatal, unlike SMP router where it is fatal).
+
+## 5. Files Modified
+
+### 5.1 `src/Simplex/Messaging/Transport/Server.hs`
+
+Added `addCORSHeaders :: Bool` field to `TransportServerConfig`. Updated `mkTransportServerConfig` to accept the new parameter. All existing SMP call sites pass `False`.
+
+### 5.2 `src/Simplex/Messaging/Transport/HTTP2/Server.hs`
+
+- Extracted `expireInactiveClient` from `runHTTP2ServerWith_`'s `where` clause to a module-level function.
+- Parameterized `runHTTP2ServerWith_`: setup type changed from `((TLS p -> IO ()) -> a)` to `(((Bool, TLS p) -> IO ()) -> a)`, callback from `HTTP2ServerFunc` to `Bool -> HTTP2ServerFunc`. The `Bool` is the per-connection `sniUsed` flag, threaded through `H.run` to the callback.
+- Extended `runHTTP2Server` with `Maybe T.Credential` parameter for SNI web certificate. Its setup uses `runTransportServerState_` with `TLSServerCredential`, which naturally provides `(sniUsed, tls)` pairs matching the new `runHTTP2ServerWith_` setup type.
+- Adapted `runHTTP2ServerWith` (client-side HTTP/2, no SNI): wraps its setup to inject `(False, tls)` and its callback with `const`.
+- Updated `getHTTP2Server` (test helper) to pass `Nothing` for httpCreds.
+
+### 5.3 `src/Simplex/FileTransfer/Server/Env.hs`
+
+- Added `httpCredentials :: Maybe ServerCredentials` to `XFTPServerConfig`.
+- Added `httpServerCreds :: Maybe T.Credential` to `XFTPEnv`.
+- `newXFTPServerEnv` loads HTTP credentials when configured.
+
+### 5.4 `src/Simplex/FileTransfer/Server/Main.hs`
+
+- Added `[WEB]` section to INI template.
+- Added `httpCredentials` parsing from INI `[WEB]` section (`cert` and `key` fields).
+- Set `addCORSHeaders = isJust httpCredentials_` in transport config (conditional on web cert presence).
+
+### 5.5 `src/Simplex/FileTransfer/Server.hs`
+
+Core server changes:
+
+- `runServer` calls `runHTTP2Server` with `httpCreds_` and a `\sniUsed -> handleRequest (sniUsed && addCORSHeaders transportConfig)` callback. TLS params are `defaultSupportedParamsHTTPS` when web creds present, `defaultSupportedParams` otherwise. SNI routing, HTTP/2 setup, and client expiration are handled inside `runHTTP2Server`.
+
+- `XFTPTransportRequest` carries `addCORS :: Bool` field, threaded through to `sendXFTPResponse`.
+
+- `sendXFTPResponse` conditionally includes CORS headers based on `addCORS`.
+
+- OPTIONS requests on SNI connections return CORS preflight headers before reaching `processRequest`.
+
+- Helper functions: `corsHeaders` (response headers), `corsPreflightHeaders` (preflight headers).
+
+### 5.6 `tests/XFTPClient.hs`
+
+- Added `httpCredentials = Nothing` to `testXFTPServerConfig`.
+- Added `testXFTPServerConfigSNI` with web cert config and `addCORSHeaders = True`.
+- Added `withXFTPServerSNI` helper.
+
+### 5.7 `tests/XFTPServerTests.hs`
+
+Added SNI and CORS tests as a subsection within `xftpServerTests` (6 tests):
+
+1. **SNI cert selection** — Connect with SNI + `h2` ALPN, verify RSA web certificate is presented.
+2. **Non-SNI cert selection** — Connect without SNI + `xftp/1` ALPN, verify Ed448 XFTP certificate is presented.
+3. **CORS headers** — SNI POST request includes `Access-Control-Allow-Origin: *` and `Access-Control-Expose-Headers: *`.
+4. **OPTIONS preflight** — SNI OPTIONS request returns all CORS preflight headers.
+5. **No CORS without SNI** — Non-SNI POST request has no CORS headers.
+6. **Data packet delivery** — Full XFTP data packet upload/download through SNI-enabled router verifying no regression.
+
+## 6. Remaining Work
+
+- **Web handshake** (§6.3 of parent RFC): Challenge-response identity proof for SNI connections. The router detects web clients via the `sniUsed` flag and expects a 32-byte challenge in the first POST body (non-empty, unlike standard handshake). Response includes full cert chain + signature over `(challenge ++ sessionId)`.
+- **Static page serving** (§6.5 of parent RFC): Optional serving of the web page HTML/JS bundle on GET requests.
@@ -0,0 +1,246 @@
+# Web Handshake — Challenge-Response Identity Proof
+
+RFC §6.3: Router proves XFTP identity to web clients independently of TLS CA infrastructure.
+
+## 1. Protocol
+
+**Standard handshake** (unchanged):
+```
+Client → empty POST                                        → Server
+Server → padded {vRange, sessionId, authPubKey, Nothing}    → Client
+Client → padded {version, keyHash, Nothing}                 → Server
+Server → empty                                              → Client
+```
+
+**Web handshake** (SNI connection, non-empty hello):
+```
+Client → padded {32 random bytes}                                → Server
+Server → padded {vRange, sessionId, authPubKey, Just sigBytes}   → Client
+  sigBytes = signatureBytes(sign(identityLeafKey, challenge <> sessionId))
+Client validates:
+  1. chainIdCaCerts(authPubKey.certChain) → CCValid {leafCert, idCert}
+  2. SHA-256(idCert) == keyHash   (server identity)
+  3. verify(leafCert.pubKey, sigBytes, challenge <> sessionId)  (challenge-response)
+  4. verify(leafCert.pubKey, signedPubKey.signature, signedPubKey.objectDer)  (DH key auth)
+Client → padded {version, keyHash, Just challenge}               → Server
+Server verifies: echoed challenge == stored challenge from step 1
+Server → empty                                                   → Client
+```
+
+**Detection**: `sniUsed` per-connection flag. Non-empty hello allowed only when `sniUsed`. Empty hello with SNI → standard handshake.
+
+**Why both steps 3 and 4**: Native clients verify `signedPubKey` using the TLS peer certificate (`serverKey` from `getServerVerifyKey`), which is the XFTP identity cert in non-SNI connections — TLS provides this binding. Web clients cannot access TLS peer certificate data (browser API limitation; TLS presents the web CA cert but provides no API to extract it). So web clients must verify at the application layer using `authPubKey.certChain`, which always contains the XFTP identity chain regardless of which cert TLS used. Step 3 proves the router holds its identity key *right now* (freshness via random challenge). Step 4 proves the DH session key was signed by the identity key holder (prevents MITM key substitution). Together they give web clients some assurance native clients get from TLS, except channel binding for commands.
+
+## 2. Type Changes — `src/Simplex/FileTransfer/Transport.hs`
+
+### `XFTPServerHandshake` (line 114)
+
+Add field: `webIdentityProof :: Maybe ByteString` — raw Ed448 signature bytes (114 bytes), or `Nothing` for standard handshake. No record needed — the cert chain is already in `authPubKey.certChain`.
+
+### `Encoding XFTPServerHandshake` (line 136)
+
+- `smpEncode`: append `smpEncode webIdentityProof`
+- `smpP`: `Tail compat`, if non-empty `eitherToMaybe $ smpDecode compat`
+
+Backward compat: old clients ignore via `Tail _compat`; new client + old server → empty compat → `Nothing`.
+
+### `XFTPClientHandshake` (line 121)
+
+Add field: `webChallenge :: Maybe ByteString`
+
+### `Encoding XFTPClientHandshake` (line 128)
+
+Same `Tail compat` pattern as server handshake.
+
+### Export list
+
+Both types use `(..)` export — new fields auto-exported.
+
+## 3. Router Changes — `src/Simplex/FileTransfer/Server.hs`
+
+### `XFTPTransportRequest` (line 88)
+
+Add field: `sniUsed :: SNICredentialUsed` (`Bool` from `Transport.Server`). Add import.
+
+### `Handshake` (line 117)
+
+`HandshakeSent C.PrivateKeyX25519` → `HandshakeSent C.PrivateKeyX25519 (Maybe ByteString)` — stores 32-byte web challenge or `Nothing`.
+
+### `runServer` handler (line 145–161)
+
+- Pass `sniUsed` into request construction (line 154)
+- SNI-first routing: when `sniUsed`, always route to `xftpServerHandshakeV1` (web ALPN `h2` would otherwise fall to `_` catch-all)
+
+### `xftpServerHandshakeV1` (line 162)
+
+- Destructure `sniUsed` from request
+- Match `HandshakeSent pk challenge_` → `processClientHandshake pk challenge_`
+
+### `processHello` (line 171)
+
+- Branch `(sniUsed, B.null bodyHead)`:
+  - `(_, True)` → standard: `challenge_ = Nothing`
+  - `(True, False)` → web: unpad, verify 32 bytes, `challenge_ = Just`
+  - `(False, False)` → `throwE HANDSHAKE`
+- Store: `HandshakeSent pk challenge_`
+- Compute: `webIdentityProof = C.signatureBytes . C.sign serverSignKey . (<> sessionId) <$> challenge_`
+- Construct `XFTPServerHandshake` with `webIdentityProof`
+
+### `processClientHandshake` (line 183)
+
+- Accept `challenge_` parameter
+- Decode `webChallenge` from `XFTPClientHandshake`
+- Add: `unless (challenge_ == webChallenge) $ throwE HANDSHAKE`
+  (standard: both `Nothing` → passes)
+
+## 4. Native Client — `src/Simplex/FileTransfer/Client.hs`
+
+### `xftpClientHandshakeV1` (line 142)
+
+Add `webChallenge = Nothing` in `sendClientHandshake` call.
+
+No other changes — parser handles new fields via `Tail`, native client ignores `webIdentityProof`.
+
+## 5. TypeScript Changes (DONE except Ed448)
+
+Sections 5.1 and 5.2 are implemented. Section 5.3 needs Ed448 support.
+
+## 10. Ed448 Support via `@noble/curves`
+
+**Problem**: Production servers use Ed448 certificates (default). `identity.ts` only supports Ed25519 via libsodium. libsodium has no Ed448 support and never will.
+
+**Solution**: Add `@noble/curves` dependency for Ed448 verification only. All other crypto stays with libsodium.
+
+### 10.1 `xftp-web/package.json` — Add dependency
+
+```json
+"dependencies": {
+  "libsodium-wrappers-sumo": "^0.7.13",
+  "@noble/curves": "^1.9.7"
+}
+```
+
+Use v1.x (supports both CJS and ESM). v2.x is ESM-only with `.js` extension requirement.
+
+### 10.2 `xftp-web/src/crypto/keys.ts` — Ed448 DER constants and decode
+
+Add Ed448 SPKI DER prefix (12 bytes, same prefix length as Ed25519):
+```
+30 43 30 05 06 03 2b 65 71 03 3a 00
+```
+
+| Property | Ed25519 | Ed448 |
+|----------|---------|-------|
+| OID | `2b 65 70` | `2b 65 71` |
+| SPKI prefix | `30 2a ...` | `30 43 ...` |
+| Raw key size | 32 bytes | 57 bytes |
+| SPKI total | 44 bytes | 69 bytes |
+| Signature size | 64 bytes | 114 bytes |
+
+New functions:
+- `decodePubKeyEd448(der: Uint8Array): Uint8Array` — 69 bytes → 57 bytes raw
+- `encodePubKeyEd448(raw: Uint8Array): Uint8Array` — 57 bytes → 69 bytes DER
+- `verifyEd448(publicKey: Uint8Array, sig: Uint8Array, msg: Uint8Array): boolean` — uses `ed448.verify(sig, msg, publicKey)` from `@noble/curves/ed448`
+
+Note: `@noble/curves` parameter order is `(signature, message, publicKey)`, not `(publicKey, signature, message)`.
+
+### 10.3 `xftp-web/src/crypto/identity.ts` — Algorithm-agnostic verification
+
+Replace `extractCertEd25519Key` + hardcoded Ed25519 `verify` with algorithm detection:
+
+1. `extractCertPublicKeyInfo(certDer)` → SPKI DER (already exists, works for any algorithm)
+2. Detect algorithm from SPKI: byte at offset 8 is `0x70` (Ed25519) or `0x71` (Ed448)
+3. Extract raw key with appropriate decoder
+4. Verify signatures with appropriate function
+
+```typescript
+type CertKeyAlgorithm = 'ed25519' | 'ed448'
+
+function detectKeyAlgorithm(spki: Uint8Array): CertKeyAlgorithm {
+  if (spki.length === 44 && spki[8] === 0x70) return 'ed25519'
+  if (spki.length === 69 && spki[8] === 0x71) return 'ed448'
+  throw new Error("unsupported certificate key algorithm")
+}
+```
+
+`verifyIdentityProof` changes:
+- Extract SPKI from leaf cert
+- Detect algorithm → choose `decodePubKeyEd25519`/`decodePubKeyEd448` and `verify`/`verifyEd448`
+- Both challenge signature and DH key signature use the same leaf key + algorithm
+
+Remove `extractCertEd25519Key` (replaced by generic path). Keep `extractCertPublicKeyInfo` (already generic).
+
+### 10.4 `xftp-web/src/protocol/handshake.ts` — Comment update
+
+`SignedKey.signature` comment: "raw Ed25519 signature bytes (64 bytes)" → "raw signature bytes (Ed25519: 64, Ed448: 114)"
+
+### 10.5 Tests — `tests/XFTPWebTests.hs`
+
+**Integration test**: Switch from `withXFTPServerEd25519SNI` (Ed25519 fixtures) to `withXFTPServerSNI` (default Ed448 fixtures). Update fingerprint source from `tests/fixtures/ed25519/ca.crt` to the default `tests/fixtures/ca.crt`.
+
+Optionally add a second integration test with Ed25519 to cover both paths, or rely on existing unit tests for Ed25519 coverage.
+
+### 10.6 Implementation order
+
+1. `npm install @noble/curves` in `xftp-web/`
+2. `keys.ts` — Ed448 constants, decode, encode, verifyEd448
+3. `identity.ts` — algorithm detection, generic verification
+4. `handshake.ts` — comment fix
+5. `XFTPWebTests.hs` — switch integration test to Ed448
+6. Build TS + run all tests
+
+## 6. Haskell Integration Test — `tests/XFTPServerTests.hs`
+
+Add `testWebHandshake` to "XFTP SNI and CORS" describe block.
+
+1. `withXFTPServerSNI` — server with web credentials
+2. Connect with SNI + `h2` ALPN
+3. Send padded 32-byte challenge
+4. Decode `XFTPServerHandshake`, assert `webIdentityProof` is `Just`
+5. `chainIdCaCerts` on `authPubKey.certChain` → `CCValid {leafCert, idCert}`
+6. Verify `SHA-256(idCert) == keyHash`
+7. Extract `leafCert` public key, verify challenge signature
+8. Verify `signedPubKey` signature using `leafCert` key (DH key auth)
+9. Send `XFTPClientHandshake` with `webChallenge = Just challenge`
+10. Assert empty response
+
+Imports: `XFTPServerHandshake (..)`, `XFTPClientHandshake (..)`, `ChainCertificates (..)`, `chainIdCaCerts`.
+
+## 7. TS Tests — `tests/XFTPWebTests.hs`
+
+### Unit tests
+
+- **`decodeServerHandshake` with proof**: Haskell-encode with `Just sigBytes`, TS-decode, verify bytes match.
+- **`encodeClientHandshake` with challenge**: TS-encode, compare with Haskell-encoded.
+- **`chainIdCaCerts`**: 2/3/4-cert chains return correct positions.
+- **`caFingerprint` (fixed)**: matches `sha256(idCert)` for 2 and 3-cert chains.
+
+### Integration test
+
+Node.js inline script against `withXFTPServerSNI`:
+1. Connect with SNI via `http2.connect`
+2. Send padded challenge, decode `XFTPServerHandshake` with TS
+3. `verifyIdentityProof` — full chain validation + challenge sig + DH key sig
+4. Send client handshake with echoed challenge
+5. Assert empty response
+
+## 8. Implementation Order
+
+1. `Transport.hs` — `Maybe` fields + encoding instances
+2. `Server.hs` — `sniUsed`, challenge in `Handshake`, `processHello`, `processClientHandshake`, SNI routing
+3. `Client.hs` — `webChallenge = Nothing`
+4. Build: `cabal build --ghc-options -O0`
+5. Run existing SNI/CORS tests
+6. `XFTPServerTests.hs` — `testWebHandshake`
+7. `handshake.ts` — types, decoding, `chainIdCaCerts`, fix `caFingerprint`
+8. `crypto/identity.ts` — Node.js verification functions
+9. `XFTPWebTests.hs` — unit + integration tests
+10. Build TS + run all tests
+
+## 9. Verification
+
+```bash
+cd xftp-web && npm install && npm run build && cd ..
+cabal test --ghc-options=-O0 --test-option='--match=/XFTP/XFTP server/XFTP SNI and CORS/' --test-show-details=streaming
+cabal test --ghc-options=-O0 --test-option='--match=/XFTP Web Client/' --test-show-details=streaming
+```
@@ -0,0 +1,208 @@
+# Plan: Browser ↔ Haskell File Transfer Tests
+
+## Table of Contents
+1. Goal
+2. Current State
+3. Implementation
+4. Success Criteria
+5. Files
+6. Order
+
+## 1. Goal
+Run browser upload/download tests in headless Chromium via Vitest, proving fetch-based transport works in real browser environment.
+
+## 2. Current State
+- `client.ts`: Transport abstraction done — http2 for Node, fetch for browser ✓
+- `agent.ts`: Uses `node:crypto` (randomBytes) and `node:zlib` (deflateRawSync/inflateRawSync) — **won't run in browser**
+- `XFTPWebTests.hs`: Cross-language tests exist (Haskell calls TS via Node.js) ✓
+
+## 3. Implementation
+
+### 3.1 Make agent.ts isomorphic
+
+| Current (Node.js only) | Isomorphic replacement |
+|------------------------|------------------------|
+| `import crypto from "node:crypto"` | Remove import |
+| `import zlib from "node:zlib"` | `import pako from "pako"` |
+| `crypto.randomBytes(32)` | `crypto.getRandomValues(new Uint8Array(32))` |
+| `zlib.deflateRawSync(buf)` | `pako.deflateRaw(buf)` |
+| `zlib.inflateRawSync(buf)` | `pako.inflateRaw(buf)` |
+
+Note: `crypto.getRandomValues` available in both browser and Node.js (globalThis.crypto).
+
+### 3.2 Vitest browser mode setup
+
+`package.json` additions:
+```json
+"devDependencies": {
+  "vitest": "^3.0.0",
+  "@vitest/browser": "^3.0.0",
+  "playwright": "^1.50.0",
+  "@types/pako": "^2.0.3"
+},
+"dependencies": {
+  "pako": "^2.1.0"
+}
+```
+
+`vitest.config.ts`:
+```typescript
+import {defineConfig} from 'vitest/config'
+import {readFileSync} from 'fs'
+import {createHash} from 'crypto'
+
+// Compute fingerprint from ca.crt (same as Haskell's loadFileFingerprint)
+const caCert = readFileSync('../tests/fixtures/ca.crt')
+const fingerprint = createHash('sha256').update(caCert).digest('base64url')
+const serverAddr = `xftp://${fingerprint}@localhost:7000`
+
+export default defineConfig({
+  define: {
+    'import.meta.env.XFTP_SERVER': JSON.stringify(serverAddr)
+  },
+  test: {
+    browser: {
+      enabled: true,
+      provider: 'playwright',
+      instances: [{browser: 'chromium'}],
+      headless: true,
+      providerOptions: {
+        launch: {ignoreHTTPSErrors: true}
+      }
+    },
+    globalSetup: './test/globalSetup.ts'
+  }
+})
+```
+
+### 3.3 Server startup
+
+`test/globalSetup.ts`:
+```typescript
+import {spawn, ChildProcess} from 'child_process'
+import {resolve, join} from 'path'
+import {mkdtempSync, writeFileSync, copyFileSync} from 'fs'
+import {tmpdir} from 'os'
+
+let server: ChildProcess | null = null
+
+export async function setup() {
+  const fixtures = resolve(__dirname, '../../tests/fixtures')
+
+  // Create temp directories
+  const cfgDir = mkdtempSync(join(tmpdir(), 'xftp-cfg-'))
+  const logDir = mkdtempSync(join(tmpdir(), 'xftp-log-'))
+  const filesDir = mkdtempSync(join(tmpdir(), 'xftp-files-'))
+
+  // Copy certificates to cfgDir (xftp-server expects ca.crt, server.key, server.crt there)
+  copyFileSync(join(fixtures, 'ca.crt'), join(cfgDir, 'ca.crt'))
+  copyFileSync(join(fixtures, 'server.key'), join(cfgDir, 'server.key'))
+  copyFileSync(join(fixtures, 'server.crt'), join(cfgDir, 'server.crt'))
+
+  // Write INI config file
+  const iniContent = `[STORE_LOG]
+enable: off
+
+[TRANSPORT]
+host: localhost
+port: 7000
+
+[FILES]
+path: ${filesDir}
+
+[WEB]
+cert: ${join(fixtures, 'web.crt')}
+key: ${join(fixtures, 'web.key')}
+`
+  writeFileSync(join(cfgDir, 'file-server.ini'), iniContent)
+
+  // Spawn xftp-server with env vars
+  server = spawn('cabal', ['exec', 'xftp-server', '--', 'start'], {
+    env: {
+      ...process.env,
+      XFTP_SERVER_CFG_PATH: cfgDir,
+      XFTP_SERVER_LOG_PATH: logDir
+    },
+    stdio: ['ignore', 'pipe', 'pipe']
+  })
+
+  // Wait for "Listening on port 7000..."
+  await waitForServerReady(server)
+}
+
+export async function teardown() {
+  server?.kill('SIGTERM')
+  await new Promise(r => setTimeout(r, 500))
+}
+
+function waitForServerReady(proc: ChildProcess): Promise<void> {
+  return new Promise((resolve, reject) => {
+    const timeout = setTimeout(() => reject(new Error('Server start timeout')), 15000)
+    proc.stdout?.on('data', (data: Buffer) => {
+      if (data.toString().includes('Listening on port')) {
+        clearTimeout(timeout)
+        resolve()
+      }
+    })
+    proc.stderr?.on('data', (data: Buffer) => {
+      console.error('[xftp-server]', data.toString())
+    })
+    proc.on('error', reject)
+    proc.on('exit', (code) => {
+      clearTimeout(timeout)
+      if (code !== 0) reject(new Error(`Server exited with code ${code}`))
+    })
+  })
+}
+```
+
+Server env vars (from `apps/xftp-server/Main.hs` + `getEnvPath`):
+- `XFTP_SERVER_CFG_PATH` — directory containing `file-server.ini` and certs (`ca.crt`, `server.key`, `server.crt`)
+- `XFTP_SERVER_LOG_PATH` — directory for logs
+
+### 3.4 Browser test
+
+`test/browser.test.ts`:
+```typescript
+import {test, expect} from 'vitest'
+import {encryptFileForUpload, uploadFile, downloadFile} from '../src/agent.js'
+import {parseXFTPServer} from '../src/protocol/address.js'
+
+const server = parseXFTPServer(import.meta.env.XFTP_SERVER)
+
+test('browser upload + download round-trip', async () => {
+  const data = new Uint8Array(50000)
+  crypto.getRandomValues(data)
+  const encrypted = encryptFileForUpload(data, 'test.bin')
+  const {rcvDescription} = await uploadFile(server, encrypted)
+  const {content} = await downloadFile(rcvDescription)
+  expect(content).toEqual(data)
+})
+```
+
+## 4. Success Criteria
+
+1. `npm run build` — agent.ts compiles without node: imports
+2. `cabal test --test-option='--match=/XFTP Web Client/'` — existing Node.js tests still pass
+3. `npm run test:browser` — browser round-trip test passes in headless Chromium
+
+## 5. Files to Create/Modify
+
+**Modify:**
+- `xftp-web/package.json` — add vitest, @vitest/browser, playwright, pako, @types/pako
+- `xftp-web/src/agent.ts` — replace node:crypto, node:zlib with isomorphic alternatives
+
+**Create:**
+- `xftp-web/vitest.config.ts` — browser mode config
+- `xftp-web/test/globalSetup.ts` — xftp-server lifecycle
+- `xftp-web/test/browser.test.ts` — browser round-trip test
+
+## 6. Order of Implementation
+
+1. **Add pako dependency** — `npm install pako @types/pako`
+2. **Make agent.ts isomorphic** — replace node:crypto, node:zlib
+3. **Verify Node.js tests pass** — `cabal test --test-option='--match=/XFTP Web Client/'`
+4. **Set up Vitest** — add devDeps, create vitest.config.ts
+5. **Create globalSetup.ts** — write INI config, spawn xftp-server
+6. **Write browser test** — upload + download round-trip
+7. **Verify browser test passes** — `npm run test:browser`
@@ -0,0 +1,921 @@
+
+# Browser Transport & Web Worker Architecture
+
+## TOC
+
+1. Executive Summary
+2. Transport: fetch() API
+3. Architecture: Environment Abstraction
+4. Web Worker Implementation
+5. OPFS Implementation
+6. Implementation Plan
+7. Testing Strategy
+
+## 1. Executive Summary
+
+Adapt `client.ts` from `node:http2` to `fetch()` API for isomorphic Node.js/browser support. Add environment abstraction layer so the same upload/download pipeline works with or without Web Workers and with or without OPFS. In browsers, crypto runs in a Web Worker to keep UI responsive; in Node.js tests, crypto runs directly.
+
+**Key architectural constraint:** Existing crypto functions (`encryptFile`, `decryptChunks`, etc.) remain unchanged. The abstraction layer wraps them, choosing execution context (direct vs Worker) and storage (memory vs OPFS) based on environment.
+
+**Scope:**
+- Replace `node:http2` with `fetch()` in `client.ts`
+- Add `CryptoBackend` abstraction with three implementations
+- Create Web Worker that calls existing crypto functions
+- Add OPFS storage for large files in browser
+
+**Out of scope:** Web page UI (Phase 5 in main RFC).
+
+## 2. Transport: fetch() API
+
+### 2.1 Current State
+
+`client.ts` uses `node:http2`:
+```typescript
+import http2 from "node:http2"
+const session = http2.connect(url)
+const stream = session.request({':method': 'POST', ':path': '/'})
+stream.write(commandBlock)
+stream.end(chunkData)
+```
+
+### 2.2 Target State
+
+Isomorphic `fetch()` (Node.js 18+ and browsers):
+```typescript
+const response = await fetch(url, {
+  method: 'POST',
+  body: concatStreams(commandBlock, chunkData),
+  duplex: 'half',  // Required for streaming request body
+})
+const reader = response.body!.getReader()
+```
+
+### 2.3 Key Differences
+
+| Aspect | node:http2 | fetch() |
+|--------|-----------|---------|
+| Session management | Explicit `session.connect()` / `session.close()` | Per-request (HTTP/2 connection reuse is automatic) |
+| Streaming upload | `stream.write()` chunks | `ReadableStream` body + `duplex: 'half'` |
+| Streaming download | `stream.on('data')` | `response.body.getReader()` |
+| Connection pooling | Manual | Automatic per origin |
+
+### 2.4 API Changes
+
+```typescript
+// Before (node:http2)
+export interface XFTPClient {
+  session: http2.ClientHttp2Session
+  thParams: THParams
+  server: XFTPServer
+}
+
+// After (fetch)
+export interface XFTPClient {
+  baseUrl: string           // "https://host:port"
+  thParams: THParams
+  server: XFTPServer
+}
+```
+
+`connectXFTP()` performs handshake via fetch, returns `XFTPClient` with `baseUrl`.
+Subsequent commands use `fetch(client.baseUrl, ...)`.
+
+### 2.5 Handshake via fetch()
+
+**TLS session binding:** Multiple fetch() requests to the same origin reuse the HTTP/2 connection, which means they share the same TLS session. The server's `sessionId` (derived from TLS channel binding) remains consistent across the handshake round-trips and subsequent commands.
+
+```typescript
+async function connectXFTP(server: XFTPServer): Promise<XFTPClient> {
+  const baseUrl = `https://${server.host}:${server.port}`
+
+  // Round-trip 1: challenge → server handshake + identity proof
+  const challenge = crypto.getRandomValues(new Uint8Array(32))
+  const req1 = pad(encodeWebClientHello(challenge), xftpBlockSize)
+  const resp1 = await fetch(baseUrl, {method: 'POST', body: req1})
+
+  const reader = resp1.body!.getReader()
+  const serverBlock = await readExactly(reader, xftpBlockSize)
+  const serverHs = decodeServerHandshake(unPad(serverBlock))
+  const proofBody = await readRemaining(reader)
+  verifyIdentityProof(server.keyHash, challenge, serverHs.sessionId, proofBody)
+
+  // Round-trip 2: client handshake → server ack
+  const clientHs = encodeClientHandshake({xftpVersion: 3, keyHash: server.keyHash})
+  const req2 = pad(clientHs, xftpBlockSize)
+  await fetch(baseUrl, {method: 'POST', body: req2})
+
+  return {baseUrl, thParams: {sessionId: serverHs.sessionId, ...}, server}
+}
+```
+
+### 2.6 Command Execution
+
+```typescript
+async function sendXFTPCommand(
+  client: XFTPClient,
+  key: Uint8Array,
+  entityId: Uint8Array,
+  cmd: Uint8Array,
+  chunkData?: Uint8Array
+): Promise<{response: Uint8Array, body?: ReadableStream}> {
+  const block = xftpEncodeAuthTransmission(client.thParams, key, entityId, cmd)
+
+  const reqBody = chunkData
+    ? concatBytes(block, chunkData)
+    : block
+
+  const resp = await fetch(client.baseUrl, {
+    method: 'POST',
+    body: reqBody,
+    duplex: 'half',
+  })
+
+  const reader = resp.body!.getReader()
+  const responseBlock = await readExactly(reader, xftpBlockSize)
+  const parsed = xftpDecodeTransmission(responseBlock)
+
+  // For FGET: remaining body is encrypted chunk
+  const hasMore = await peekReader(reader)
+  return {
+    response: parsed,
+    body: hasMore ? wrapAsStream(reader) : undefined
+  }
+}
+```
+
+## 3. Architecture: Environment Abstraction
+
+### 3.1 Core Principle
+
+**Existing crypto functions remain unchanged.** The functions `encryptFile()`, `decryptChunks()`, `sha512()`, etc. in `crypto/file.ts` and `crypto/digest.ts` are pure computation — they take input bytes and produce output bytes. They have no knowledge of Workers, OPFS, or execution context.
+
+The abstraction layer sits between `agent.ts` (upload/download orchestration) and these crypto functions:
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│  agent.ts (upload/download orchestration)                            │
+│  - Unchanged logic: encrypt → chunk → upload → build description     │
+│  - Calls CryptoBackend interface, not crypto functions directly      │
+├─────────────────────────────────────────────────────────────────────┤
+│  CryptoBackend interface (env.ts)                                    │
+│  - Abstract interface for encrypt/decrypt/readChunk/writeChunk       │
+│  - Factory function selects implementation based on environment      │
+├──────────────┬──────────────────────┬───────────────────────────────┤
+│ DirectMemory │ WorkerMemory         │ WorkerOPFS                    │
+│ Backend      │ Backend              │ Backend                       │
+│ (Node.js)    │ (Browser, ≤50MB)     │ (Browser, >50MB)              │
+├──────────────┼──────────────────────┼───────────────────────────────┤
+│ Calls crypto │ Posts to Worker,     │ Posts to Worker,              │
+│ functions    │ Worker calls crypto  │ Worker calls crypto,          │
+│ directly     │ functions, returns   │ streams through OPFS          │
+│              │ via postMessage      │                               │
+├──────────────┴──────────────────────┴───────────────────────────────┤
+│  crypto/file.ts, crypto/digest.ts (unchanged)                        │
+│  - encryptFile(), decryptChunks(), sha512(), etc.                    │
+│  - Pure functions, no environment dependencies                       │
+└─────────────────────────────────────────────────────────────────────┘
+```
+
+### 3.2 CryptoBackend Interface
+
+```typescript
+// env.ts
+export interface CryptoBackend {
+  // Encrypt file, store result (in memory or OPFS depending on backend)
+  encrypt(
+    data: Uint8Array,
+    fileName: string,
+    onProgress?: (done: number, total: number) => void
+  ): Promise<EncryptResult>
+
+  // Decrypt from stored encrypted data
+  decrypt(
+    key: Uint8Array,
+    nonce: Uint8Array,
+    size: number,
+    onProgress?: (done: number, total: number) => void
+  ): Promise<DecryptResult>
+
+  // Read chunk from stored encrypted data (for upload)
+  readChunk(offset: number, size: number): Promise<Uint8Array>
+
+  // Write chunk to storage (for download, before decrypt)
+  writeChunk(data: Uint8Array, offset: number): Promise<void>
+
+  // Clean up temporary storage
+  cleanup(): Promise<void>
+}
+
+export interface EncryptResult {
+  digest: Uint8Array      // SHA-512 of encrypted data
+  key: Uint8Array         // Generated encryption key
+  nonce: Uint8Array       // Generated nonce
+  chunkSizes: number[]    // Chunk sizes for upload
+  totalSize: number       // Total encrypted size
+}
+
+export interface DecryptResult {
+  header: FileHeader      // Extracted file header (fileName, etc.)
+  content: Uint8Array     // Decrypted file content
+}
+```
+
+### 3.3 Backend Implementations
+
+**DirectMemoryBackend** (Node.js):
+```typescript
+class DirectMemoryBackend implements CryptoBackend {
+  private encryptedData: Uint8Array | null = null
+
+  async encrypt(data: Uint8Array, fileName: string, onProgress?): Promise<EncryptResult> {
+    const key = randomBytes(32)
+    const nonce = randomBytes(24)
+    // Call existing crypto function directly
+    this.encryptedData = encryptFile(data, fileName, key, nonce, onProgress)
+    const digest = sha512(this.encryptedData)
+    const chunkSizes = prepareChunkSizes(this.encryptedData.length)
+    return { digest, key, nonce, chunkSizes, totalSize: this.encryptedData.length }
+  }
+
+  async decrypt(key, nonce, size, onProgress): Promise<DecryptResult> {
+    // Call existing crypto function directly
+    return decryptChunks([this.encryptedData!], key, nonce, size, onProgress)
+  }
+
+  async readChunk(offset: number, size: number): Promise<Uint8Array> {
+    return this.encryptedData!.slice(offset, offset + size)
+  }
+
+  async writeChunk(data: Uint8Array, offset: number): Promise<void> {
+    if (!this.encryptedData) this.encryptedData = new Uint8Array(offset + data.length)
+    this.encryptedData.set(data, offset)
+  }
+
+  async cleanup(): Promise<void> {
+    this.encryptedData = null
+  }
+}
+```
+
+**WorkerMemoryBackend** and **WorkerOPFSBackend** are similar but post messages to a Web Worker instead of calling crypto directly. The Worker then calls the same `encryptFile()`, `decryptChunks()` functions. See §4 for Worker implementation details.
+
+### 3.4 Factory Function
+
+```typescript
+// env.ts
+export function createCryptoBackend(fileSize: number): CryptoBackend {
+  const hasWorker = typeof Worker !== 'undefined'
+  const hasOPFS = typeof navigator?.storage?.getDirectory !== 'undefined'
+  const isLargeFile = fileSize > 50 * 1024 * 1024
+
+  if (hasWorker && hasOPFS && isLargeFile) {
+    return new WorkerOPFSBackend()   // Browser + large file
+  } else if (hasWorker) {
+    return new WorkerMemoryBackend() // Browser + small file
+  } else {
+    return new DirectMemoryBackend() // Node.js
+  }
+}
+```
+
+### 3.5 Usage in agent.ts
+
+```typescript
+// agent.ts - upload orchestration (simplified)
+export async function uploadFile(
+  server: XFTPServer,
+  fileData: Uint8Array,
+  fileName: string,
+  onProgress?: ProgressCallback
+): Promise<string> {
+  // Create backend based on environment
+  const backend = createCryptoBackend(fileData.length)
+
+  try {
+    // Encrypt (runs in Worker in browser, directly in Node)
+    const enc = await backend.encrypt(fileData, fileName, onProgress)
+
+    // Upload chunks (same code regardless of backend)
+    const client = await connectXFTP(server)
+    const sentChunks = []
+    let offset = 0
+    for (const size of enc.chunkSizes) {
+      const chunk = await backend.readChunk(offset, size)
+      const sent = await uploadChunk(client, chunk, enc.digest)
+      sentChunks.push(sent)
+      offset += size
+    }
+
+    // Build description and URI
+    const fd = buildFileDescription(enc, sentChunks)
+    return encodeFileDescriptionURI(fd)
+  } finally {
+    await backend.cleanup()
+  }
+}
+```
+
+The key point: `uploadFile()` logic is identical regardless of whether crypto runs in a Worker or directly. The `CryptoBackend` abstraction hides that detail.
+
+### 3.6 Why This Matters for Testing
+
+- **Layer 1 tests** (per-function): Call `encryptFile()`, `decryptChunks()` directly via Node — unchanged
+- **Layer 2 tests** (full flow): Call `uploadFile()`, `downloadFile()` in Node — uses `DirectMemoryBackend`, same code path as browser except for Worker
+- **Layer 3 tests** (browser): Call `uploadFile()`, `downloadFile()` in Playwright — uses `WorkerMemoryBackend` or `WorkerOPFSBackend`
+
+All three layers exercise the same crypto functions. The only difference is execution context.
+
+## 4. Web Worker Implementation
+
+### 4.1 Why Web Worker
+
+File encryption (XSalsa20-Poly1305) is sequential and CPU-bound:
+- 100 MB file ≈ 1-2 seconds of continuous computation
+- Running on main thread blocks UI (no progress updates, frozen page)
+- Chunking into async microtasks adds complexity and still causes jank
+
+Web Worker runs crypto in parallel thread. Main thread stays responsive.
+
+### 4.2 Architecture
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│  Main Thread                                                 │
+│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │
+│  │ UI (upload/ │  │ Progress    │  │ Network (fetch)     │  │
+│  │ download)   │  │ display     │  │                     │  │
+│  └──────┬──────┘  └──────▲──────┘  └──────────▲──────────┘  │
+│         │                │                    │              │
+│         │ postMessage    │ progress          │ encrypted    │
+│         ▼                │ events            │ chunks       │
+├─────────────────────────────────────────────────────────────┤
+│  Web Worker                                                  │
+│  ┌─────────────────────────────────────────────────────────┐│
+│  │ Crypto Pipeline                                          ││
+│  │ - encryptFile() with progress callbacks                  ││
+│  │ - decryptChunks() with progress callbacks                ││
+│  │ - OPFS read/write for temp storage                       ││
+│  └─────────────────────────────────────────────────────────┘│
+└─────────────────────────────────────────────────────────────┘
+```
+
+### 4.3 Message Protocol
+
+**Main → Worker:**
+
+```typescript
+type WorkerRequest =
+  // Encrypt file, store result in OPFS (large) or memory (small)
+  | {type: 'encrypt', file: File, fileName: string, useOPFS: boolean}
+  // Read encrypted chunk from OPFS for upload
+  | {type: 'readChunk', offset: number, size: number}
+  // Write downloaded chunk to OPFS for later decryption
+  | {type: 'writeChunk', data: ArrayBuffer, offset: number}
+  // Decrypt from OPFS or provided chunks
+  | {type: 'decrypt', key: Uint8Array, nonce: Uint8Array, size: number, chunks?: ArrayBuffer[]}
+  // Delete OPFS temp files
+  | {type: 'cleanup'}
+  | {type: 'cancel'}
+```
+
+**Worker → Main:**
+
+```typescript
+type WorkerResponse =
+  | {type: 'progress', phase: 'encrypt' | 'decrypt', done: number, total: number}
+  // For OPFS: encData is empty, data lives in OPFS temp file
+  | {type: 'encrypted', encData: ArrayBuffer | null, digest: Uint8Array, key: Uint8Array, nonce: Uint8Array, chunkSizes: number[]}
+  | {type: 'chunk', data: ArrayBuffer}  // Response to readChunk
+  | {type: 'chunkWritten'}              // Response to writeChunk
+  | {type: 'decrypted', header: FileHeader, content: ArrayBuffer}
+  | {type: 'cleaned'}                   // Response to cleanup
+  | {type: 'error', message: string}
+```
+
+### 4.4 Worker Implementation
+
+```typescript
+// crypto.worker.ts
+import {encryptFile, encryptFileStreaming, decryptChunks, decryptFromOPFS} from './crypto/file.js'
+import {sha512} from './crypto/digest.js'
+import {prepareChunkSizes} from './protocol/chunks.js'
+
+let opfsHandle: FileSystemSyncAccessHandle | null = null
+
+self.onmessage = async (e: MessageEvent<WorkerRequest>) => {
+  const req = e.data
+
+  if (req.type === 'encrypt') {
+    const key = crypto.getRandomValues(new Uint8Array(32))
+    const nonce = crypto.getRandomValues(new Uint8Array(24))
+
+    if (req.useOPFS) {
+      // Large file: stream through OPFS to avoid memory pressure
+      const root = await navigator.storage.getDirectory()
+      const fileHandle = await root.getFileHandle('encrypted-temp', {create: true})
+      opfsHandle = await fileHandle.createSyncAccessHandle()
+
+      // Stream encrypt: read 64KB from File, encrypt, write to OPFS
+      const digest = await encryptFileStreaming(
+        req.file,
+        req.fileName,
+        key,
+        nonce,
+        opfsHandle,
+        (done, total) => self.postMessage({type: 'progress', phase: 'encrypt', done, total})
+      )
+
+      const encSize = opfsHandle.getSize()
+      const chunkSizes = prepareChunkSizes(encSize)
+
+      self.postMessage({
+        type: 'encrypted',
+        encData: null,  // Data in OPFS, not memory
+        digest, key, nonce, chunkSizes
+      })
+    } else {
+      // Small file: in-memory is fine
+      const source = new Uint8Array(await req.file.arrayBuffer())
+      const encData = encryptFile(source, req.fileName, key, nonce, (done, total) => {
+        self.postMessage({type: 'progress', phase: 'encrypt', done, total})
+      })
+
+      const digest = sha512(encData)
+      const chunkSizes = prepareChunkSizes(encData.length)
+
+      self.postMessage({
+        type: 'encrypted',
+        encData: encData.buffer,
+        digest, key, nonce, chunkSizes
+      }, [encData.buffer])
+    }
+  }
+
+  if (req.type === 'readChunk') {
+    // Read chunk from OPFS for upload
+    const chunk = new Uint8Array(req.size)
+    opfsHandle!.read(chunk, {at: req.offset})
+    self.postMessage({type: 'chunk', data: chunk.buffer}, [chunk.buffer])
+  }
+
+  if (req.type === 'writeChunk') {
+    // Write downloaded chunk to OPFS
+    if (!opfsHandle) {
+      const root = await navigator.storage.getDirectory()
+      const fileHandle = await root.getFileHandle('download-temp', {create: true})
+      opfsHandle = await fileHandle.createSyncAccessHandle()
+    }
+    opfsHandle.write(new Uint8Array(req.data), {at: req.offset})
+    self.postMessage({type: 'chunkWritten'})
+  }
+
+  if (req.type === 'decrypt') {
+    let result
+    if (req.chunks) {
+      // Small file: chunks provided in memory
+      const chunks = req.chunks.map(b => new Uint8Array(b))
+      result = decryptChunks(chunks, req.key, req.nonce, req.size, (done, total) => {
+        self.postMessage({type: 'progress', phase: 'decrypt', done, total})
+      })
+    } else {
+      // Large file: read from OPFS
+      result = decryptFromOPFS(opfsHandle!, req.key, req.nonce, req.size, (done, total) => {
+        self.postMessage({type: 'progress', phase: 'decrypt', done, total})
+      })
+    }
+
+    self.postMessage({
+      type: 'decrypted',
+      header: result.header,
+      content: result.content.buffer
+    }, [result.content.buffer])
+  }
+
+  if (req.type === 'cleanup') {
+    if (opfsHandle) {
+      opfsHandle.close()
+      opfsHandle = null
+    }
+    const root = await navigator.storage.getDirectory()
+    try { await root.removeEntry('encrypted-temp') } catch {}
+    try { await root.removeEntry('download-temp') } catch {}
+    self.postMessage({type: 'cleaned'})
+  }
+}
+```
+
+### 4.5 Main Thread Wrapper
+
+```typescript
+// crypto-worker.ts (main thread)
+export class CryptoWorker {
+  private worker: Worker
+  private pending: Map<string, {resolve: Function, reject: Function}> = new Map()
+  private onProgress?: (done: number, total: number) => void
+
+  constructor() {
+    this.worker = new Worker(new URL('./crypto.worker.js', import.meta.url), {type: 'module'})
+    this.worker.onmessage = (e) => this.handleMessage(e.data)
+  }
+
+  async encrypt(file: File, onProgress?: (done: number, total: number) => void): Promise<EncryptedFileInfo> {
+    const useOPFS = file.size > 50 * 1024 * 1024  // 50 MB threshold
+    return new Promise((resolve, reject) => {
+      this.pending.set('encrypt', {resolve, reject})
+      this.onProgress = onProgress
+      this.worker.postMessage({type: 'encrypt', file, fileName: file.name, useOPFS})
+    })
+  }
+
+  async decrypt(
+    chunks: Uint8Array[],
+    key: Uint8Array,
+    nonce: Uint8Array,
+    size: number,
+    onProgress?: (done: number, total: number) => void
+  ): Promise<DownloadResult> {
+    return new Promise((resolve, reject) => {
+      this.pending.set('decrypt', {resolve, reject})
+      this.onProgress = onProgress
+      this.worker.postMessage({
+        type: 'decrypt',
+        chunks: chunks.map(c => c.buffer),
+        key, nonce, size
+      }, chunks.map(c => c.buffer))
+    })
+  }
+
+  private handleMessage(msg: WorkerResponse) {
+    if (msg.type === 'progress') {
+      this.onProgress?.(msg.done, msg.total)
+    } else if (msg.type === 'encrypted') {
+      this.pending.get('encrypt')?.resolve({
+        encData: msg.encData ? new Uint8Array(msg.encData) : null,  // null when using OPFS
+        digest: msg.digest,
+        key: msg.key,
+        nonce: msg.nonce,
+        chunkSizes: msg.chunkSizes
+      })
+    } else if (msg.type === 'decrypted') {
+      this.pending.get('decrypt')?.resolve({
+        header: msg.header,
+        content: new Uint8Array(msg.content)
+      })
+    } else if (msg.type === 'error') {
+      // Reject all pending
+      for (const p of this.pending.values()) p.reject(new Error(msg.message))
+    }
+  }
+}
+```
+
+## 5. OPFS Implementation
+
+### 5.1 Purpose
+
+For files approaching 100 MB, holding encrypted data in memory while uploading creates memory pressure. OPFS provides temporary file storage:
+- Write encrypted data to OPFS as it's generated
+- Read chunks from OPFS for upload
+- Delete after upload completes
+
+### 5.2 When to Use
+
+- Files > 50 MB: Use OPFS
+- Files ≤ 50 MB: In-memory (simpler, no OPFS overhead)
+
+Threshold is configurable.
+
+### 5.3 OPFS API
+
+```typescript
+// In Web Worker (synchronous API for performance)
+const root = await navigator.storage.getDirectory()
+const fileHandle = await root.getFileHandle('encrypted-temp', {create: true})
+const accessHandle = await fileHandle.createSyncAccessHandle()
+
+// Write encrypted chunks as they're generated
+accessHandle.write(encryptedChunk, {at: offset})
+
+// Read chunk for upload
+const chunk = new Uint8Array(chunkSize)
+accessHandle.read(chunk, {at: chunkOffset})
+
+// Cleanup
+accessHandle.close()
+await root.removeEntry('encrypted-temp')
+```
+
+### 5.4 Upload Flow with OPFS
+
+```
+1. Main: user drops file
+2. Main → Worker: {type: 'encrypt', file}
+3. Worker:
+   - Create OPFS temp file
+   - Encrypt 64KB at a time, write to OPFS
+   - Post progress every 64KB
+   - Compute digest
+   - Return {digest, key, nonce, chunkSizes} (data stays in OPFS)
+4. Main: for each chunk:
+   - Main → Worker: {type: 'readChunk', offset, size}
+   - Worker: read from OPFS, return chunk
+   - Main: upload chunk via fetch()
+5. Main → Worker: {type: 'cleanup'}
+6. Worker: delete OPFS temp file
+```
+
+### 5.5 Download Flow with OPFS
+
+```
+1. Main: parse URL, get FileDescription
+2. Main: for each chunk:
+   - Download via fetch()
+   - Main → Worker: {type: 'writeChunk', data, offset}
+   - Worker: write to OPFS temp file
+3. Main → Worker: {type: 'decrypt', key, nonce, size}
+4. Worker:
+   - Read from OPFS
+   - Decrypt, verify auth tag
+   - Return {header, content}
+5. Main: trigger browser download
+6. Main → Worker: {type: 'cleanup'}
+```
+
+## 6. Implementation Plan
+
+### 6.1 Phase A: fetch() Transport
+
+**Goal:** Replace `node:http2` with `fetch()` in `client.ts`. All existing Node.js tests pass.
+
+1. Rewrite `connectXFTP()` to use fetch() for handshake
+2. Rewrite `sendXFTPCommand()` to use fetch()
+3. Update `createXFTPChunk`, `uploadXFTPChunk`, `downloadXFTPChunk`, etc.
+4. Remove `node:http2` import
+5. Run existing Haskell integration tests — must pass
+
+**Files:** `client.ts`
+
+### 6.2 Phase B: Environment Abstraction + Web Worker
+
+**Goal:** Add `CryptoBackend` abstraction (§3) so the same code works in Node (direct) and browser (Worker).
+
+1. Create `env.ts` with `CryptoBackend` interface and `createCryptoBackend()` factory (as specified in §3)
+2. Implement `DirectMemoryBackend` for Node.js
+3. Create `crypto.worker.ts` that imports and calls existing crypto functions
+4. Implement `WorkerMemoryBackend` for browser
+5. Update `agent.ts` to use `createCryptoBackend()` instead of direct crypto calls
+6. Existing tests pass (now using `DirectMemoryBackend`)
+
+**Files:** `env.ts`, `crypto.worker.ts`, `agent.ts`
+
+### 6.3 Phase C: OPFS Backend
+
+**Goal:** Large files (>50 MB) use OPFS for temp storage in browser.
+
+1. Implement `WorkerOPFSBackend` — uses OPFS sync API in worker
+2. Add OPFS helpers in worker: read/write to temp file
+3. Factory function now returns `WorkerOPFSBackend` for large files
+4. Same `agent.ts` code works — only backend implementation differs
+
+**Files:** `env.ts`, `crypto.worker.ts`
+
+### 6.4 Phase D: Browser Testing
+
+**Goal:** Verify everything works in real browsers.
+
+1. Create minimal test HTML page
+2. Test upload flow in Chrome, Firefox, Safari
+3. Test download flow
+4. Test progress reporting
+5. Test cancellation
+6. Test error handling (network failure, invalid file)
+
+## 7. Testing Strategy
+
+### 7.1 Test Layers
+
+The `CryptoBackend` abstraction (§3) enables testing at multiple levels without code duplication:
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│ Layer 3: Browser Integration (Playwright)                        │
+│ - Web Worker message passing                                     │
+│ - OPFS read/write                                                │
+│ - Progress UI updates                                            │
+│ - Real browser fetch() with CORS                                 │
+├─────────────────────────────────────────────────────────────────┤
+│ Layer 2: Full Flow (Haskell-driven, Node.js)                     │
+│ - fetch() transport against real xftp-server                     │
+│ - Upload: encrypt → chunk → upload → build description           │
+│ - Download: parse → download → verify → decrypt                  │
+│ - Cross-language: TS upload ↔ Haskell download (and vice versa)  │
+├─────────────────────────────────────────────────────────────────┤
+│ Layer 1: Per-Function (Haskell-driven, Node.js)                  │
+│ - 172 existing tests                                             │
+│ - Byte-identical output vs Haskell functions                     │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+### 7.2 Layer 1: Per-Function Tests (Existing)
+
+Existing Haskell-driven tests in `XFTPWebTests.hs`. Each test calls a TypeScript function via Node and compares output with Haskell.
+
+```bash
+cabal test --ghc-options -O0 --test-option='--match=/XFTP Web Client/'
+```
+
+All 172 tests must pass. No changes needed for browser transport work.
+
+### 7.3 Layer 2: Full Flow Tests (Node.js + fetch)
+
+Haskell-driven integration tests using Node.js native fetch(). These test the complete upload/download flow without Worker/OPFS.
+
+```haskell
+-- XFTPWebTests.hs (extends existing test file)
+it "fetch transport: upload and download round-trip" $ do
+  withXFTPServer testXFTPServerConfigSNI $ \server -> do
+    -- TypeScript uploads via fetch(), returns URI
+    uri <- jsOut $ callTS "src/agent" "uploadFileTest" serverAddrHex <> testFileHex
+    -- TypeScript downloads via fetch()
+    content <- jsOut $ callTS "src/agent" "downloadFileTest" uriHex
+    content `shouldBe` testFileContent
+
+it "fetch transport: TS upload, Haskell download" $ do
+  withXFTPServer testXFTPServerConfigSNI $ \server -> do
+    uri <- jsOut $ callTS "src/agent" "uploadFileTest" serverAddrHex <> testFileHex
+    -- Haskell agent downloads using existing xftp CLI pattern
+    outPath <- withAgent 1 agentCfg initAgentServers testDB $ \a -> do
+      rfId <- xftpReceiveFile' a 1 uri Nothing
+      waitRfDone a
+    content <- B.readFile outPath
+    content `shouldBe` testFileContent
+```
+
+**What this tests:**
+- fetch() handshake (challenge-response, TLS session binding)
+- fetch() command execution (FNEW, FPUT, FGET, FACK)
+- Streaming request/response bodies
+- Full encrypt → upload → download → decrypt flow
+
+**What this doesn't test:**
+- Web Worker message passing
+- OPFS storage
+- Browser-specific fetch() behavior (CORS preflight, etc.)
+
+### 7.4 Layer 3: Browser Integration Tests (Playwright)
+
+Playwright tests run in real browsers, testing browser-specific functionality.
+
+**Test infrastructure:**
+
+```
+xftp-web/
+├── test/
+│   ├── browser.test.ts      # Playwright test file
+│   └── test-server.ts       # Spawns xftp-server for tests
+└── test-page/
+    ├── index.html           # Minimal test UI
+    └── test-harness.ts      # Exposes test functions to window
+```
+
+**Running browser tests:**
+
+```bash
+cd xftp-web
+npm run test:browser  # Spawns xftp-server, runs Playwright
+```
+
+**Test cases:**
+
+```typescript
+// test/browser.test.ts
+import { test, expect } from '@playwright/test'
+import { spawn } from 'child_process'
+
+let serverProcess: ChildProcess
+
+test.beforeAll(async () => {
+  // Spawn xftp-server with SNI cert for browser TLS
+  serverProcess = spawn('xftp-server', ['start', '-c', 'test-config.ini'])
+  await waitForServer()
+})
+
+test.afterAll(async () => {
+  serverProcess.kill()
+})
+
+test('small file upload/download (in-memory)', async ({ page }) => {
+  await page.goto('/test-page/')
+
+  const result = await page.evaluate(async () => {
+    const data = new Uint8Array(1024 * 1024)  // 1 MB
+    crypto.getRandomValues(data)
+    const file = new File([data], 'small.bin')
+
+    const uri = await window.xftp.uploadFile(file)
+    const downloaded = await window.xftp.downloadFile(uri)
+
+    return {
+      uploadedSize: data.length,
+      downloadedSize: downloaded.length,
+      match: arraysEqual(data, downloaded),
+      usedOPFS: window.xftp.lastUploadUsedOPFS
+    }
+  })
+
+  expect(result.match).toBe(true)
+  expect(result.usedOPFS).toBe(false)  // Small file, no OPFS
+})
+
+test('large file upload/download (OPFS)', async ({ page }) => {
+  await page.goto('/test-page/')
+
+  const result = await page.evaluate(async () => {
+    const data = new Uint8Array(60 * 1024 * 1024)  // 60 MB
+    crypto.getRandomValues(data)
+    const file = new File([data], 'large.bin')
+
+    const uri = await window.xftp.uploadFile(file)
+    const downloaded = await window.xftp.downloadFile(uri)
+
+    return {
+      match: arraysEqual(data, downloaded),
+      usedOPFS: window.xftp.lastUploadUsedOPFS
+    }
+  })
+
+  expect(result.match).toBe(true)
+  expect(result.usedOPFS).toBe(true)  // Large file, used OPFS
+})
+
+test('progress events fire during upload', async ({ page }) => {
+  await page.goto('/test-page/')
+
+  const progressEvents = await page.evaluate(async () => {
+    const events: number[] = []
+    const data = new Uint8Array(10 * 1024 * 1024)  // 10 MB
+    const file = new File([data], 'progress.bin')
+
+    await window.xftp.uploadFile(file, (done, total) => {
+      events.push(done / total)
+    })
+
+    return events
+  })
+
+  expect(progressEvents.length).toBeGreaterThan(1)
+  expect(progressEvents[progressEvents.length - 1]).toBe(1)  // 100% at end
+})
+
+test('Web Worker keeps UI responsive', async ({ page }) => {
+  await page.goto('/test-page/')
+
+  // Start upload and measure main thread responsiveness
+  const result = await page.evaluate(async () => {
+    const data = new Uint8Array(50 * 1024 * 1024)  // 50 MB
+    const file = new File([data], 'responsive.bin')
+
+    let frameCount = 0
+    let uploadDone = false
+
+    // Count animation frames during upload
+    function countFrames() {
+      frameCount++
+      if (!uploadDone) requestAnimationFrame(countFrames)
+    }
+    requestAnimationFrame(countFrames)
+
+    const start = performance.now()
+    await window.xftp.uploadFile(file)
+    uploadDone = true
+    const elapsed = performance.now() - start
+
+    // If main thread was blocked, frameCount would be very low
+    const expectedFrames = (elapsed / 1000) * 30  // ~30 fps minimum
+    return { frameCount, expectedFrames, elapsed }
+  })
+
+  // Should maintain reasonable frame rate (Worker offloaded crypto)
+  expect(result.frameCount).toBeGreaterThan(result.expectedFrames * 0.5)
+})
+```
+
+### 7.5 Cross-Browser Matrix
+
+| Browser | fetch streaming | Web Worker | OPFS sync | Status |
+|---------|----------------|------------|-----------|--------|
+| Chrome 105+ | ✓ | ✓ | ✓ | Primary target |
+| Firefox 111+ | ✓ | ✓ | ✓ | Supported |
+| Safari 16.4+ | ✓ | ✓ | ✓ | Supported |
+| Edge 105+ | ✓ | ✓ | ✓ | Supported (Chromium) |
+
+Playwright tests run against Chrome by default. CI can run against all browsers.
+
+### 7.6 Test Execution Summary
+
+| Phase | Test Layer | Command | What's Verified |
+|-------|-----------|---------|-----------------|
+| A | Layer 1 + 2 | `cabal test --test-option='--match=/XFTP Web Client/'` | fetch() transport, full flow |
+| B | Layer 3 | `npm run test:browser` | Worker message passing, progress |
+| C | Layer 3 | `npm run test:browser` | OPFS storage for large files |
+| D | Layer 3 | `npm run test:browser -- --project=firefox,webkit` | Cross-browser |
@@ -0,0 +1,772 @@
+# Send File Web Page — Implementation Plan
+
+## TOC
+1. Executive Summary
+2. Architecture
+3. CryptoBackend & Web Worker
+4. Server Configuration
+5. Page Structure & UI
+6. Upload Flow
+7. Download Flow
+8. Build & Dev Setup
+9. agent.ts Changes
+10. Testing
+11. Files
+12. Implementation Order
+
+## 1. Executive Summary
+
+Build a static web page for browser-based XFTP file transfer (Phase 5 of master RFC). The page supports upload (drag-drop → encrypt → upload → shareable link) and download (open link → download → decrypt → save). Crypto runs in a Web Worker; large files use OPFS temp storage.
+
+Two build variants:
+- **Local**: single test server at `localhost:7000` (development/testing)
+- **Production**: 12 preset XFTP routers (6 SimpleX + 6 Flux)
+
+Uses Vite for bundling (already a dependency via vitest). No CSS framework — plain CSS per RFC spec.
+
+## 2. Architecture
+
+```
+xftp-web/
+├── src/                        # Library (existing, targeted changes)
+│   ├── agent.ts                # Modified: uploadFile readChunk, downloadFileRaw
+│   ├── client.ts               # Modified: downloadXFTPChunkRaw
+│   ├── crypto/                 # Unchanged
+│   ├── download.ts             # Unchanged
+│   └── protocol/
+│       └── description.ts      # Fix: SHA-256 → SHA-512 comment on digest field
+├── web/                        # Web page (new)
+│   ├── index.html              # Entry point (CSP meta tag)
+│   ├── main.ts                 # Router + sodium.ready init
+│   ├── upload.ts               # Upload UI + orchestration
+│   ├── download.ts             # Download UI + orchestration
+│   ├── progress.ts             # Circular progress canvas component
+│   ├── servers.ts              # Server list (build-time configured, imports servers.json)
+│   ├── servers.json            # Preset server addresses (shared with vite.config.ts)
+│   ├── crypto-backend.ts       # CryptoBackend interface + WorkerBackend
+│   ├── crypto.worker.ts        # Web Worker: encrypt/decrypt/OPFS
+│   └── style.css               # Minimal styling
+├── vite.config.ts              # Page build config (new)
+├── tsconfig.web.json           # IDE/CI type-check for web/ (new)
+├── tsconfig.worker.json        # IDE/CI type-check for worker (new)
+├── playwright.config.ts        # Page E2E test config (new)
+├── vitest.config.ts            # Test config (existing)
+├── .gitignore                  # Existing (add dist-web/)
+└── test/                       # Tests (existing + new page test)
+```
+
+Data flow:
+
+```
+                  ┌───────────────────────────────────────────┐
+                  │ Main Thread                                 │
+                  │                                             │
+                  │  Upload:  upload.ts ──► agent.ts ──► fetch()│
+                  │  Download: download.ts ──► agent.ts ──► fetch()
+                  │         │                                   │
+                  │    postMessage                        HTTP/2 │
+                  │         ▼                                   ▼
+                  │ ┌─────────────────┐             ┌──────────┐│
+                  │ │ Web Worker       │             │ XFTP     ││
+                  │ │ crypto.worker.ts │             │ Server   ││
+                  │ │ ┌─────────────┐ │             └──────────┘│
+                  │ │ │ OPFS temp   │ │                         │
+                  │ │ └─────────────┘ │                         │
+                  │ └─────────────────┘                         │
+                  └───────────────────────────────────────────┘
+```
+
+Both upload and download use `agent.ts` for orchestration (connection pooling, parallel chunk transfers, redirect handling). Upload uses a `readChunk` callback for Worker data access. Download uses an `onRawChunk` callback to route raw encrypted chunks to the Worker for decryption (see §7.2). ACK is the caller's responsibility — `downloadFileRaw` returns the resolved `FileDescription` without ACKing, so the caller can verify integrity before acknowledging.
+
+## 3. CryptoBackend & Web Worker
+
+### 3.1 Interface
+
+```typescript
+// crypto-backend.ts
+export interface CryptoBackend {
+  // Upload: encrypt file, store encrypted data in OPFS
+  encrypt(data: Uint8Array, fileName: string,
+          onProgress?: (done: number, total: number) => void
+  ): Promise<EncryptResult>
+
+  // Upload: read encrypted chunk from OPFS (called by agent.ts via readChunk callback)
+  readChunk(offset: number, size: number): Promise<Uint8Array>
+
+  // Download: transit-decrypt raw chunk and store in OPFS
+  decryptAndStoreChunk(
+    dhSecret: Uint8Array, nonce: Uint8Array,
+    body: Uint8Array, digest: Uint8Array, chunkNo: number
+  ): Promise<void>
+
+  // Download: verify digest + file-level decrypt all stored chunks
+  // Only needs size/digest/key/nonce — not the full FileDescription (avoids sending private keys to Worker)
+  verifyAndDecrypt(params: {size: number, digest: Uint8Array, key: Uint8Array, nonce: Uint8Array}
+  ): Promise<{header: FileHeader, content: Uint8Array}>
+
+  cleanup(): Promise<void>
+}
+
+// Structurally identical to EncryptedFileMetadata from agent.ts (§9.1).
+// Kept separate to avoid crypto-backend.ts importing from agent.ts
+// (which would pull in node:http2 via client.ts, breaking Worker bundling).
+// TypeScript structural typing makes them assignment-compatible.
+export interface EncryptResult {
+  digest: Uint8Array
+  key: Uint8Array
+  nonce: Uint8Array
+  chunkSizes: number[]
+}
+```
+
+### 3.2 Factory
+
+```typescript
+export function createCryptoBackend(): CryptoBackend {
+  if (typeof Worker === 'undefined') {
+    throw new Error('Web Workers required — update your browser')
+  }
+  return new WorkerBackend()
+}
+```
+
+The Worker always uses OPFS for temp storage (single code path — no memory/disk branching). OPFS I/O overhead is negligible relative to crypto and network time. Each Worker session creates a unique directory in OPFS root named `session-<Date.now()>-<crypto.randomUUID()>`, containing `upload.bin` and `download.bin` as needed. `cleanup()` deletes the entire session directory. On Worker startup (before processing messages), sweep OPFS root and delete any `session-*` directories whose embedded timestamp (parsed from the name) is older than 1 hour — this handles stale files from crashed tabs. The OPFS API does not expose directory timestamps, so the name-encoded timestamp is the only reliable mechanism. This prevents cross-tab collisions and unbounded OPFS growth.
+
+### 3.3 Worker message protocol
+
+Every request carries a numeric `id`. Responses carry the same `id`. WorkerBackend maintains a `Map<number, {resolve, reject}>` to match responses to pending promises.
+
+Main → Worker (fields marked `†` are Transferable — arrive as `ArrayBuffer` in Worker, must be wrapped with `new Uint8Array(...)` before use):
+- `{id: number, type: 'encrypt', data†: ArrayBuffer, fileName: string}` — encrypt file, store in OPFS
+- `{id: number, type: 'readChunk', offset: number, size: number}` — read encrypted chunk from OPFS
+- `{id: number, type: 'decryptAndStoreChunk', dhSecret: Uint8Array, nonce: Uint8Array, body†: ArrayBuffer, chunkDigest: Uint8Array, chunkNo: number}` — transit-decrypt + store in OPFS. `chunkDigest` is the per-chunk SHA-256 digest (verified by `decryptReceivedChunk`). Distinct from the file-level SHA-512 digest in `verifyAndDecrypt`.
+- `{id: number, type: 'verifyAndDecrypt', size: number, digest: Uint8Array, key: Uint8Array, nonce: Uint8Array}` — verify digest + file-level decrypt all chunks. Only the four fields needed for verification/decryption are sent — not the full `FileDescription`, which contains private replica keys that the Worker doesn't need.
+- `{id: number, type: 'cleanup'}` — delete OPFS temp files
+
+Worker → Main (fields marked `†` are Transferable):
+- `{id: number, type: 'progress', done: number, total: number}` — encryption/decryption progress (fire-and-forget, no promise)
+- `{id: number, type: 'encrypted', digest: Uint8Array, key: Uint8Array, nonce: Uint8Array, chunkSizes: number[]}` — all fields structured-cloned (not transferred)
+- `{id: number, type: 'chunk', data†: ArrayBuffer}` — readChunk response
+- `{id: number, type: 'stored'}` — decryptAndStore acknowledgment
+- `{id: number, type: 'decrypted', header: FileHeader, content†: ArrayBuffer}` — verifyAndDecrypt response
+- `{id: number, type: 'cleaned'}`
+- `{id: number, type: 'error', message: string}` — rejects the pending promise for this `id`
+
+All messages carrying large `ArrayBuffer` payloads use `postMessage(msg, [transferables])` to transfer ownership instead of structured-clone copying. Only `ArrayBuffer` can be transferred — `Uint8Array`, `number[]`, and other types are always structured-cloned. This applies to: `encrypt` request (`data`), `readChunk` response (`data`), `decryptAndStoreChunk` request (`body`), and `verifyAndDecrypt` response (`content`). The `WorkerBackend` implementation must ensure the transferred `ArrayBuffer` covers the full `Uint8Array` — if `byteOffset !== 0` or `byteLength !== buffer.byteLength`, slice first: `data.buffer.slice(data.byteOffset, data.byteOffset + data.byteLength)`. This is required for `decryptAndStore` request bodies: `sendXFTPCommand` returns `body = fullResp.subarray(XFTP_BLOCK_SIZE)`, which has `byteOffset = XFTP_BLOCK_SIZE`. Other payloads are full-buffer views (§6 step 3 creates `new Uint8Array(await file.arrayBuffer())`; Worker responses allocate fresh buffers) but `WorkerBackend` should guard unconditionally.
+
+### 3.4 Worker internals
+
+**Imports:** The Worker imports directly from `libsodium-wrappers-sumo` (for `await sodium.ready`), `src/crypto/file.js` (`encryptFile`, `encodeFileHeader`, `decryptChunks`), `src/crypto/digest.js` (`sha512`), `src/protocol/chunks.js` (`prepareChunkSizes`, `fileSizeLen`, `authTagSize`), `src/protocol/encoding.js` (`concatBytes`), and `src/download.js` (`decryptReceivedChunk`). `download.js` directly imports `src/protocol/client.js` (for `decryptTransportChunk`). These transitively pull in `src/crypto/secretbox.js`, `src/crypto/keys.js`, and `src/crypto/padding.js`. None of these import `src/agent.ts` or `src/client.ts` — those pull in `node:http2` via dynamic import which would break Worker bundling. Vite tree-shakes the transitive deps automatically. Note: `download.js` → `protocol/client.js` → `crypto/keys.js` transitively pulls in `@noble/curves` (~50-80KB). This is unavoidable since `decryptTransportChunk` needs `dh` from `keys.js`. If Worker bundle size becomes a concern, `decryptReceivedChunk` could be refactored out of `download.js` into a separate module that doesn't import `protocol/client.js`.
+
+**ArrayBuffer → Uint8Array conversion:** All Transferable fields arrive in the Worker as `ArrayBuffer`. The Worker's message handler must wrap them before passing to library functions: `new Uint8Array(msg.data)` for encrypt, `new Uint8Array(msg.body)` for decryptAndStore. Non-transferred fields (`dhSecret`, `nonce`, `digest`, `chunkSizes`) arrive as their original types (`Uint8Array` / `number[]`) via structured clone.
+
+The Worker's encrypt handler calls the same functions as `encryptFileForUpload` in agent.ts (key/nonce generation → `encryptFile` → `sha512` → `prepareChunkSizes`). This is not reimplementation — it's calling the same library functions from a different entry point.
+
+**Libsodium init:** Both the Worker and the main thread must `await sodium.ready` before calling any crypto functions that use libsodium. The Worker does this once on startup before processing messages. The main thread needs it before `connectXFTP` (which uses libsodium via `verifyIdentityProof`) and before `downloadXFTPChunkRaw` (which uses libsodium via `generateX25519KeyPair` + `dh`). In practice, `main.ts` calls `await sodium.ready` at page load, before any XFTP calls.
+
+Encrypt (mirrors `encryptFileForUpload` in agent.ts):
+1. Generate key (32B) + nonce (24B) via `crypto.getRandomValues`
+2. `fileHdr = encodeFileHeader({fileName, fileExtra: null})`
+3. `fileSize = BigInt(fileHdr.length + source.length)`
+4. `payloadSize = Number(fileSize) + fileSizeLen + authTagSize`
+5. `chunkSizes = prepareChunkSizes(payloadSize)`
+6. `encSize = BigInt(chunkSizes.reduce((a, b) => a + b, 0))`
+7. `encData = encryptFile(source, fileHdr, key, nonce, fileSize, encSize)`
+8. `digest = sha512(encData)` — note: the `digest` field comment in `FileDescription` in `description.ts` says "SHA-256" but the actual hash is SHA-512 everywhere (`sha512` in agent.ts and download.ts). Fix the comment during implementation.
+9. Open OPFS upload file via `createSyncAccessHandle`, write `encData`, flush, close handle. Null out `encData` reference.
+10. Reopen the same OPFS file with `createSyncAccessHandle` as a persistent read handle (stored on the Worker module scope). This handle is used by all subsequent `readChunk` calls and closed on `cleanup`.
+11. Post back `{digest, key, nonce, chunkSizes}` (no encData transfer — data stays in OPFS)
+
+readChunk:
+- Use the persistent read handle: `handle.read(buf, {at: offset})` → return slice as transferable ArrayBuffer. OPFS allows only one `FileSystemSyncAccessHandle` per file; the persistent handle avoids per-call open/close overhead.
+
+decryptAndStoreChunk (removes transport encryption only — stored data is still file-level encrypted):
+1. `decryptReceivedChunk(dhSecret, nonce, new Uint8Array(body), chunkDigest)` → transit-decrypted chunk data (still file-level encrypted — only the transport layer is removed). Argument order matches signature `(dhSecret, cbNonce, encData, expectedDigest)` from download.ts. `body` arrives as `ArrayBuffer` via Transferable and must be wrapped; `dhSecret`, `nonce`, `chunkDigest` arrive as `Uint8Array` via structured clone.
+2. On first call, open the OPFS download temp file via `createSyncAccessHandle` and store as a persistent write handle. Record `{chunkNo, size: decrypted.length}` in an in-memory `chunkMeta: Map<number, {offset: number, size: number}>` — offset is the running sum of sizes for chunks stored so far (chunks may arrive out of order with `concurrency > 1`, so offset is assigned as `currentFileOffset`, then `currentFileOffset += size`)
+3. Write decrypted chunk to the persistent handle at the recorded offset
+
+verifyAndDecrypt (mirrors size/digest checks in agent.ts `downloadFile`):
+1. Close the persistent download write handle (flush first), then reopen as a read handle. Read each chunk from OPFS into a `Uint8Array[]` array, ordered by `chunkNo`: for each entry in `chunkMeta` sorted by `chunkNo`, `handle.read(buf, {at: offset})` with the recorded offset and size
+2. Concatenate for verification: `combined = concatBytes(...chunks)`
+3. Verify total size: `combined.length === params.size`
+4. Verify SHA-512 digest: `sha512(combined)` matches `params.digest`
+5. Decrypt: `decryptChunks(BigInt(params.size), chunks, params.key, params.nonce)` — `params.size` is the encrypted file size (`fd.size` = `sum(chunkSizes)` = `decryptChunks`' first param `encSize`). Called directly instead of via `processDownloadedFile` (which expects a full `FileDescription`). Pass the original `chunks` array (not `combined`), as `decryptChunks` handles concatenation internally.
+6. Delete OPFS download temp file
+7. Return `{header, content}` via transferable ArrayBuffer
+
+### 3.5 Browser requirements
+
+The page requires a modern browser with Web Worker and OPFS support:
+- Chrome 102+, Firefox 114+, Safari 15.2+ (Workers + OPFS + ES module Workers — Firefox added module Worker support in 114)
+- If Worker or OPFS is unavailable, the page shows an error message rather than falling back silently.
+
+No `DirectBackend` is needed — the page is browser-only, and tests run in vitest browser mode (real Chromium). The existing library tests (`test/browser.test.ts`) test the crypto/upload/download pipeline directly without Workers.
+
+## 4. Server Configuration
+
+### 4.1 Server lists
+
+`web/servers.json` — single source of truth for preset server addresses (imported by both `servers.ts` and `vite.config.ts`):
+
+```json
+{
+  "simplex": [
+    "xftp://da1aH3nOT-9G8lV7bWamhxpDYdJ1xmW7j3JpGaDR5Ug=@xftp1.simplex.im",
+    "xftp://5vog2Imy1ExJB_7zDZrkV1KDWi96jYFyy9CL6fndBVw=@xftp2.simplex.im",
+    "xftp://PYa32DdYNFWi0uZZOprWQoQpIk5qyjRJ3EF7bVpbsn8=@xftp3.simplex.im",
+    "xftp://k_GgQl40UZVV0Y4BX9ZTyMVqX5ZewcLW0waQIl7AYDE=@xftp4.simplex.im",
+    "xftp://-bIo6o8wuVc4wpZkZD3tH-rCeYaeER_0lz1ffQcSJDs=@xftp5.simplex.im",
+    "xftp://6nSvtY9pJn6PXWTAIMNl95E1Kk1vD7FM2TeOA64CFLg=@xftp6.simplex.im"
+  ],
+  "flux": [
+    "xftp://92Sctlc09vHl_nAqF2min88zKyjdYJ9mgxRCJns5K2U=@xftp1.simplexonflux.com",
+    "xftp://YBXy4f5zU1CEhnbbCzVWTNVNsaETcAGmYqGNxHntiE8=@xftp2.simplexonflux.com",
+    "xftp://ARQO74ZSvv2OrulRF3CdgwPz_AMy27r0phtLSq5b664=@xftp3.simplexonflux.com",
+    "xftp://ub2jmAa9U0uQCy90O-fSUNaYCj6sdhl49Jh3VpNXP58=@xftp4.simplexonflux.com",
+    "xftp://Rh19D5e4Eez37DEE9hAlXDB3gZa1BdFYJTPgJWPO9OI=@xftp5.simplexonflux.com",
+    "xftp://0AznwoyfX8Od9T_acp1QeeKtxUi676IBIiQjXVwbdyU=@xftp6.simplexonflux.com"
+  ]
+}
+```
+
+`web/servers.ts`:
+
+```typescript
+import {parseXFTPServer, type XFTPServer} from '../src/protocol/address.js'
+import presets from './servers.json'
+
+declare const __XFTP_SERVERS__: string[]
+
+const serverAddresses: string[] = typeof __XFTP_SERVERS__ !== 'undefined'
+  ? __XFTP_SERVERS__
+  : [...presets.simplex, ...presets.flux]
+
+export function getServers(): XFTPServer[] {
+  return serverAddresses.map(parseXFTPServer)
+}
+
+export function pickRandomServer(servers: XFTPServer[]): XFTPServer {
+  return servers[Math.floor(Math.random() * servers.length)]
+}
+```
+
+### 4.2 Build-time injection
+
+`vite.config.ts` defines `__XFTP_SERVERS__`:
+- `mode === 'local'`: `["xftp://<test-fingerprint>@localhost:7000"]`
+- `mode === 'production'`: not defined → falls through to hardcoded list
+
+### 4.3 Assumption
+
+Production XFTP routers must have `[WEB]` section configured with a CA-signed certificate for browser TLS. Without this, browsers will reject the self-signed XFTP identity cert. The local test router uses `tests/fixtures/` certs which Chromium accepts via `ignoreHTTPSErrors`.
+
+## 5. Page Structure & UI
+
+### 5.1 Routing
+
+`main.ts` checks `window.location.hash` once on page load:
+- Hash present → download mode
+- Hash absent → upload mode
+
+No `hashchange` listener — the shareable link opens in a new tab. Simple page-load routing.
+
+### 5.2 Upload UI states
+
+1. **Landing**: Drag-drop zone centered, file picker button, size limit note
+2. **Uploading**: Circular progress (canvas), percentage, cancel button
+3. **Complete**: Shareable link (input + copy button), "Install SimpleX" CTA
+4. **Error**: Error message + retry button. On server-unreachable, auto-retry with exponential backoff (1s, 2s, 4s, up to 3 attempts) before showing the error state.
+
+### 5.3 Download UI states
+
+1. **Ready**: Approximate file size displayed (encrypted size from `fd.size` or `fd.redirect.size` — see §7 step 2; file name is unavailable — it's inside the encrypted content), download button
+2. **Downloading**: Circular progress, percentage
+3. **Complete**: Browser save dialog triggered automatically
+4. **Error**: Error message (expired, corrupted, unreachable)
+
+### 5.4 Security summary (RFC §7.4)
+
+Both upload-complete and download-ready states display a brief non-technical security summary:
+- Files are encrypted in the browser before upload — the server never sees file contents.
+- The link contains the decryption key in the hash fragment, which the browser never sends to any server.
+- For maximum security, use the SimpleX app.
+
+### 5.5 File expiry
+
+Display on upload-complete state: "Files are typically available for 48 hours." This is an approximation — actual expiry depends on each XFTP router's `[STORE_LOG]` retention configuration. The 48-hour figure matches the current preset router defaults.
+
+### 5.6 Styling
+
+Plain CSS, no framework. White background, centered content, responsive. Circular progress via `<canvas>` (arc drawing, percentage text in center).
+
+File size limit: 100MB. Displayed on upload page.
+
+### 5.7 CSP
+
+`index.html` includes a `<meta>` Content-Security-Policy tag with a build-time placeholder:
+
+```html
+<meta http-equiv="Content-Security-Policy"
+  content="default-src 'self'; worker-src 'self' blob:; style-src 'self' 'unsafe-inline'; connect-src __CSP_CONNECT_SRC__;">
+```
+
+Vite's `transformIndexHtml` hook (in `vite.config.ts`) replaces `__CSP_CONNECT_SRC__` at build time with origins derived from the server list:
+- Local mode: `https://localhost:7000`
+- Production: `https://xftp1.simplex.im:443 https://xftp2.simplex.im:443 ...` (all 12 servers)
+
+## 6. Upload Flow
+
+`web/upload.ts`:
+
+1. User drops/picks file → `File` object
+2. Validate `file.size <= 100 * 1024 * 1024` — show error if exceeded
+3. Read file: `new Uint8Array(await file.arrayBuffer())` — note: after `backend.encrypt()` transfers the buffer to the Worker, `fileData` is detached (zero-length). Peak memory is ~2× file size (main thread holds original until transfer, Worker holds encrypted copy before OPFS write). Acceptable for the 100MB limit; do not raise the limit without considering memory implications.
+4. Create `CryptoBackend` via factory
+5. Create `XFTPClientAgent`
+6. `backend.encrypt(fileData, file.name, onProgress)` → `EncryptResult`
+   - Encryption progress shown on canvas (Worker posts progress messages)
+7. Pick one random server from configured list (V1: all chunks to same server)
+8. Call `uploadFile(agent, server, metadata, {onProgress, readChunk: (off, sz) => backend.readChunk(off, sz)})`:
+   - `metadata` = `{digest, key, nonce, chunkSizes}` from EncryptResult
+   - Network progress shown on canvas
+   - Returns `{rcvDescription, sndDescription, uri}`
+9. Construct full URL: `window.location.origin + window.location.pathname + '#' + uri`
+10. Display link, copy button
+11. Cleanup: `backend.cleanup()`, `closeXFTPAgent(agent)`
+
+**Cancel:** User can abort via cancel button. Sets an `AbortController` signal that:
+- Sends `{type: 'cleanup'}` to Worker
+- Closes the XFTPClientAgent (drops HTTP/2 connections)
+- Resets UI to landing state
+
+## 7. Download Flow
+
+`web/download.ts`:
+
+1. Parse `window.location.hash.slice(1)` → `decodeDescriptionURI(fragment)` → `FileDescription`
+2. Display file size (`fd.size` bytes, formatted human-readable). Note: `fd.size` is the encrypted size (slightly larger than plaintext due to padding + auth tag). The plaintext size is not available until decryption — display it as an approximate file size. If `fd.redirect !== null`, size comes from `fd.redirect.size` (which is the inner encrypted size).
+3. User clicks "Download"
+4. Create `CryptoBackend` and `XFTPClientAgent`
+5. Call `downloadFileRaw(agent, fd, onRawChunk, {onProgress, concurrency: 3})`:
+   - `onRawChunk` forwards each raw chunk to the Worker: `backend.decryptAndStoreChunk(raw.dhSecret, raw.nonce, raw.body, raw.digest, raw.chunkNo)`
+   - `downloadFileRaw` handles redirect resolution internally (see §7.1), parallel downloads, and connection pooling
+   - Returns the resolved `FileDescription` (inner fd for redirect case, original fd otherwise)
+6. `backend.verifyAndDecrypt({size: resolvedFd.size, digest: resolvedFd.digest, key: resolvedFd.key, nonce: resolvedFd.nonce})` → `{header, content}`
+   - Verifies size + SHA-512 digest + file-level decryption inside Worker. Only the four needed fields are sent — private replica keys stay on the main thread.
+7. ACK: `ackFileChunks(agent, resolvedFd)` — best-effort, after verification succeeds
+8. Sanitize `header.fileName` before use: strip path separators (`/`, `\`), replace null/control characters (U+0000-U+001F, U+007F), strip Unicode bidi override characters (U+202A-U+202E, U+2066-U+2069 — prevents `doc.pdf.exe` appearing as `doc.exe.pdf`), limit length to 255 chars. The filename is user-controlled (set by the uploader) and arrives via decrypted content. Then trigger browser save: `new Blob([content])` → `<a download="${sanitizedName}">` click
+9. Cleanup: `backend.cleanup()`, `closeXFTPAgent(agent)`
+
+### 7.1 Redirect handling
+
+Handled inside `downloadFileRaw` in agent.ts — the web page doesn't see it. When `fd.redirect !== null`:
+
+1. Download redirect chunks via `downloadXFTPChunkRaw` (parallel, same as regular chunks)
+2. Transit-decrypt + verify + file-level decrypt on main thread (redirect data is always small — a few KB of YAML, so main thread decryption is fine)
+3. Parse YAML → inner `FileDescription`, validate against `fd.redirect.{size, digest}`
+4. ACK redirect chunks (best-effort)
+5. Continue downloading inner description's chunks, calling `onRawChunk` for each
+
+### 7.2 Architecture note: download refactoring
+
+Both upload and download use `agent.ts` for orchestration. The key difference is where the crypto/network split happens:
+
+- **Upload**: agent.ts reads encrypted chunks from the Worker via `readChunk` callback, sends them over the network.
+- **Download**: agent.ts receives raw encrypted responses from the network via `downloadXFTPChunkRaw` (DH key exchange + network only, no decryption), passes them to the web page via `onRawChunk` callback, which routes them to the Worker for transit decryption.
+
+This split keeps all expensive crypto off the main thread. Transit decryption uses a custom JS Salsa20 implementation (`xorKeystream` in secretbox.ts) that would block the UI for ~50-200ms on a 4MB chunk. File-level decryption (`decryptChunks`) is similarly expensive. Both happen in the Worker.
+
+The cheap operations stay on the main thread: DH key exchange (`generateX25519KeyPair` + `dh` — ~1ms via libsodium WASM), XFTP command encoding/decoding, connection management.
+
+## 8. Build & Dev Setup
+
+### 8.1 vite.config.ts (new, separate from vitest.config.ts)
+
+```typescript
+import {defineConfig, type Plugin} from 'vite'
+import {readFileSync} from 'fs'
+import {createHash} from 'crypto'
+import presets from './web/servers.json'
+
+function parseHost(addr: string): string {
+  const m = addr.match(/@(.+)$/)
+  if (!m) throw new Error('bad server address: ' + addr)
+  const host = m[1].split(',')[0]
+  return host.includes(':') ? host : host + ':443'
+}
+
+function cspPlugin(servers: string[]): Plugin {
+  const origins = servers.map(s => 'https://' + parseHost(s)).join(' ')
+  return {
+    name: 'csp-connect-src',
+    transformIndexHtml: {
+      order: 'pre',
+      handler(html, ctx) {
+        if (ctx.server) {
+          // Dev mode: remove CSP meta tag entirely — Vite HMR needs inline scripts
+          return html.replace(/<meta\s[^>]*?Content-Security-Policy[\s\S]*?>/i, '')
+        }
+        return html.replace('__CSP_CONNECT_SRC__', origins)
+      }
+    }
+  }
+}
+
+export default defineConfig(({mode}) => {
+  const define: Record<string, string> = {}
+  let servers: string[]
+
+  if (mode === 'local') {
+    const pem = readFileSync('../tests/fixtures/ca.crt', 'utf-8')
+    const der = Buffer.from(pem.replace(/-----[^-]+-----/g, '').replace(/\s/g, ''), 'base64')
+    const fp = createHash('sha256').update(der).digest('base64')
+      .replace(/\+/g, '-').replace(/\//g, '_')
+    servers = [`xftp://${fp}@localhost:7000`]
+    define['__XFTP_SERVERS__'] = JSON.stringify(servers)
+  } else {
+    servers = [...presets.simplex, ...presets.flux]
+  }
+
+  return {
+    root: 'web',
+    build: {outDir: '../dist-web'},
+    define,
+    worker: {format: 'es'},
+    plugins: [cspPlugin(servers)],
+  }
+})
+```
+
+### 8.2 package.json scripts
+
+```json
+"dev": "vite --mode local",
+"build:local": "vite build --mode local",
+"build:prod": "vite build --mode production",
+"preview": "vite preview",
+"check:web": "tsc -p tsconfig.web.json --noEmit && tsc -p tsconfig.worker.json --noEmit"
+```
+
+Note: `check:web` type-checks `src/` twice (once per config) — acceptable for this small library.
+
+Add `vite` as an explicit devDependency (`^6.0.0` — matching the version vitest 3.x depends on transitively). Relying on transitive resolution is fragile across package managers.
+
+### 8.3 TypeScript configuration
+
+The existing `tsconfig.json` has `rootDir: "src"` and `include: ["src/**/*.ts"]` — this is for library compilation only (output to `dist/`). Vite handles `web/` TypeScript compilation independently via esbuild, so the main tsconfig is unchanged. `web/*.ts` files import from `../src/*.js` using relative paths.
+
+Add two tsconfigs for `web/` type-checking — split by environment to avoid type pollution between DOM and WebWorker globals:
+
+`tsconfig.web.json` — main-thread files (DOM globals: `document`, `window`, etc.):
+
+```json
+{
+  "extends": "./tsconfig.json",
+  "compilerOptions": {
+    "rootDir": ".",
+    "noEmit": true,
+    "types": [],
+    "moduleResolution": "bundler",
+    "lib": ["ES2022", "DOM"]
+  },
+  "include": ["web/**/*.ts", "src/**/*.ts"],
+  "exclude": ["web/crypto.worker.ts"]
+}
+```
+
+`tsconfig.worker.json` — Worker file (`self`, `FileSystemSyncAccessHandle`, etc.):
+
+```json
+{
+  "extends": "./tsconfig.json",
+  "compilerOptions": {
+    "rootDir": ".",
+    "noEmit": true,
+    "types": [],
+    "moduleResolution": "bundler",
+    "lib": ["ES2022", "WebWorker"]
+  },
+  "include": ["web/crypto.worker.ts", "src/**/*.ts"]
+}
+```
+
+Both configs set `"types": []` to prevent auto-inclusion of `@types/node` and `"moduleResolution": "bundler"` for Vite-compatible resolution (JSON imports, `.js` extension mapping). The base config's `"moduleResolution": "node"` would cause false type errors on `import ... from './servers.json'`. Both override `@types/node`, which would pollute DOM/WebWorker environments with Node.js globals (`process`, `Buffer`, etc.). This means `src/client.ts`'s dynamic `import("node:http2")` will produce a type error in these configs. This is acceptable — `src/client.ts` provides `createNodeTransport` which is never used in browser code (Vite tree-shakes it out), and full `src/` type-checking is handled by the base `tsconfig.json`. If the error is distracting, add `src/client.ts` to both configs' `exclude` arrays.
+
+Both extend the library tsconfig (inheriting `strict`, `module`, etc.) and include `src/**/*.ts` so imports from `../src/*.js` resolve. `"noEmit": true` means they're only used for type-checking — Vite handles actual compilation. The inherited `"exclude": ["node_modules", "dist", "test"]` intentionally excludes `test/` — test files are type-checked by their own vitest/playwright configs, not by `check:web`.
+
+### 8.4 Dev workflow
+
+`npm run dev` → Vite dev server at `localhost:5173`, configured for local test server. Start `xftp-server` on port 7000 separately (or via the existing globalSetup).
+
+Note: The CSP meta tag's `default-src 'self'` blocks Vite's injected HMR inline scripts in dev mode. The `cspPlugin` handles this by removing the entire CSP `<meta>` tag in serve mode (dev server), so HMR works without restrictions. Production builds always have the correct CSP.
+
+## 9. Library Changes (agent.ts + client.ts)
+
+Changes to support the web page: upload `readChunk` callback, download `onRawChunk` callback with parallel chunk downloads.
+
+### 9.1 Type changes
+
+Split the existing `EncryptedFileInfo` (which currently has `encData`, `digest`, `key`, `nonce`, `chunkSizes` as direct fields) into a metadata-only base and an extension:
+
+```typescript
+// Metadata-only variant (no encData — data lives in Worker/OPFS)
+export interface EncryptedFileMetadata {
+  digest: Uint8Array
+  key: Uint8Array
+  nonce: Uint8Array
+  chunkSizes: number[]
+}
+
+// Full variant (existing, extends metadata with data)
+export interface EncryptedFileInfo extends EncryptedFileMetadata {
+  encData: Uint8Array
+}
+```
+
+### 9.2 uploadFile signature change
+
+Replace positional optional params with an options bag. Add optional `readChunk`. When provided, `encrypted.encData` is not accessed.
+
+```typescript
+export interface UploadOptions {
+  onProgress?: (uploaded: number, total: number) => void
+  redirectThreshold?: number
+  readChunk?: (offset: number, size: number) => Promise<Uint8Array>
+}
+
+export async function uploadFile(
+  agent: XFTPClientAgent,
+  server: XFTPServer,
+  encrypted: EncryptedFileMetadata,
+  options?: UploadOptions
+): Promise<UploadResult>
+```
+
+Inside `uploadFile`:
+- Chunk read: if `options?.readChunk` is provided, use it. Otherwise, verify `'encData' in encrypted` at runtime (throws `"uploadFile: readChunk required when encData is absent"` if missing), then use `(off, sz) => Promise.resolve((encrypted as EncryptedFileInfo).encData.subarray(off, off + sz))`. This guards against calling `uploadFile` with `EncryptedFileMetadata` but no `readChunk`. For each chunk, call `readChunk(offset, size)` once and use the returned `Uint8Array` for both `getChunkDigest(chunkData)` and `uploadXFTPChunk(..., chunkData)` — do not call `readChunk` twice per chunk.
+- Progress total: `const total = encrypted.chunkSizes.reduce((a, b) => a + b, 0)` — replaces `encrypted.encData.length` (line 129) since `EncryptedFileMetadata` has no `encData`. The values are identical: `encData.length === sum(chunkSizes)`.
+- `buildDescription` parameter type: change from `EncryptedFileInfo` to `EncryptedFileMetadata` — it only accesses `chunkSizes`, `digest`, `key`, `nonce` (not `encData`).
+
+`uploadRedirectDescription` (internal) is unchanged — redirect descriptions are always small and created in-memory by `encryptFileForUpload`.
+
+### 9.3 Backward compatibility
+
+The signature change from positional params `(agent, server, encrypted, onProgress?, redirectThreshold?)` to `(agent, server, encrypted, options?)` is a breaking change for callers that pass `onProgress` or `redirectThreshold`. In practice, the only callers are the browser test (which passes no options — no change needed) and the web page (new code). `EncryptedFileInfo` extends `EncryptedFileMetadata`, so existing callers that pass `EncryptedFileInfo` work without change.
+
+### 9.4 client.ts: downloadXFTPChunkRaw
+
+Split `downloadXFTPChunk` at the network/crypto boundary. The new function does DH key exchange and network I/O but skips transit decryption:
+
+```typescript
+export interface RawChunkResponse {
+  dhSecret: Uint8Array
+  nonce: Uint8Array
+  body: Uint8Array
+}
+
+export async function downloadXFTPChunkRaw(
+  c: XFTPClient, rpKey: Uint8Array, fId: Uint8Array
+): Promise<RawChunkResponse> {
+  const {publicKey, privateKey} = generateX25519KeyPair()
+  const cmd = encodeFGET(encodePubKeyX25519(publicKey))
+  const {response, body} = await sendXFTPCommand(c, rpKey, fId, cmd)
+  if (response.type !== "FRFile") throw new Error("unexpected response: " + response.type)
+  const dhSecret = dh(response.rcvDhKey, privateKey)
+  return {dhSecret, nonce: response.nonce, body}
+}
+```
+
+`RawChunkResponse` contains only what client.ts produces (DH secret, nonce, encrypted body). The chunk metadata (`chunkNo`, `digest`) is added by agent.ts when constructing `RawDownloadedChunk` (see §9.5).
+
+The existing `downloadXFTPChunk` is refactored to call `downloadXFTPChunkRaw` + `decryptReceivedChunk`:
+
+```typescript
+export async function downloadXFTPChunk(
+  c: XFTPClient, rpKey: Uint8Array, fId: Uint8Array, digest?: Uint8Array
+): Promise<Uint8Array> {
+  const {dhSecret, nonce, body} = await downloadXFTPChunkRaw(c, rpKey, fId)
+  return decryptReceivedChunk(dhSecret, nonce, body, digest ?? null)
+}
+```
+
+### 9.5 agent.ts: downloadFileRaw, ackFileChunks, RawDownloadedChunk
+
+New type combining client.ts's `RawChunkResponse` with chunk metadata from agent.ts:
+
+```typescript
+export interface RawDownloadedChunk {
+  chunkNo: number
+  dhSecret: Uint8Array
+  nonce: Uint8Array
+  body: Uint8Array
+  digest: Uint8Array
+}
+```
+
+New function providing download orchestration with a raw chunk callback. Handles connection pooling, parallel downloads, redirect resolution, and progress. Does **not** ACK — the caller ACKs after verification.
+
+```typescript
+export interface DownloadRawOptions {
+  onProgress?: (downloaded: number, total: number) => void
+  concurrency?: number  // max parallel chunk downloads, default 1
+}
+
+export async function downloadFileRaw(
+  agent: XFTPClientAgent,
+  fd: FileDescription,
+  onRawChunk: (chunk: RawDownloadedChunk) => Promise<void>,
+  options?: DownloadRawOptions
+): Promise<FileDescription>
+```
+
+Returns the resolved `FileDescription` — for redirect files this is the inner fd, for non-redirect files this is the original fd. The caller uses this for verification and ACK.
+
+Internal structure:
+
+1. Validate `fd` via `validateFileDescription` (may double-validate if caller already validated via `decodeDescriptionURI` — harmless)
+2. If `fd.redirect !== null`: resolve redirect on main thread (redirect data is small):
+   a. Download redirect chunks via `downloadXFTPChunk` (not raw — main thread decryption is fine for a few KB)
+   b. Verify size + digest, `processDownloadedFile` → YAML bytes
+   c. Parse inner `FileDescription`, validate against `fd.redirect.{size, digest}`
+   d. ACK redirect chunks (best-effort — redirect chunks are small and separate from the file chunks)
+   e. Replace `fd` with inner description
+3. Pre-connect: call `getXFTPServerClient(agent, server)` for each unique server before launching concurrent workers. This ensures the client connection exists in the agent's map, avoiding a race condition where multiple concurrent workers all see the client as missing and each call `connectXFTP` independently (leaking all but the last connection). Known limitation: if a connection drops mid-download and multiple workers attempt reconnection simultaneously, the same TOCTOU race reappears. This is a pre-existing issue in `getXFTPServerClient`; a proper fix (per-key connection promise) is out of scope for this plan but should be tracked for follow-up.
+4. Download file chunks in parallel (concurrency-limited via sliding window):
+   - Create a queue of chunk indices `[0, 1, ..., N-1]`. Launch `min(concurrency, N)` async workers, each pulling the next index from the queue until empty. Each worker loops: pull index → derive key → `getXFTPServerClient` → `downloadXFTPChunkRaw` → `await onRawChunk(...)` → update progress → next index. `await Promise.all(workers)` to wait for completion.
+   - For each chunk: derive key (`decodePrivKeyEd25519` → `ed25519KeyPairFromSeed`), get client (`getXFTPServerClient`), call `downloadXFTPChunkRaw`, `await onRawChunk(...)` with result + `chunkNo` + `chunk.digest`
+   - Each concurrency slot awaits its `onRawChunk` before starting the next download on that slot. With `concurrency > 1`, multiple `onRawChunk` calls may be in-flight concurrently (one per slot). The Worker handles this correctly — messages are queued and processed sequentially.
+   - Update progress after each chunk: `downloaded += chunk.chunkSize; onProgress?.(downloaded, resolvedFd.size)` — both values use encrypted sizes for consistency
+5. Return the resolved `fd`
+
+New helper for ACKing after verification:
+
+```typescript
+export async function ackFileChunks(
+  agent: XFTPClientAgent, fd: FileDescription
+): Promise<void> {
+  for (const chunk of fd.chunks) {
+    const replica = chunk.replicas[0]
+    if (!replica) continue
+    try {
+      const client = await getXFTPServerClient(agent, parseXFTPServer(replica.server))
+      const seed = decodePrivKeyEd25519(replica.replicaKey)
+      const kp = ed25519KeyPairFromSeed(seed)
+      await ackXFTPChunk(client, kp.privateKey, replica.replicaId)
+    } catch (_) {}
+  }
+}
+```
+
+The existing `downloadFile` is refactored to use `downloadFileRaw` internally:
+
+```typescript
+export async function downloadFile(
+  agent: XFTPClientAgent,
+  fd: FileDescription,
+  onProgress?: (downloaded: number, total: number) => void
+): Promise<DownloadResult> {
+  const chunks: Uint8Array[] = []
+  const resolvedFd = await downloadFileRaw(agent, fd, async (raw) => {
+    chunks[raw.chunkNo - 1] = decryptReceivedChunk(
+      raw.dhSecret, raw.nonce, raw.body, raw.digest
+    )
+  }, {onProgress})
+  // verify + file-level decrypt using resolvedFd (inner fd for redirect case)
+  const combined = chunks.length === 1 ? chunks[0] : concatBytes(...chunks)
+  if (combined.length !== resolvedFd.size) throw new Error("downloadFile: file size mismatch")
+  const digest = sha512(combined)
+  if (!digestEqual(digest, resolvedFd.digest)) throw new Error("downloadFile: file digest mismatch")
+  // processDownloadedFile re-concatenates chunks internally — this mirrors the
+  // existing downloadFile pattern (verify on concatenated data, then pass chunks
+  // array to decryptChunks which concatenates again). Acceptable overhead for
+  // correctness: verification must happen on transit-decrypted data before
+  // file-level decryption transforms it.
+  const result = processDownloadedFile(resolvedFd, chunks)
+  await ackFileChunks(agent, resolvedFd)
+  return result
+}
+```
+
+Existing callers retain serial behavior (`concurrency` defaults to 1). The web page opts into parallelism by passing `concurrency: 3`. The browser test (`test/browser.test.ts`) continues to work unchanged. The chunks array is initialized empty (`[]`) and populated by sparse index assignment (`chunks[raw.chunkNo - 1] = ...`), so it correctly handles both redirect and non-redirect cases regardless of the outer fd's chunk count. `digestEqual` is an existing module-private helper in agent.ts (line 327) that performs constant-time byte comparison.
+
+### 9.6 Backward compatibility (download)
+
+`downloadFile` signature is unchanged — existing callers are unaffected. The refactoring adds `downloadFileRaw`, `ackFileChunks`, and `RawDownloadedChunk` as new exports from agent.ts, and `downloadXFTPChunkRaw` + `RawChunkResponse` as new exports from client.ts.
+
+## 10. Testing
+
+### 10.1 Existing tests (unchanged)
+
+- `npm run test:browser` — vitest browser round-trip (library-level)
+- `cabal test --test-option='--match=/XFTP Web Client/'` — Haskell per-function tests
+
+### 10.2 New: page E2E test
+
+Add `test/page.spec.ts` using `@playwright/test` (not vitest browser mode — vitest tests run IN the browser and can't control page navigation; Playwright tests run in Node.js and control the browser). Add `@playwright/test` as a devDependency.
+
+Add `playwright.config.ts` at the project root (`xftp-web/`):
+- `webServer: { command: 'vite build --mode local && vite preview', url: 'http://localhost:4173', reuseExistingServer: !process.env.CI }` — the `url` property tells Playwright to wait until the preview server is ready before running tests
+- `use.ignoreHTTPSErrors: true` (test server uses self-signed cert)
+- `use.launchOptions: { args: ['--ignore-certificate-errors'] }` — required because Playwright's `ignoreHTTPSErrors` only affects page navigation, not `fetch()` calls from in-page JavaScript. Without this flag, the page's `createBrowserTransport` fetch to `https://localhost:7000` would fail TLS validation.
+- `globalSetup`: `'./test/globalSetup.ts'` (starts xftp-server, shared with vitest)
+
+```typescript
+import {test, expect} from '@playwright/test'
+
+test('page upload + download round-trip', async ({page}) => {
+  await page.goto(PAGE_URL)
+  // Set file input via page.setInputFiles()
+  // Wait for upload link to appear: page.waitForSelector('[data-testid="share-link"]')
+  // Extract hash from link text
+  // Navigate to PAGE_URL + '#' + hash
+  // Wait for download complete state
+  // Verify file was offered for save (check download event)
+})
+```
+
+Add script: `"test:page": "playwright test test/page.spec.ts"`
+
+This tests the real bundle including Worker loading, OPFS, and CSP. The existing `test/browser.test.ts` continues to test the library-level pipeline (vitest browser mode, no Workers).
+
+### 10.3 Manual testing
+
+`npm run dev` → open `localhost:5173` in browser → drag file → get link → open link in new tab → download. Requires xftp-server running on port 7000 (local mode).
+
+## 11. Files
+
+**Create:**
+- `xftp-web/web/index.html` — page entry point (includes CSP meta tag)
+- `xftp-web/web/main.ts` — router + libsodium init
+- `xftp-web/web/upload.ts` — upload UI + orchestration
+- `xftp-web/web/download.ts` — download UI + orchestration
+- `xftp-web/web/progress.ts` — circular progress canvas component
+- `xftp-web/web/servers.json` — preset server addresses (shared by servers.ts and vite.config.ts)
+- `xftp-web/web/servers.ts` — server configuration (imports servers.json)
+- `xftp-web/web/crypto-backend.ts` — CryptoBackend interface + WorkerBackend + factory
+- `xftp-web/web/crypto.worker.ts` — Web Worker implementation
+- `xftp-web/web/style.css` — styles
+- `xftp-web/vite.config.ts` — page build config (CSP generation, server list)
+- `xftp-web/tsconfig.web.json` — IDE/CI type-checking for `web/` main-thread files (DOM)
+- `xftp-web/tsconfig.worker.json` — IDE/CI type-checking for `web/crypto.worker.ts` (WebWorker)
+- `xftp-web/playwright.config.ts` — Playwright E2E test config (webServer, globalSetup)
+- `xftp-web/test/page.spec.ts` — page E2E test (Playwright)
+
+**Modify:**
+- `xftp-web/src/agent.ts` — add `EncryptedFileMetadata` type, `uploadFile` options bag with `readChunk`, `downloadFileRaw` with `onRawChunk` callback + parallel downloads, `ackFileChunks`, `RawDownloadedChunk` type, refactor `downloadFile` on top of `downloadFileRaw`, add `import {decryptReceivedChunk} from "./download.js"` (needed by refactored `downloadFile`)
+- `xftp-web/src/client.ts` — add `downloadXFTPChunkRaw`, `RawChunkResponse` type, refactor `downloadXFTPChunk` to use raw variant
+- `xftp-web/package.json` — add dev/build/check:web/test:page scripts, add `vite` + `@playwright/test` devDeps
+- `xftp-web/src/protocol/description.ts` — fix stale "SHA-256" comment on `FileDescription.digest` to "SHA-512"
+- `xftp-web/.gitignore` — add `dist-web/`
+
+## 12. Implementation Order
+
+1. **Library refactoring** — `client.ts`: add `downloadXFTPChunkRaw`; `agent.ts`: add `downloadFileRaw` + parallel downloads, `uploadFile` options bag with `readChunk`; refactor existing `downloadFile` on top of `downloadFileRaw`. Run existing tests to verify no regressions.
+2. **Vite config + HTML shell** — `vite.config.ts`, `index.html`, `main.ts`, verify dev server works
+3. **Server config** — `servers.ts` with both local and production server lists
+4. **CryptoBackend + Worker** — interface, WorkerBackend, Worker implementation, OPFS logic
+5. **Upload flow** — `upload.ts` with drag-drop, encrypt via Worker, upload via agent, show link
+6. **Download flow** — `download.ts` with URL parsing, download via agent `downloadFileRaw`, Worker decrypt, browser save
+7. **Progress component** — `progress.ts` canvas drawing
+8. **Styling** — `style.css`
+9. **Testing** — page E2E test, manual browser verification
+10. **Build scripts** — `build:local`, `build:prod` in package.json
@@ -0,0 +1,53 @@
+# XFTPClientAgent Pattern
+
+## TOC
+1. Executive Summary
+2. Changes: client.ts
+3. Changes: agent.ts
+4. Changes: test/browser.test.ts
+5. Verification
+
+## Executive Summary
+
+Add `XFTPClientAgent` — a per-server connection pool matching the Haskell pattern. The agent caches `XFTPClient` instances by server URL. All orchestration functions (`uploadFile`, `downloadFile`, `deleteFile`) take `agent` as first parameter and use `getXFTPServerClient(agent, server)` instead of calling `connectXFTP` directly. Connections stay open on success; the caller creates and closes the agent.
+
+`connectXFTP` and `closeXFTP` stay exported (used by `XFTPWebTests.hs` Haskell tests). The `browserClients` hack, per-function `connections: Map`, and `getOrConnect` are deleted.
+
+## Changes: client.ts
+
+**Add** after types section: `XFTPClientAgent` interface, `newXFTPAgent`, `getXFTPServerClient`, `closeXFTPServerClient`, `closeXFTPAgent`.
+
+**Delete**: `browserClients` Map and all `isNode` browser-cache checks in `connectXFTP` and `closeXFTP`.
+
+**Revert `closeXFTP`** to unconditional `c.transport.close()` (browser transport.close() is already a no-op).
+
+`connectXFTP` stays exported (backward compat) but becomes a raw low-level function — no caching.
+
+## Changes: agent.ts
+
+**Imports**: replace `connectXFTP`/`closeXFTP` with `getXFTPServerClient`/`closeXFTPAgent` etc.
+
+**Re-export** from agent.ts: `newXFTPAgent`, `closeXFTPAgent`, `XFTPClientAgent`.
+
+**`uploadFile`**: add `agent: XFTPClientAgent` as first param. Replace `connectXFTP` → `getXFTPServerClient`. Remove `finally { closeXFTP }`. Pass `agent` to `uploadRedirectDescription`.
+
+**`uploadRedirectDescription`**: change from `(client, server, innerFd)` to `(agent, server, innerFd)`. Get client via `getXFTPServerClient`.
+
+**`downloadFile`**: add `agent` param. Delete local `connections: Map`. Replace `getOrConnect` → `getXFTPServerClient`. Remove finally cleanup. Pass `agent` to `downloadWithRedirect`.
+
+**`downloadWithRedirect`**: add `agent` param. Same replacements. Remove try/catch cleanup. Recursive call passes `agent`.
+
+**`deleteFile`**: add `agent` param. Same pattern.
+
+**Delete**: `getOrConnect` function entirely.
+
+## Changes: test/browser.test.ts
+
+Create agent before operations, pass to upload/download, close in finally.
+
+## Verification
+
+1. `npx vitest --run` — browser round-trip test passes
+2. No remaining `browserClients`, `getOrConnect`, or per-function `connections: Map` locals
+3. `connectXFTP` and `closeXFTP` still exported (XFTPWebTests.hs compat)
+4. All orchestration functions take `agent` as first param
--- a/Show More
+++ b/Show More