migration

.github/CODEOWNERS

@@ -1,4 +1 @@
-* @epoberezkin @spaced4ndy
-/Dockerfile @shumvgolove
-/scripts/docker/ @shumvgolove
-/scripts/main/ @shumvgolove
+* @epoberezkin @efim-poberezkin

.github/workflows/build.yml

@@ -11,59 +11,34 @@ on:
 
 jobs:
   build:
-    name: build-${{ matrix.os }}-${{ matrix.ghc }}
-    runs-on: ${{ matrix.os }}
-    strategy:
-      fail-fast: false
-      matrix:
-        include:
-          - os: ubuntu-20.04
-            platform_name: 20_04-x86-64
-            ghc: "8.10.7"
-          - os: ubuntu-20.04
-            platform_name: 20_04-x86-64
-            ghc: "9.6.3"
-          - os: ubuntu-22.04
-            platform_name: 22_04-x86-64
-            ghc: "9.6.3"
+    runs-on: ubuntu-20.04
     steps:
       - name: Clone project
-        uses: actions/checkout@v3
+        uses: actions/checkout@v2
 
-      - name: Setup Haskell
-        uses: haskell-actions/setup@v2
+      - name: Setup Stack
+        uses: haskell/actions/setup@v1
         with:
-          ghc-version: ${{ matrix.ghc }}
-          cabal-version: "3.10.1.0"
+          ghc-version: '8.10.7'
+          enable-stack: true
+          stack-version: 'latest'
 
       - name: Cache dependencies
         uses: actions/cache@v2
         with:
-          path: |
-            ~/.cabal/store
-            dist-newstyle
-          key: ${{ matrix.os }}-${{ hashFiles('cabal.project', 'simplexmq.cabal') }}
+          path: ~/.stack
+          key: ${{ hashFiles('stack.yaml') }}
 
-      - name: Build
-        shell: bash
-        run: cabal build --enable-tests
-
-      - name: Test
-        timeout-minutes: 40
-        shell: bash
-        run: cabal test --test-show-details=direct
-
-      - name: Prepare binaries
-        if: startsWith(github.ref, 'refs/tags/v')
+      - name: Build & test
+        id: build_test
         shell: bash
         run: |
-          mv $(cabal list-bin smp-server) smp-server-ubuntu-${{ matrix.platform_name}}
-          mv $(cabal list-bin ntf-server) ntf-server-ubuntu-${{ matrix.platform_name}}
-          mv $(cabal list-bin xftp-server) xftp-server-ubuntu-${{ matrix.platform_name}}
-          mv $(cabal list-bin xftp) xftp-ubuntu-${{ matrix.platform_name}}
+          stack build --test --force-dirty
+          install_root=$(stack path --local-install-root)
+          mv ${install_root}/bin/smp-server smp-server-ubuntu-20_04-x86-64
 
       - name: Build changelog
-        if: startsWith(github.ref, 'refs/tags/v') && matrix.os == 'ubuntu-22.04'
+        if: startsWith(github.ref, 'refs/tags/v')
         id: build_changelog
         uses: mikepenz/release-changelog-builder-action@v1
         with:
@@ -74,8 +49,19 @@ jobs:
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
+      - name: Extract release candidate
+        if: startsWith(github.ref, 'refs/tags/v')
+        id: extract_release_candidate
+        shell: bash
+        run: |
+          if [[ ${GITHUB_REF} == *rc* ]]; then
+            echo "::set-output name=release_candidate::true"
+          else
+            echo "::set-output name=release_candidate::false"
+          fi
+
       - name: Create release
-        if: startsWith(github.ref, 'refs/tags/v') && matrix.ghc != '8.10.7'
+        if: startsWith(github.ref, 'refs/tags/v')
         uses: softprops/action-gh-release@v1
         with:
           body: |
@@ -83,13 +69,10 @@ jobs:
 
             Commits:
             ${{ steps.build_changelog.outputs.changelog }}
-          prerelease: true
+          prerelease: ${{ steps.extract_release_candidate.outputs.release_candidate }}
           files: |
             LICENSE
-            smp-server-ubuntu-${{ matrix.platform_name}}
-            ntf-server-ubuntu-${{ matrix.platform_name}}
-            xftp-server-ubuntu-${{ matrix.platform_name}}
-            xftp-ubuntu-${{ matrix.platform_name}}
+            smp-server-ubuntu-20_04-x86-64
           fail_on_unmatched_files: true
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/docker-image.yml

@@ -1,50 +0,0 @@
-name: Build and push Docker image to Docker Hub
-
-on:
-  push:
-    tags:
-      - "v*"
-
-jobs:
-  build-and-push:
-    name: Build and push Docker image
-    runs-on: ubuntu-latest
-    strategy:
-      fail-fast: false
-      matrix:
-        include:
-          - app: smp-server
-            app_port: 5223
-          - app: xftp-server
-            app_port: 443 
-    steps:
-      - name: Clone project
-        uses: actions/checkout@v3
-
-      - name: Log in to Docker Hub
-        uses: docker/login-action@v2
-        with:
-          username: ${{ secrets.DOCKERHUB_USERNAME }}
-          password: ${{ secrets.DOCKERHUB_PASSWORD }}
-
-      - name: Extract metadata for Docker image
-        id: meta
-        uses: docker/metadata-action@v4
-        with:
-          images: ${{ secrets.DOCKERHUB_USERNAME }}/${{ matrix.app }}
-          flavor: |
-            latest=auto
-          tags: |
-            type=semver,pattern=v{{version}}
-            type=semver,pattern=v{{major}}.{{minor}}
-            type=semver,pattern=v{{major}}
-
-      - name: Build and push Docker image
-        uses: docker/build-push-action@v4
-        with:
-          push: true
-          build-args: |
-            APP=${{ matrix.app }}
-            APP_PORT=${{ matrix.app_port }}
-          tags: ${{ steps.meta.outputs.tags }}
-          labels: ${{ steps.meta.outputs.labels }}

.gitignore

@@ -4,10 +4,3 @@
 *.session.sql
 tests/tmp
 dist-newstyle/
-
-cabal.project.local
-cabal.project.local~
-
-.hpc/
-*.tix
-.coverage

.hlint.yaml

@@ -1 +0,0 @@
-- ignore: {name: "Use underscore"}

CHANGELOG.md

@@ -1,504 +1,9 @@
-# 5.8.0
-
-Version 5.8.0.10
-
-SMP server and client:
-- protocol extension to forward messages to the destination servers, to protect sending client IP address and transport session.
-
-Agent:
-- process timed out subscription responses to reduce the number of resubscriptions.
-- avoid sending messages and commands when waiting for response timed out (except batched SUB and DEL commands).
-- fix issue with stuck message reception on slow connection (when response to ACK timed out, and the new message was not processed until resubscribed).
-- fix issue when temporary file sending or receiving error was treated as permanent.
-
-SMP server:
-- include OK responses to all batched SUB requests to reduce subscription timeouts.
-
-XFTP server:
-- report file upload timeout as TIMEOUT, to avoid delivery failure.
-
-# 5.7.6
-
-XFTP agent:
-- treat XFTP handshake timeouts and network errors as temporary, to retry file operations.
-
-# 5.7.5
-
-SMP agent:
-- fail if non-unique connection IDs are passed to sendMessages (to prevent client errors and deadlocks).
-
-# 5.7.4
-
-SMP agent:
-- remove re-subscription timeouts (as they are tracked per operation, and could cause failed subscriptions).
-- reconnect XFTP clients when network settings changes.
-- fix lock contention resulting in stuck subscriptions on network change.
-
-# 5.7.3
-
-SMP/NTF protocol:
-- add ALPN for handshake version negotiation, similar to XFTP (to preserve backwards compatibility with the old clients).
-- upgrade clients to versions v7/v2 of the protocols.
-
-SMP server:
-- faster responses to subscription requests.
-
-XFTP client:
-- fix network exception during file download treated as permanent file error.
-
-SMP agent:
-- do not report subscription timeouts while client is offline.
-
-# 5.7.2
-
-SMP agent:
-- fix connections failing when connecting via link due to race condition on slow network.
-- remove concurrency limit when waiting for connection subscription.
-- remove TLS timeout.
-
-# 5.7.1
-
-SMP agent:
-- increase timeout for TLS connection via SOCKS
-
-# 5.7.0
-
-Version 5.7.0.4
-
-_Please note_: the earliest SimpleX Chat clients supported by this version of the servers is 5.5.3 (released on February 11, 2024).
-
-SMP server:
-- increase max SMP protocol version to 7 (support for deniable authenticators).
-
-NTF server:
-- increase max NTF protocol version to 2 (support for deniable authenticators).
-
-XFTP server:
-- version handshake using ALPN.
-
-SMP agent:
-- increase timeouts for XFTP files.
-- don't send commands after timeout.
-- PQ encryption support.
-
-# 5.6.2
-
-Version 5.6.2.2.
-
-SMP agent:
-- Lower memory consumption (~20-25%).
-- More stable XFTP file uploads and downloads.
-- API to receive network connectivity changes from the apps.
-- to reduce battery consumption: connection attempts interval growing to every 2 hours when app reports as offline.
-- to reduce retries and traffic: 50% increased timeouts when on mobile network.
-
-XFTP server:
-- expire files on start.
-- version negotiation based on TLS ALPN and handshake.
-
-NTF server:
-- reduced downtime by ~100x faster start time.
-- exclude test tokens from statistics.
-
-# 5.6.1
-
-Version 5.6.1.0.
-
-- Much faster iOS notification server start time (fewer skipped notifications).
-- Fix SMP server stored message stats.
-- Prevent overwriting uploaded XFTP files with subsequent upload attempts.
-- Faster base64 encoding/parsing.
-- Control port audit log and authentication.
-
-# 5.6.0
-
-Version 5.6.0.4.
-
-SMP protocol/client/server:
-- support deniable sender command authorization (to be enabled in the next version).
-- remove support for SMP protocol versions (prior to v4, 07/2022).
-
-Agent:
-- optional post-quantum key agreement using sntrup761 in double ratchet protocol.
-- improve performance of deleting multiple connections and files by batching database operations.
-- delay connection deletion to deliver pending messages.
-- API to test for notifications server.
-- remove support for client protocols versions (prior to 10/2022).
-
-XFTP server:
-- restore storage quota in case of failed uploads.
-
-Performance and stability improvements.
-
-# 5.5.3
-
-Agent:
-- notification token API also returns active notifications server.
-- support file descriptions with redirection and file URIs.
-
-Servers:
-- CLI commands for online key and certificate rotation.
-- Configure config and log paths via environment variables.
-
-# 5.5.2
-
-Extensible handshake for clients and SMP/NTF servers (ignore extra data).
-
-# 5.5.1
-
-SMP servers:
-- do not keep stats file open
-- additional stats about currently stored messages
-
-Agent:
-- support multiple notification servers (only one can be used at a time).
-- expire messages after "quota exceeded" error after 7 days (instead of 21 days previously).
-- stabilize message delivery, remove unnecessary subscription retries and traffic.
-- improve database performance for message delivery.
-- fix sockets/memory leak - a very old bug "activated" by improvements in v5.5.0.
-
-# 5.5.0
-
-Code:
-- compatible with GHC 8.10.7 to support compilation for armv7a.
-- migrate to `crypton` from deprecated `cryptonite` (the seed for DRG is now sha512-hashed).
-- use ChaChaDRG for all random IDs, keys and nonces, only using hashed entropy as seed.
-- more efficient transaction batching in SMP protocol client and server.
-
-Agent:
-- stabilize message reception and delivery, migrate message delivery to database queue.
-- additional event MSGNTF confirming that message received via notification is processed.
-- efficient processing of messages sent to multiple recipients with batched database transactions.
-- new worker abstraction for all queued tasks resilient to race conditions and some database errors.
-- many fixed race conditions.
-- background mode for iOS NSE.
-- additional error reporting to client on critical errors (to be show as alert in the clients).
-- functional api to get worker statistics.
-
-SMP/XFTP servers:
-- fix socket and memory leak on servers with high load (inactive clients without subscriptions are disconnected after set time of inactivity).
-- control port improvements.
-- fix statistics for stored queues, messages and files.
-- make writing to store log atomic (fixes a rare bug in XFTP server).
-
-# 5.4.0
-
-Migrate to GHC 9.6.3
-
-Agent:
-- database improvements:
-  - track slow queries.
-  - better performance.
-  - "busy" error handling.
-  - create parent folder when needed.
-  - support closing and re-opening database.
-- SMP agent improvements
-  - streaming for batched SMP commands.
-  - fix asynchronous JOINing connection.
-  - handle repeating JOINs without failure.
-  - api to get subscribed connections.
-  - return simplex:/ links as invitations.
-  - fix memory leak.
-- XFTP improvements:
-  - suspend when agent is suspended.
-  - support locally encrypted files.
-  - fixes - create empty file, prevent permanent error treated as temporary.
-  - upgrade HTTP2 library (fixes error handling and flow control).
-- Remote control protocol (XRCP)
-
-SMP server:
-- control port commands for GHC threads introspection.
-- allow creating new queues without subscriptions (required for iOS).
-
-XFTP server:
-- allow 64kb file chunks.
-
-NTF server:
-- faster startup.
-
-# 5.3.0
-
-Agent:
-- improve performance, track slow database queries.
-- support delivery receipts.
-
-SMP server:
-- control port
-
-# 5.2.0 (NTF server 1.5.0)
-
-Agent:
-- treat agent INACTIVE error as temporary - fixes failed message delivery in some race conditions.
-- restore connection confirmations after client restart - fixes failed connections.
-- ratchet resynchronization protocol and API.
-- increase connection version to mutually supported by both peers on each received message.
-
-Client:
-- make timeout for batched functions dependent on the number of batches - fixes expiry on large batches.
-
-Servers:
-- add timeout in case of sending TCP traffic and in case of partial delivery of requested blocks to avoid resource leaks.
-
-# 5.1.2, 5.1.3 (NTF server 1.4.1, 1.4.2)
-
-Agent:
-- ACK message on decryption error (fixes stuck message delivery bug)
-- more robust connection switching logic, API to abort switching the address
-
-Notification server:
-- batch subscriptions to SMP servers
-
-# 5.1.1 (NTF server 1.4.0)
-
-Agent:
-- store and check hashes of previous encrypted messages to differentiate between duplicates and decryption errors
-
-Server:
-- larger processing queues
-- expire messages when restoring them
-
-# 5.1.0
-
-XFTP client:
-- check encrypted file exists when uploading
-- remove user ID from deletion API
-
-Agent:
-- vacuum database on migrations
-
-SMP server:
-- configure message expiration time in INI file
-
-# 5.0.0
-
-SimpleX File Transfer Protocol (XFTP):
-- XFTP server
-- XFTP CLI
-- support XFTP in the agent
-
-Other changes:
-- preserve retry interval for sending messages on agent restarts
-- support IPv6 in the servers and in the agent
-- support for 32-bit platforms
-
-Read more about XFTP in this post: https://simplex.chat/blog/20230301-simplex-file-transfer-protocol.html
-
-# 4.4.1
-
-SMP agent:
-
-- fix handling of server addresses.
-- prevent message delivery getting stuck on IO error in SMP client.
-
-# 4.4.0
-
-SMP agent:
-
-- support multiple user profiles with transport session isolation.
-- support optional transport isolation per connection.
-- batch connection deletion
-- improve asynchronous connection deletion – it may now be completed after the client is restarted as well.
-- improve subscription logic to retry if initial attempt fails.
-- end SMP client connection after a number of failed PINGs (default is 3).
-
-# 4.3.0
-
-SMP server:
-
-- additional server usage statistics.
-
-SMP agent:
-
-- increase retry interval when sending messages after ERR QUOTA.
-
-# 4.2.0
-
-SMP agent and server:
-
-- reduce sender traffic in cases when queue quota is exceeded:
-  - server sends quota exceeded message to the recipient when sender receives ERR QUOTA.
-  - recipient sends QCONT message to the send once the queue is drained (via reply queue).
-  - sender retry delays are increased, reducing traffic, but sender instantly resumes delivery where QCONT is received.
-
-SMP server:
-
-- increase internal queue sizes.
-
-SMP agent:
-
-- deduplicate connection IDs in connect/disconnect responses.
-- unit tests for Crypto.hs.
-- fix connection switch to another queue: correctly set primary send queue.
-
-Notification server (v1.3.0):
-
-- check token status when sending verification notification.
-
-# 4.1.0
-
-SMP agent and server:
-
-- option to toggle TLS handshake error logs (disabled by default).
-
-SMP agent:
-
-- include server address in BROKER error.
-- api to get hash of double ratchet associated data (for connection verification).
-- api to get agent statistics.
-
-# 4.0.0
-
-SMP server:
-
-- Basic authentication. The server address can now include an optional password that is required to create messaging queues, so the contacts who message you will not be able to receive messages via your server, unless you share with them the address with the password. It is recommended to enable basic authentication on all private servers by adding `create_password` parameter into AUTH section of server INI file (the previously deployed servers do not have this section, you need to add it).
-- Disable creating new queues completely with `new_queues: off` parameter in AUTH section of INI file - it can be used to simplify migrating the existing connections to another server.
-- Updated server CLI with changed defaults:
-  - interactive server initialization, use -y flag to initialize the server non-interactively.
-  - store log is now enabled by default, so messaging queues and messages are restored when the server is restarted (to restore undelivered messages the server needs to be stopped with SIGINT signal).
-  - a random password is now generated by default during the server initialization.
-
-SMP agent:
-
-- API to test SMP servers. It connects to the server, creates and deletes a messaging queue. The new SimpleX Chat client uses this API to allow you to test that you have the correct server address, with the valid certificate fingerprint and password, before enabling the new server.
-
-# 3.4.0
-
-SMP agent:
-
-- increase concurrency with connection-level locks
-- fix issues identified in security assessment (see the announcement: https://github.com/simplex-chat/simplex-chat/blob/stable/blog/20221108-simplex-chat-v4.2-security-audit-new-website.md)
-- manual connection queue rotation
-- optional client data in connection requests links
-
-SMP server:
-
-- specialize monad stack to improve performance
-- log slow commands
-
-# 3.3.0
-
-SMP server:
-
-- allow repeated KEY command with the same key (to avoid failures on retries)
-
-SMP agent:
-
-- enable/disable connection notifications
-- asynchronous commands that retry on network error
-- use SQLCipher
-
-# 3.2.0
-
-SMP agent:
-
-- Support multiple server hostnames (including onion hostnames) in server addresses.
-- Network configuration options.
-- Options to define rules to choose server hostname.
-
-# 3.1.0
-
-SMP server and agent:
-
-- SMP protocol v4: batching multiple server commands/responses in a transport block.
-
-# 3.0.0
-
-SMP server:
-
-- restore undelivered messages when the server is restarted.
-- SMP protocol v3 to support push notification:
-  - updated SEND and MSG to add message flags (for notification flag that confirm whether the notification is sent and for any future extensions) and to move message meta-data sent to the recipient into the encrypted envelope.
-  - update NKEY and NID to add e2e encryption keys (for the notification meta-data encryption between SMP server and the client), and update NMSG to include this meta-data.
-  - update ACK command to include message ID (to avoid acknowledging unprocessed message).
-  - add NDEL commands to remove notification subscription credentials from SMP queue.
-  - add GET command to receive messages without subscription - to be used in iOS notification service extension to receive messages without terminating app subscriptions.
-
-SMP agent:
-
-- new protocol for duplex connection handshake reducing traffic and connection time.
-- support for SMP notifications server and managing device token.
-- remove redundant FQDN validation from TLS handshake to prepare for access via Tor.
-- support for fully stopping agent and for temporary suspending agent operations.
-- improve management of duplicate message delivery.
-
-SMP notifications server v1.0:
-
-- SMP notifications protocol with version negotiation during handshake.
-- device token registration and verification (via background notification).
-- SMP notification subscriptions and push notifications via APNS.
-- restoring notification subscriptions when the server is restarted.
-
-# 2.3.0
-
-SMP server:
-
-- Save and restore undelivered messages, to avoid losing them. To save messages the server has to be stopped with SIGINT signal, if it is stopped with SIGTERM undelivered messages would not be saved.
-
-# 2.2.0
-
-SMP server:
-
-- Fix sockets/threads/memory leak
-
-SMP agent:
-
-- Support stopping and resuming agent with `disconnectAgentClient` / `resumeAgentClient`
-
-# 2.1.1
-
-SMP server:
-
-- gracefully close sockets on client disconnection
-- CLI warning when deleting server configuration
-
-# 2.1.0
-
-SMP server:
-
-- configuration to expire inactive clients in ini file, increased TTL and check interval for client expiration
-
-# 2.0.0
-
-Push notifications server (beta):
-
-- supports APNS
-- manage device tokens verification via notification delivery
-- sending periodic background notification to check messages (not more frequent than every 20 min)
-
-SMP server:
-
-- disconnect inactive clients after some period
-- remove undelivered messages after 30 days
-- log aggregate usage daily stats: only the number of queues created/secured/deleted/used and messages sent/delivered is logged, as one line per day, so we can plan server capacity and diagnose any problems.
-
-SMP agent:
-
-- manage device tokens and notification server connection
-- DOWN/UP events to the agent user about server disconnections/reconnections are now sent once per server
-
-# 1.1.0
-
-SMP server:
-
-- message TTL and periodic deletion of old messages
-- configuration to prevent creation of the new queues
-
-SMP agent:
-
-- asynchronous connection handshake
-- configurable SMP servers at run-time
-- use TCP keep-alive for connection stability
-- improve stability of connection subscriptions
-- auto-vacuum DB to remove deleted records
-
 # 1.0.3
 
 SMP server:
-
 - Reduce server message queue quota to 128 messages.
 
 SMP agent:
-
 - Add "yes to migrations" option.
 - Make new SMP client attempt to reconnect on network error.
 - Reduce connection handshake expiration to 2 days.
@@ -508,29 +13,24 @@ JSON encoding of types used in simplex-chat, some other minor adjustments.
 # 1.0.2
 
 General:
-
 - Enable TLS 1.3 parameters for TLS handshake (server and client).
 - Switch from hs-tls fork to original repo now that it supports getFinished and getPeerFinished APIs for both TLS 1.2 and TLS 1.3.
 
 SMP server:
-
 - Perform TLS handshake in a separate thread per-connection.
 
 SMP agent:
-
 - Cease attempts to send HELLO after one week timeout.
 - Coalesce requests to connect to SMP servers, to have 1 connection per server.
 
 # 1.0.1
 
 SMP server:
-
 - Explicitly set line buffering in stdout/stderr to log each line when output is redirected to files.
 
 # 1.0.0
 
 Security and privacy improvements:
-
 - Faster and more secure 2-layer E2E encryption with additional encryption layer between servers and recipients:
   - application messages in each duplex connection (managed by SMP agents - see [overview](https://github.com/simplex-chat/simplexmq/blob/master/protocol/overview-tjr.md)) are encrypted using [double-ratchet algorithm](https://www.signal.org/docs/specifications/doubleratchet/), providing forward secrecy and break-in recovery. This layer uses two Curve448 keys per client for [X3DH key agreement](https://www.signal.org/docs/specifications/x3dh/), SHA512 based HKDFs and AES-GCM AEAD encryption.
   - SMP client messages are additionally E2E encrypted in each SMP queue to avoid cipher-text correlation of messages sent via multiple redundant queues (that will be supported soon). This and the next layer use [NaCl crypto_box algorithm](https://nacl.cr.yp.to/index.html) with XSalsa20Poly1305 cipher and Curve25519 keys for DH key agreement.
@@ -543,16 +43,13 @@ Security and privacy improvements:
 - Server identity verification via server offline certificate fingerprints included in SMP server addresses.
 
 New functionality:
-
 - Support for notification servers with new SMP commands: `NKEY`/`NID`, `NSUB`/`NMSG`.
 
 Efficiency improvements:
-
 - Binary protocol encodings to reduce overhead from circa 15% to approximately 3.7% of transmitted application message size, with only 2.2% overhead for SMP protocol messages.
 - More performant cryptographic algorithms.
 
 For more information about SimpleX:
-
 - [SimpleX overview](https://github.com/simplex-chat/simplexmq/blob/master/protocol/overview-tjr.md).
 - [SimpleX chat v1 announcement](https://github.com/simplex-chat/simplex-chat/blob/master/blog/20220112-simplex-chat-v1-released.md).
 

Dockerfile

@@ -1,62 +0,0 @@
-ARG TAG=22.04
-
-FROM ubuntu:${TAG} AS build
-
-### Build stage
-
-# Install curl and git and simplexmq dependencies
-RUN apt-get update && apt-get install -y curl git build-essential libgmp3-dev zlib1g-dev llvm-12 llvm-12-dev libnuma-dev libssl-dev
-
-# Specify bootstrap Haskell versions
-ENV BOOTSTRAP_HASKELL_GHC_VERSION=9.6.3
-ENV BOOTSTRAP_HASKELL_CABAL_VERSION=3.10.1.0
-
-# Install ghcup
-RUN curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | BOOTSTRAP_HASKELL_NONINTERACTIVE=1 sh
-
-# Adjust PATH
-ENV PATH="/root/.cabal/bin:/root/.ghcup/bin:$PATH"
-
-# Set both as default
-RUN ghcup set ghc "${BOOTSTRAP_HASKELL_GHC_VERSION}" && \
-    ghcup set cabal "${BOOTSTRAP_HASKELL_CABAL_VERSION}"
-
-COPY . /project
-WORKDIR /project
-
-ARG APP
-ARG APP_PORT
-RUN if [ -z "$APP" ] || [ -z "$APP_PORT" ]; then printf "Please spcify \$APP and \$APP_PORT build-arg.\n"; exit 1; fi
-
-# Compile app
-RUN cabal update
-RUN cabal build exe:$APP
-
-# Create new path containing all files needed
-RUN mkdir /final
-WORKDIR /final
-
-# Strip the binary from debug symbols to reduce size
-RUN bin=$(find /project/dist-newstyle -name "$APP" -type f -executable) && \
-    mv "$bin" ./ && \
-    strip ./"$APP" &&\
-    mv /project/scripts/docker/entrypoint-"$APP" ./entrypoint
-
-### Final stage
-FROM ubuntu:${TAG}
-
-# Install OpenSSL dependency
-RUN apt-get update && apt-get install -y openssl libnuma-dev
-
-# Copy compiled app from build stage
-COPY --from=build /final /usr/local/bin/
-
-# Open app listening port
-ARG APP_PORT
-EXPOSE $APP_PORT
-
-# simplexmq requires using SIGINT to correctly preserve undelivered messages and restore them on restart
-STOPSIGNAL SIGINT
-
-# Finally, execute helper script
-ENTRYPOINT [ "/usr/local/bin/entrypoint" ]

README.md

@@ -11,7 +11,7 @@ If you have a server deployed please deploy a new server to a new host and retir
 
 ## Message broker for unidirectional (simplex) queues
 
-SimpleXMQ is a message broker for managing message queues and sending messages over public network. It consists of SMP server, SMP client library and SMP agent that implement [SMP protocol](./protocol/simplex-messaging.md) for client-server communication and [SMP agent protocol](./protocol/agent-protocol.md) to manage duplex connections via simplex queues on multiple SMP servers.
+SimpleXMQ is a message broker for managing message queues and sending messages over public network. It consists of SMP server, SMP client library and SMP agent that implement [SMP protocol](https://github.com/simplex-chat/simplexmq/blob/master/protocol/simplex-messaging.md) for client-server communication and [SMP agent protocol](https://github.com/simplex-chat/simplexmq/blob/master/protocol/agent-protocol.md) to manage duplex connections via simplex queues on multiple SMP servers.
 
 SMP protocol is inspired by [Redis serialization protocol](https://redis.io/topics/protocol), but it is much simpler - it currently has only 10 client commands and 8 server responses.
 
@@ -27,19 +27,17 @@ SimpleXMQ is implemented in Haskell - it benefits from robust software transacti
 
 ### SMP server
 
-[SMP server](./apps/smp-server/Main.hs) can be run on any Linux distribution, including low power/low memory devices. OpenSSL library is required for initialization.
+[SMP server](https://github.com/simplex-chat/simplexmq/blob/master/apps/smp-server/Main.hs) can be run on any Linux distribution without any dependencies, including low power/low memory devices.
 
-To initialize the server use `smp-server init -n <fqdn>` (or `smp-server init --ip <ip>` for IP based address) command - it will generate keys and certificates for TLS transport. The fingerprint of offline certificate is used as part of the server address to protect client/server connection against man-in-the-middle attacks: `smp://<fingerprint>@<hostname>[:5223]`.
+To initialize the server use `smp-server init` command - it will generate keys and certificates for TLS transport. The fingerprint of offline certificate is used as part of the server address to protect client/server connection against man-in-the-middle attacks: `smp://<fingerprint>@<hostname>[:5223]`.
 
 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.
 
-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.
-
 > **Please note:** On initialization SMP server creates a chain of two certificates: a self-signed CA certificate ("offline") and a server certificate used for TLS handshake ("online"). **You should store CA certificate private key securely and delete it from the server. If server TLS credential is compromised this key can be used to sign a new one, keeping the same server identity and established connections.** CA private key location by default is `/etc/opt/simplex/ca.key`.
 
-SMP server implements [SMP protocol](./protocol/simplex-messaging.md).
+SMP server implements [SMP protocol](https://github.com/simplex-chat/simplexmq/blob/master/protocol/simplex-messaging.md).
 
 #### Running SMP server on MacOS
 
@@ -62,21 +60,20 @@ Now `openssl version` should be saying "OpenSSL". You can now run `smp-server in
 
 ### SMP client library
 
-[SMP client](./src/Simplex/Messaging/Client.hs) is a Haskell library to connect to SMP servers that allows to:
-
+[SMP client](https://github.com/simplex-chat/simplexmq/blob/master/src/Simplex/Messaging/Client.hs) is a Haskell library to connect to SMP servers that allows to:
 - execute commands with a functional API.
 - receive messages and other notifications via STM queue.
 - automatically send keep-alive commands.
 
 ### SMP agent
 
-[SMP agent library](./src/Simplex/Messaging/Agent.hs) can be used to run SMP agent as part of another application and to communicate with the agent via STM queues, without serializing and parsing commands and responses.
+[SMP agent library](https://github.com/simplex-chat/simplexmq/blob/master/src/Simplex/Messaging/Agent.hs) can be used to run SMP agent as part of another application and to communicate with the agent via STM queues, without serializing and parsing commands and responses.
 
-Haskell type [ACommand](./src/Simplex/Messaging/Agent/Protocol.hs) represents SMP agent protocol to communicate via STM queues.
+Haskell type [ACommand](https://github.com/simplex-chat/simplexmq/blob/master/src/Simplex/Messaging/Agent/Protocol.hs) represents SMP agent protocol to communicate via STM queues.
 
 See [simplex-chat](https://github.com/simplex-chat/simplex-chat) terminal UI for the example of integrating SMP agent into another application.
 
-[SMP agent executable](./apps/smp-agent/Main.hs) can be used to run a standalone SMP agent process that implements plaintext [SMP agent protocol](./protocol/agent-protocol.md) via TCP port 5224, so it can be used via telnet. It can be deployed in private networks to share access to the connections between multiple applications and services.
+[SMP agent executable](https://github.com/simplex-chat/simplexmq/blob/master/apps/smp-agent/Main.hs) can be used to run a standalone SMP agent process that implements plaintext [SMP agent protocol](https://github.com/simplex-chat/simplexmq/blob/master/protocol/agent-protocol.md) via TCP port 5224, so it can be used via telnet. It can be deployed in private networks to share access to the connections between multiple applications and services.
 
 ## Using SMP server and SMP agent
 
@@ -90,155 +87,7 @@ You can either run your own SMP server locally or deploy using [Linode StackScri
 
 It's the easiest to try SMP agent via a prototype [simplex-chat](https://github.com/simplex-chat/simplex-chat) terminal UI.
 
-## Deploy SMP/XFTP servers on Linux
-
-You can run your SMP/XFTP server as a Linux process, optionally using a service manager for booting and restarts.
-
-Notice that `smp-server` and `xftp-server` requires `openssl` as run-time dependency (it is used to generate server certificates during initialization). Install it with your packet manager:
-
-```sh
-# For Ubuntu
-apt update && apt install openssl
-```
-
-### Install binaries
-
-#### Using Docker
-
-On Linux, you can deploy smp and xftp server using Docker. This will download image from [Docker Hub](https://hub.docker.com/r/simplexchat).
-
-1. Create directories for persistent Docker configuration:
-
-   ```sh
-   mkdir -p $HOME/simplex/{xftp,smp}/{config,logs} && mkdir -p $HOME/simplex/xftp/files
-   ```
-
-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 \
-         -e "ADDR=your_ip_or_domain" \
-         -e "PASS=password" \
-         -p 5223:5223 \
-         -v $HOME/simplex/smp/config:/etc/opt/simplex:z \
-         -v $HOME/simplex/smp/logs:/var/opt/simplex:z \
-         simplexchat/smp-server:latest
-     ```
-
-   - `xftp-server`
-   
-     You must change **your_ip_or_domain** and **maximum_storage**.
-     ```sh
-     docker run -d \
-         -e "ADDR=your_ip_or_domain" \
-         -e "QUOTA=maximum_storage" \
-         -p 443:443 \
-         -v $HOME/simplex/xftp/config:/etc/opt/simplex-xftp:z \
-         -v $HOME/simplex/xftp/logs:/var/opt/simplex-xftp:z \
-         -v $HOME/simplex/xftp/files:/srv/xftp:z \
-         simplexchat/xftp-server:latest
-     ```
-
-#### Using installation script
-
-**Please note** that currently, only Ubuntu distribution is supported.
-
-You can install and setup servers automatically using our script:
-
-```sh
-curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/simplex-chat/simplexmq/stable/install.sh -o simplex-server-install.sh \
-&& if echo 'b8cf2be103f21f9461d9a500bcd3db06ab7d01d68871b07f4bd245195cbead1d simplex-server-install.sh' | sha256sum -c; then chmod +x ./simplex-server-install.sh && ./simplex-server-install.sh; rm ./simplex-server-install.sh; else echo "SHA-256 checksum is incorrect!" && rm ./simplex-server-install.sh; fi
-```
-
-### Build from source
-
-#### Using Docker
-
-> **Please note:** to build the app use source code from [stable branch](https://github.com/simplex-chat/simplexmq/tree/stable).
-
-On Linux, you can build smp server using Docker.
-
-1. Build your images:
-
-   ```sh
-   git clone https://github.com/simplex-chat/simplexmq
-   cd simplexmq
-   git checkout stable
-   DOCKER_BUILDKIT=1 docker build -t local/smp-server --build-arg APP="smp-server" --build-arg APP_PORT="5223" . # For xmp-server
-   DOCKER_BUILDKIT=1 docker build -t local/xftp-server --build-arg APP="xftp-server" --build-arg APP_PORT="443" . # For xftp-server
-   ```
-
-2. Create directories for persistent Docker configuration:
-
-   ```sh
-   mkdir -p $HOME/simplex/{xftp,smp}/{config,logs} && mkdir -p $HOME/simplex/xftp/files
-   ```
-
-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 \
-         -e "ADDR=your_ip_or_domain" \
-         -e "PASS=password" \
-         -p 5223:5223 \
-         -v $HOME/simplex/smp/config:/etc/opt/simplex:z \
-         -v $HOME/simplex/smp/logs:/var/opt/simplex:z \
-         simplexchat/smp-server:latest
-     ```
-
-   - `xftp-server`
-   
-     You must change **your_ip_or_domain** and **maximum_storage**.
-     ```sh
-     docker run -d \
-         -e "ADDR=your_ip_or_domain" \
-         -e "QUOTA=maximum_storage" \
-         -p 443:443 \
-         -v $HOME/simplex/xftp/config:/etc/opt/simplex-xftp:z \
-         -v $HOME/simplex/xftp/logs:/var/opt/simplex-xftp:z \
-         -v $HOME/simplex/xftp/files:/srv/xftp:z \
-         simplexchat/xftp-server:latest
-     ```
-
-#### Using your distribution
-
-1. Install [Haskell GHCup](https://www.haskell.org/ghcup/), GHC 8.10.7 and cabal:
-
-   ```sh
-   curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh
-   ghcup install ghc 8.10.7
-   ghcup install cabal
-   ghcup set ghc 8.10.7
-   ghcup set cabal
-   ```
-
-2. Build the project:
-
-   ```sh
-   git clone https://github.com/simplex-chat/simplexmq
-   cd simplexmq
-   git checkout stable
-   # On Ubuntu. Depending on your distribution, use your package manager to determine package names.
-   apt-get update && apt-get install -y build-essential libgmp3-dev zlib1g-dev
-   cabal update
-   cabal install
-   ```
-
-- 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.
-
-- Run `smp-server start` to start SMP server, or you can configure a service manager to run it as a service.
-
-- Optionally, `smp-server` can be setup for having an onion address in `tor` network. See: [`scripts/tor`](./scripts/tor/). In this case, the server address can have both public and onion hostname pointing to the same server, to allow two people connect when only one of them is using Tor. The server address would be: `smp://<fingerprint>@<public_hostname>,<onion_hostname>`
-
-See [this section](#smp-server) for more information. Run `smp-server -h` and `smp-server init -h` for explanation of commands and options.
-
-[<img alt="Linode" src="./img/linode.svg" align="right" width="200">](https://cloud.linode.com/stackscripts/748014)
+[<img alt="Linode" src="https://raw.githubusercontent.com/simplex-chat/simplexmq/master/img/linode.svg" align="right" width="200">](https://cloud.linode.com/stackscripts/748014)
 
 ## Deploy SMP server on Linode
 
@@ -249,11 +98,11 @@ Deployment on Linode is performed via StackScripts, which serve as recipes for L
 - Create a Linode account or login with an already existing one.
 - Open [SMP server StackScript](https://cloud.linode.com/stackscripts/748014) and click "Deploy New Linode".
 - You can optionally configure the following parameters:
-  - SMP Server store log flag for queue persistence on server restart, recommended.
-  - [Linode API token](https://www.linode.com/docs/guides/getting-started-with-the-linode-api#get-an-access-token) to attach server address etc. as tags to Linode and to add A record to your 2nd level domain (e.g. `example.com` [domain should be created](https://cloud.linode.com/domains/create) in your account prior to deployment). The API token access scopes:
-    - read/write for "linodes"
-    - read/write for "domains"
-  - Domain name to use instead of Linode IP address, e.g. `smp1.example.com`.
+    - SMP Server store log flag for queue persistence on server restart, recommended.
+    - [Linode API token](https://www.linode.com/docs/guides/getting-started-with-the-linode-api#get-an-access-token) to attach server address etc. as tags to Linode and to add A record to your 2nd level domain (e.g. `example.com` [domain should be created](https://cloud.linode.com/domains/create) in your account prior to deployment). The API token access scopes:
+      - read/write for "linodes"
+      - read/write for "domains"
+    - Domain name to use instead of Linode IP address, e.g. `smp1.example.com`.
 - Choose the region and plan, Shared CPU Nanode with 1Gb is sufficient.
 - Provide ssh key to be able to connect to your Linode via ssh. If you haven't provided a Linode API token this step is required to login to your Linode and get the server's fingerprint either from the welcome message or from the file `/etc/opt/simplex/fingerprint` after server starts. See [Linode's guide on ssh](https://www.linode.com/docs/guides/use-public-key-authentication-with-ssh/) .
 - Deploy your Linode. After it starts wait for SMP server to start and for tags to appear (if a Linode API token was provided). It may take up to 5 minutes depending on the connection speed on the Linode. Connecting Linode IP address to provided domain name may take some additional time.
@@ -262,7 +111,7 @@ Deployment on Linode is performed via StackScripts, which serve as recipes for L
 
 Please submit an [issue](https://github.com/simplex-chat/simplexmq/issues) if any problems occur.
 
-[<img alt="DigitalOcean" src="/img/digitalocean.png" align="right" width="300">](https://marketplace.digitalocean.com/apps/simplex-server)
+[<img alt="DigitalOcean" src="https://raw.githubusercontent.com/simplex-chat/simplexmq/master/img/digitalocean.png" align="right" width="300">](https://marketplace.digitalocean.com/apps/simplex-server)
 
 ## Deploy SMP server on DigitalOcean
 
@@ -290,12 +139,12 @@ smp-server init [-l] -n <fqdn>
 
 ## SMP server design
 
-![SMP server design](./design/server.svg)
+![SMP server design](https://raw.githubusercontent.com/simplex-chat/simplexmq/master/design/server.svg)
 
 ## SMP agent design
 
-![SMP agent design](./design/agent2.svg)
+![SMP agent design](https://raw.githubusercontent.com/simplex-chat/simplexmq/master/design/agent2.svg)
 
 ## License
 
-[AGPL v3](./LICENSE)
+[AGPL v3](https://github.com/simplex-chat/simplexmq/blob/master/LICENSE)

apps/ntf-server/Main.hs

@@ -1,21 +0,0 @@
-module Main where
-
-import Control.Logger.Simple
-import Simplex.Messaging.Server.CLI (getEnvPath)
-import Simplex.Messaging.Notifications.Server.Main
-
-defaultCfgPath :: FilePath
-defaultCfgPath = "/etc/opt/simplex-notifications"
-
-defaultLogPath :: FilePath
-defaultLogPath = "/var/opt/simplex-notifications"
-
-logCfg :: LogConfig
-logCfg = LogConfig {lc_file = Nothing, lc_stderr = True}
-
-main :: IO ()
-main = do
-  setLogLevel LogDebug -- change to LogError in production
-  cfgPath <- getEnvPath "NTF_SERVER_CFG_PATH" defaultCfgPath
-  logPath <- getEnvPath "NTF_SERVER_LOG_PATH" defaultLogPath
-  withGlobalLogging logCfg $ ntfServerCLI cfgPath logPath

apps/smp-agent/Main.hs

@@ -1,46 +1,23 @@
 {-# LANGUAGE DuplicateRecordFields #-}
-{-# LANGUAGE NamedFieldPuns #-}
 {-# LANGUAGE OverloadedStrings #-}
 {-# LANGUAGE TypeApplications #-}
 
 module Main where
 
 import Control.Logger.Simple
-import Data.ByteArray (ScrubbedBytes)
 import qualified Data.List.NonEmpty as L
-import qualified Data.Map.Strict as M
 import Simplex.Messaging.Agent.Env.SQLite
 import Simplex.Messaging.Agent.Server (runSMPAgent)
-import Simplex.Messaging.Agent.Store.SQLite (MigrationConfirmation (..))
-import Simplex.Messaging.Client (defaultNetworkConfig)
 import Simplex.Messaging.Transport (TLS, Transport (..))
 
 cfg :: AgentConfig
-cfg = defaultAgentConfig
-
-agentDbFile :: String
-agentDbFile = "smp-agent.db"
-
-agentDbKey :: ScrubbedBytes
-agentDbKey = ""
-
-servers :: InitialAgentServers
-servers =
-  InitialAgentServers
-    { smp = M.fromList [(1, L.fromList ["smp://bU0K-bRg24xWW__lS0umO1Zdw_SXqpJNtm1_RrPLViE=@localhost:5223"])],
-      ntf = [],
-      xftp = M.empty,
-      netCfg = defaultNetworkConfig
-    }
+cfg = defaultAgentConfig {initialSMPServers = L.fromList ["smp://bU0K-bRg24xWW__lS0umO1Zdw_SXqpJNtm1_RrPLViE=@localhost:5223"]}
 
 logCfg :: LogConfig
 logCfg = LogConfig {lc_file = Nothing, lc_stderr = True}
 
--- Warning: this SMP agent server is experimental - it does not work correctly with multiple connected TCP clients in some cases.
 main :: IO ()
 main = do
-  let AgentConfig {tcpPort} = cfg
-  putStrLn $ maybe (error "no agent port") (\port -> "SMP agent listening on port " ++ port) tcpPort
+  putStrLn $ "SMP agent listening on port " ++ tcpPort (cfg :: AgentConfig)
   setLogLevel LogInfo -- LogError
-  Right st <- createAgentStore agentDbFile agentDbKey False MCConsole
-  withGlobalLogging logCfg $ runSMPAgent (transport @TLS) cfg servers st
+  withGlobalLogging logCfg $ runSMPAgent (transport @TLS) cfg

apps/smp-server/Main.hs

@@ -1,22 +1,319 @@
+{-# LANGUAGE DataKinds #-}
+{-# LANGUAGE DuplicateRecordFields #-}
+{-# LANGUAGE GADTs #-}
+{-# LANGUAGE LambdaCase #-}
+{-# LANGUAGE NamedFieldPuns #-}
+{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE TypeApplications #-}
+
 module Main where
 
-import Control.Logger.Simple
-import Simplex.Messaging.Server.CLI (getEnvPath)
-import Simplex.Messaging.Server.Main
-import qualified Static
+import Control.Monad.Except
+import Data.ByteString.Char8 (ByteString)
+import qualified Data.ByteString.Char8 as B
+import Data.Either (fromRight)
+import Data.Ini (Ini, lookupValue, readIniFile)
+import Data.Maybe (fromMaybe)
+import qualified Data.Text as T
+import Data.X509.Validation (Fingerprint (..))
+import Network.Socket (HostName, ServiceName)
+import Options.Applicative
+import Simplex.Messaging.Encoding.String
+import Simplex.Messaging.Server (runSMPServer)
+import Simplex.Messaging.Server.Env.STM
+import Simplex.Messaging.Server.StoreLog (StoreLog, openReadStoreLog, storeLogFilePath)
+import Simplex.Messaging.Transport (ATransport (..), TLS, Transport (..), simplexMQVersion)
+import Simplex.Messaging.Transport.Server (loadFingerprint)
+import Simplex.Messaging.Transport.WebSockets (WS)
+import System.Directory (createDirectoryIfMissing, doesDirectoryExist, doesFileExist, removeDirectoryRecursive)
+import System.Exit (exitFailure)
+import System.FilePath (combine)
+import System.IO (BufferMode (..), IOMode (..), hGetLine, hSetBuffering, stderr, stdout, withFile)
+import System.Process (readCreateProcess, shell)
+import Text.Read (readMaybe)
 
-defaultCfgPath :: FilePath
-defaultCfgPath = "/etc/opt/simplex"
+cfgDir :: FilePath
+cfgDir = "/etc/opt/simplex"
 
-defaultLogPath :: FilePath
-defaultLogPath = "/var/opt/simplex"
+logDir :: FilePath
+logDir = "/var/opt/simplex"
 
-logCfg :: LogConfig
-logCfg = LogConfig {lc_file = Nothing, lc_stderr = True}
+iniFile :: FilePath
+iniFile = combine cfgDir "smp-server.ini"
+
+storeLogFile :: FilePath
+storeLogFile = combine logDir "smp-server-store.log"
+
+caKeyFile :: FilePath
+caKeyFile = combine cfgDir "ca.key"
+
+caCrtFile :: FilePath
+caCrtFile = combine cfgDir "ca.crt"
+
+serverKeyFile :: FilePath
+serverKeyFile = combine cfgDir "server.key"
+
+serverCrtFile :: FilePath
+serverCrtFile = combine cfgDir "server.crt"
+
+fingerprintFile :: FilePath
+fingerprintFile = combine cfgDir "fingerprint"
 
 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 cfgPath logPath
+  getCliCommand >>= \case
+    Init opts ->
+      doesFileExist iniFile >>= \case
+        True -> exitError $ "Error: server is already initialized (" <> iniFile <> " exists).\nRun `smp-server start`."
+        _ -> initializeServer opts
+    Start ->
+      doesFileExist iniFile >>= \case
+        True -> readIniFile iniFile >>= either exitError (runServer . mkIniOptions)
+        _ -> exitError $ "Error: server is not initialized (" <> iniFile <> " does not exist).\nRun `smp-server init`."
+    Delete -> cleanup >> putStrLn "Deleted configuration and log files"
+
+exitError :: String -> IO ()
+exitError msg = putStrLn msg >> exitFailure
+
+data CliCommand
+  = Init InitOptions
+  | Start
+  | Delete
+
+data InitOptions = InitOptions
+  { enableStoreLog :: Bool,
+    signAlgorithm :: SignAlgorithm,
+    ip :: HostName,
+    fqdn :: Maybe HostName
+  }
+  deriving (Show)
+
+data SignAlgorithm = ED448 | ED25519
+  deriving (Read, Show)
+
+getCliCommand :: IO CliCommand
+getCliCommand =
+  customExecParser
+    (prefs showHelpOnEmpty)
+    ( info
+        (helper <*> versionOption <*> cliCommandP)
+        (header version <> fullDesc)
+    )
+  where
+    versionOption = infoOption version (long "version" <> short 'v' <> help "Show version")
+
+cliCommandP :: Parser CliCommand
+cliCommandP =
+  hsubparser
+    ( command "init" (info initP (progDesc $ "Initialize server - creates " <> cfgDir <> " and " <> logDir <> " directories and configuration files"))
+        <> command "start" (info (pure Start) (progDesc $ "Start server (configuration: " <> iniFile <> ")"))
+        <> command "delete" (info (pure Delete) (progDesc "Delete configuration and log files"))
+    )
+  where
+    initP :: Parser CliCommand
+    initP =
+      Init
+        <$> ( InitOptions
+                <$> switch
+                  ( long "store-log"
+                      <> short 'l'
+                      <> help "Enable store log for SMP queues persistence"
+                  )
+                <*> option
+                  (maybeReader readMaybe)
+                  ( long "sign-algorithm"
+                      <> short 'a'
+                      <> help "Signature algorithm used for TLS certificates: ED25519, ED448"
+                      <> value ED448
+                      <> showDefault
+                      <> metavar "ALG"
+                  )
+                <*> strOption
+                  ( long "ip"
+                      <> help
+                        "Server IP address used as Subject Alternative Name for TLS online certificate, \
+                        \also used as Common Name if FQDN is not supplied"
+                      <> value "127.0.0.1"
+                      <> showDefault
+                      <> metavar "IP"
+                  )
+                <*> (optional . strOption)
+                  ( long "fqdn"
+                      <> short 'n'
+                      <> help "Server FQDN used as Common Name and Subject Alternative Name for TLS online certificate"
+                      <> showDefault
+                      <> metavar "FQDN"
+                  )
+            )
+
+initializeServer :: InitOptions -> IO ()
+initializeServer InitOptions {enableStoreLog, signAlgorithm, ip, fqdn} = do
+  cleanup
+  createDirectoryIfMissing True cfgDir
+  createDirectoryIfMissing True logDir
+  createX509
+  fp <- saveFingerprint
+  createIni
+  putStrLn $ "Server initialized, you can modify configuration in " <> iniFile <> ".\nRun `smp-server start` to start server."
+  printServiceInfo fp
+  warnCAPrivateKeyFile
+  where
+    createX509 = do
+      createOpensslCaConf
+      createOpensslServerConf
+      -- CA certificate (identity/offline)
+      run $ "openssl genpkey -algorithm " <> show signAlgorithm <> " -out " <> caKeyFile
+      run $ "openssl req -new -x509 -days 999999 -config " <> opensslCaConfFile <> " -extensions v3 -key " <> caKeyFile <> " -out " <> caCrtFile
+      -- server certificate (online)
+      run $ "openssl genpkey -algorithm " <> show signAlgorithm <> " -out " <> serverKeyFile
+      run $ "openssl req -new -config " <> opensslServerConfFile <> " -reqexts v3 -key " <> serverKeyFile <> " -out " <> serverCsrFile
+      run $ "openssl x509 -req -days 999999 -extfile " <> opensslServerConfFile <> " -extensions v3 -in " <> serverCsrFile <> " -CA " <> caCrtFile <> " -CAkey " <> caKeyFile <> " -CAcreateserial -out " <> serverCrtFile
+      where
+        run cmd = void $ readCreateProcess (shell cmd) ""
+        opensslCaConfFile = combine cfgDir "openssl_ca.conf"
+        opensslServerConfFile = combine cfgDir "openssl_server.conf"
+        serverCsrFile = combine cfgDir "server.csr"
+        createOpensslCaConf =
+          writeFile
+            opensslCaConfFile
+            "[req]\n\
+            \distinguished_name = req_distinguished_name\n\
+            \prompt = no\n\n\
+            \[req_distinguished_name]\n\
+            \CN = SMP server CA\n\
+            \O = SimpleX\n\n\
+            \[v3]\n\
+            \subjectKeyIdentifier = hash\n\
+            \authorityKeyIdentifier = keyid:always\n\
+            \basicConstraints = critical,CA:true\n"
+        -- TODO revise https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3, https://www.rfc-editor.org/rfc/rfc3279#section-2.3.5
+        -- IP and FQDN can't both be used as server address interchangeably even if IP is added
+        -- as Subject Alternative Name, unless the following validation hook is disabled:
+        -- https://hackage.haskell.org/package/x509-validation-1.6.10/docs/src/Data-X509-Validation.html#validateCertificateName
+        createOpensslServerConf =
+          writeFile
+            opensslServerConfFile
+            ( "[req]\n\
+              \distinguished_name = req_distinguished_name\n\
+              \prompt = no\n\n\
+              \[req_distinguished_name]\n"
+                <> ("CN = " <> cn <> "\n\n")
+                <> "[v3]\n\
+                   \basicConstraints = CA:FALSE\n\
+                   \keyUsage = digitalSignature, nonRepudiation, keyAgreement\n\
+                   \extendedKeyUsage = serverAuth\n"
+            )
+          where
+            cn = fromMaybe ip fqdn
+
+    saveFingerprint = do
+      Fingerprint fp <- loadFingerprint caCrtFile
+      withFile fingerprintFile WriteMode (`B.hPutStrLn` strEncode fp)
+      pure fp
+
+    createIni = do
+      writeFile iniFile $
+        "[STORE_LOG]\n\
+        \# The server uses STM memory to store SMP queues and messages,\n\
+        \# that will be lost on restart (e.g., as with redis).\n\
+        \# This option enables saving SMP queues to append only log,\n\
+        \# and restoring them when the server is started.\n\
+        \# Log is compacted on start (deleted queues are removed).\n\
+        \# The messages in the queues are not logged.\n"
+          <> ("enable: " <> (if enableStoreLog then "on" else "off  # on") <> "\n\n")
+          <> "[TRANSPORT]\n\
+             \port: 5223\n\
+             \websockets: off\n"
+
+    warnCAPrivateKeyFile =
+      putStrLn $
+        "----------\n\
+        \You should store CA private key securely and delete it from the server.\n\
+        \If server TLS credential is compromised this key can be used to sign a new one, \
+        \keeping the same server identity and established connections.\n\
+        \CA private key location:\n"
+          <> caKeyFile
+          <> "\n----------"
+
+data IniOptions = IniOptions
+  { enableStoreLog :: Bool,
+    port :: ServiceName,
+    enableWebsockets :: Bool
+  }
+
+-- TODO ? properly parse ini as a whole
+mkIniOptions :: Ini -> IniOptions
+mkIniOptions ini =
+  IniOptions
+    { enableStoreLog = (== "on") $ strict "STORE_LOG" "enable",
+      port = T.unpack $ strict "TRANSPORT" "port",
+      enableWebsockets = (== "on") $ strict "TRANSPORT" "websockets"
+    }
+  where
+    strict :: String -> String -> T.Text
+    strict section key =
+      fromRight (error ("no key " <> key <> " in section " <> section)) $
+        lookupValue (T.pack section) (T.pack key) ini
+
+runServer :: IniOptions -> IO ()
+runServer IniOptions {enableStoreLog, port, enableWebsockets} = do
+  hSetBuffering stdout LineBuffering
+  hSetBuffering stderr LineBuffering
+  fp <- checkSavedFingerprint
+  printServiceInfo fp
+  storeLog <- openStoreLog
+  let cfg = mkServerConfig storeLog
+  printServerConfig cfg
+  runSMPServer cfg
+  where
+    checkSavedFingerprint = do
+      savedFingerprint <- loadSavedFingerprint
+      Fingerprint fp <- loadFingerprint caCrtFile
+      when (B.pack savedFingerprint /= strEncode fp) $
+        exitError "Stored fingerprint is invalid."
+      pure fp
+
+    mkServerConfig storeLog =
+      ServerConfig
+        { transports = (port, transport @TLS) : [("80", transport @WS) | enableWebsockets],
+          tbqSize = 16,
+          serverTbqSize = 64,
+          msgQueueQuota = 128,
+          queueIdBytes = 24,
+          msgIdBytes = 24, -- must be at least 24 bytes, it is used as 192-bit nonce for XSalsa20
+          caCertificateFile = caCrtFile,
+          privateKeyFile = serverKeyFile,
+          certificateFile = serverCrtFile,
+          storeLog
+        }
+
+    openStoreLog :: IO (Maybe (StoreLog 'ReadMode))
+    openStoreLog =
+      if enableStoreLog
+        then Just <$> openReadStoreLog storeLogFile
+        else pure Nothing
+
+    printServerConfig ServerConfig {storeLog, transports} = do
+      putStrLn $ case storeLog of
+        Just s -> "Store log: " <> storeLogFilePath s
+        Nothing -> "Store log disabled."
+      forM_ transports $ \(p, ATransport t) ->
+        putStrLn $ "Listening on port " <> p <> " (" <> transportName t <> ")..."
+
+cleanup :: IO ()
+cleanup = do
+  deleteDirIfExists cfgDir
+  deleteDirIfExists logDir
+  where
+    deleteDirIfExists path = doesDirectoryExist path >>= (`when` removeDirectoryRecursive path)
+
+printServiceInfo :: ByteString -> IO ()
+printServiceInfo fpStr = do
+  putStrLn version
+  B.putStrLn $ "Fingerprint: " <> strEncode fpStr
+
+version :: String
+version = "SMP server v" <> simplexMQVersion
+
+loadSavedFingerprint :: IO String
+loadSavedFingerprint = withFile fingerprintFile ReadMode hGetLine

apps/smp-server/static/contact/index.html

@@ -1 +0,0 @@
-../link.html

apps/smp-server/static/invitation/index.html

@@ -1 +0,0 @@
-../link.html

apps/smp-server/static/media/apple_store.svg

@@ -1,26 +0,0 @@
-<svg width="119" height="40" viewBox="0 0 119 40" fill="none" xmlns="http://www.w3.org/2000/svg">
-<path d="M8.44484 39.125C8.14016 39.125 7.84284 39.1211 7.54055 39.1143C6.91433 39.1061 6.28957 39.0516 5.67141 38.9512C5.095 38.8519 4.53661 38.6673 4.01467 38.4033C3.49751 38.1415 3.02582 37.7983 2.61767 37.3867C2.20361 36.98 1.85888 36.5082 1.59716 35.9902C1.33255 35.4688 1.14942 34.9099 1.05416 34.333C0.951281 33.7131 0.895621 33.0863 0.887656 32.458C0.881316 32.2471 0.873016 31.5449 0.873016 31.5449V8.44434C0.873016 8.44434 0.881856 7.75293 0.887706 7.5498C0.895332 6.92248 0.950669 6.29665 1.05324 5.67773C1.14868 5.09925 1.33194 4.53875 1.5967 4.01563C1.85746 3.49794 2.20027 3.02586 2.61184 2.61768C3.02294 2.20562 3.49614 1.8606 4.01418 1.59521C4.53492 1.33209 5.09225 1.14873 5.6675 1.05127C6.28769 0.949836 6.91462 0.894996 7.54301 0.88721L8.44533 0.875H111.214L112.127 0.8877C112.75 0.895099 113.371 0.94945 113.985 1.05029C114.566 1.14898 115.13 1.33362 115.656 1.59814C116.694 2.13299 117.539 2.97916 118.071 4.01807C118.332 4.53758 118.512 5.09351 118.606 5.66699C118.71 6.29099 118.768 6.92174 118.78 7.5542C118.783 7.8374 118.783 8.1416 118.783 8.44434C118.791 8.81934 118.791 9.17627 118.791 9.53613V30.4648C118.791 30.8281 118.791 31.1826 118.783 31.54C118.783 31.8652 118.783 32.1631 118.779 32.4697C118.768 33.0909 118.71 33.7104 118.608 34.3232C118.515 34.9043 118.333 35.4675 118.068 35.9932C117.805 36.5056 117.462 36.9733 117.053 37.3789C116.644 37.7927 116.172 38.1379 115.653 38.4014C115.128 38.6674 114.566 38.8527 113.985 38.9512C113.367 39.0522 112.742 39.1067 112.116 39.1143C111.823 39.1211 111.517 39.125 111.219 39.125L110.135 39.127L8.44484 39.125Z" fill="black"/>
-<path d="M24.7689 20.3007C24.7796 19.466 25.0013 18.6477 25.4134 17.9217C25.8254 17.1957 26.4144 16.5858 27.1254 16.1486C26.6737 15.5035 26.0778 14.9725 25.3849 14.598C24.6921 14.2234 23.9215 14.0156 23.1343 13.991C21.455 13.8147 19.8271 14.9958 18.9714 14.9958C18.0991 14.9958 16.7816 14.0085 15.3629 14.0376C14.4452 14.0673 13.5509 14.3341 12.767 14.8122C11.9831 15.2903 11.3364 15.9632 10.89 16.7655C8.95597 20.1139 10.3986 25.035 12.2512 27.7416C13.1781 29.0669 14.2613 30.5474 15.6788 30.4949C17.0659 30.4374 17.5839 29.6104 19.2582 29.6104C20.917 29.6104 21.403 30.4949 22.8492 30.4615C24.3376 30.4374 25.2753 29.1303 26.1697 27.7924C26.8357 26.848 27.3481 25.8043 27.6881 24.6999C26.8234 24.3341 26.0855 23.722 25.5664 22.9397C25.0473 22.1574 24.7699 21.2396 24.7689 20.3007V20.3007Z" fill="white"/>
-<path d="M22.0373 12.2109C22.8488 11.2367 23.2486 9.98451 23.1518 8.72028C21.9119 8.8505 20.7667 9.44306 19.9442 10.3799C19.5421 10.8376 19.2341 11.37 19.0378 11.9468C18.8416 12.5235 18.7609 13.1333 18.8005 13.7413C19.4206 13.7477 20.0341 13.6132 20.5948 13.3482C21.1555 13.0831 21.6487 12.6942 22.0373 12.2109Z" fill="white"/>
-<path d="M42.3023 27.1396H37.5689L36.4322 30.4961H34.4273L38.9107 18.0781H40.9937L45.4771 30.4961H43.438L42.3023 27.1396ZM38.0591 25.5908H41.8111L39.9615 20.1435H39.9097L38.0591 25.5908Z" fill="white"/>
-<path d="M55.1597 25.9697C55.1597 28.7832 53.6538 30.5908 51.3814 30.5908C50.8057 30.6209 50.2332 30.4883 49.7294 30.2082C49.2256 29.928 48.8109 29.5117 48.5327 29.0068H48.4897V33.4912H46.6313V21.4424H48.4302V22.9482H48.4644C48.7553 22.4458 49.1771 22.0316 49.6847 21.7497C50.1923 21.4679 50.7669 21.3289 51.3472 21.3476C53.645 21.3477 55.1597 23.1641 55.1597 25.9697ZM53.2495 25.9697C53.2495 24.1367 52.3023 22.9316 50.857 22.9316C49.437 22.9316 48.482 24.1621 48.482 25.9697C48.482 27.7939 49.437 29.0156 50.857 29.0156C52.3023 29.0156 53.2495 27.8193 53.2495 25.9697Z" fill="white"/>
-<path d="M65.1245 25.9697C65.1245 28.7832 63.6187 30.5908 61.3462 30.5908C60.7706 30.6209 60.1981 30.4883 59.6943 30.2082C59.1905 29.928 58.7758 29.5117 58.4976 29.0068H58.4546V33.4912H56.5962V21.4424H58.395V22.9482H58.4292C58.7201 22.4458 59.1419 22.0316 59.6495 21.7497C60.1571 21.4679 60.7317 21.3289 61.312 21.3476C63.6099 21.3476 65.1245 23.164 65.1245 25.9697ZM63.2144 25.9697C63.2144 24.1367 62.2671 22.9316 60.8218 22.9316C59.4019 22.9316 58.4468 24.1621 58.4468 25.9697C58.4468 27.7939 59.4019 29.0156 60.8218 29.0156C62.2671 29.0156 63.2144 27.8193 63.2144 25.9697H63.2144Z" fill="white"/>
-<path d="M71.7105 27.0361C71.8482 28.2676 73.0445 29.0761 74.6792 29.0761C76.2456 29.0761 77.3726 28.2675 77.3726 27.1572C77.3726 26.1933 76.6929 25.6162 75.0835 25.2207L73.4742 24.833C71.1939 24.2822 70.1353 23.2158 70.1353 21.4853C70.1353 19.3427 72.0025 17.871 74.6538 17.871C77.2778 17.871 79.0767 19.3427 79.1372 21.4853H77.2612C77.1489 20.246 76.1245 19.498 74.6274 19.498C73.1304 19.498 72.106 20.2548 72.106 21.3564C72.106 22.2343 72.7603 22.7509 74.3608 23.1464L75.729 23.4823C78.2769 24.0849 79.3355 25.1083 79.3355 26.9247C79.3355 29.248 77.4849 30.703 74.5415 30.703C71.7876 30.703 69.9282 29.2821 69.8081 27.036L71.7105 27.0361Z" fill="white"/>
-<path d="M83.3462 19.2998V21.4424H85.0679V22.9141H83.3462V27.9053C83.3462 28.6807 83.6909 29.042 84.4478 29.042C84.6522 29.0384 84.8562 29.0241 85.0591 28.999V30.4619C84.7188 30.5255 84.373 30.5543 84.0269 30.5478C82.1939 30.5478 81.479 29.8593 81.479 28.1035V22.9141H80.1626V21.4424H81.479V19.2998H83.3462Z" fill="white"/>
-<path d="M86.065 25.9697C86.065 23.1211 87.7427 21.3311 90.3589 21.3311C92.9839 21.3311 94.6539 23.1211 94.6539 25.9697C94.6539 28.8262 92.9927 30.6084 90.3589 30.6084C87.7261 30.6084 86.065 28.8262 86.065 25.9697ZM92.7603 25.9697C92.7603 24.0156 91.8648 22.8623 90.3589 22.8623C88.8531 22.8623 87.9585 24.0244 87.9585 25.9697C87.9585 27.9316 88.8531 29.0762 90.3589 29.0762C91.8648 29.0762 92.7603 27.9316 92.7603 25.9697H92.7603Z" fill="white"/>
-<path d="M96.1861 21.4424H97.9585V22.9834H98.0015C98.1215 22.5021 98.4034 22.0768 98.8 21.7789C99.1966 21.481 99.6836 21.3287 100.179 21.3476C100.393 21.3469 100.607 21.3702 100.816 21.417V23.1553C100.546 23.0726 100.264 23.0347 99.981 23.043C99.711 23.032 99.4419 23.0796 99.192 23.1825C98.9422 23.2854 98.7176 23.4411 98.5336 23.639C98.3496 23.8369 98.2106 24.0723 98.1262 24.3289C98.0418 24.5856 98.0139 24.8575 98.0445 25.126V30.4961H96.1861L96.1861 21.4424Z" fill="white"/>
-<path d="M109.384 27.8369C109.134 29.4805 107.534 30.6084 105.486 30.6084C102.852 30.6084 101.217 28.8437 101.217 26.0127C101.217 23.1729 102.861 21.3311 105.408 21.3311C107.913 21.3311 109.488 23.0518 109.488 25.7969V26.4336H103.093V26.5459C103.064 26.8791 103.105 27.2148 103.216 27.5306C103.326 27.8464 103.502 28.1352 103.732 28.3778C103.963 28.6203 104.242 28.8111 104.552 28.9374C104.861 29.0637 105.195 29.1226 105.529 29.1103C105.968 29.1515 106.409 29.0498 106.785 28.8203C107.162 28.5909 107.455 28.246 107.62 27.8369L109.384 27.8369ZM103.102 25.1348H107.628C107.645 24.8352 107.6 24.5354 107.495 24.2541C107.39 23.9729 107.229 23.7164 107.02 23.5006C106.812 23.2849 106.561 23.1145 106.283 23.0003C106.006 22.8861 105.708 22.8305 105.408 22.8369C105.105 22.8351 104.805 22.8933 104.525 23.008C104.245 23.1227 103.99 23.2918 103.776 23.5054C103.562 23.7191 103.392 23.973 103.276 24.2527C103.16 24.5323 103.101 24.8321 103.102 25.1348V25.1348Z" fill="white"/>
-<path d="M37.8262 8.73101C38.2158 8.70305 38.6068 8.76191 38.9709 8.90335C39.335 9.04478 39.6632 9.26526 39.9318 9.54889C40.2004 9.83251 40.4026 10.1722 40.524 10.5435C40.6455 10.9148 40.6829 11.3083 40.6338 11.6959C40.6338 13.6021 39.6035 14.6979 37.8262 14.6979H35.6709V8.73101H37.8262ZM36.5977 13.854H37.7227C38.0011 13.8707 38.2797 13.825 38.5382 13.7204C38.7968 13.6158 39.0287 13.4548 39.2172 13.2493C39.4057 13.0437 39.546 12.7987 39.6279 12.5321C39.7097 12.2655 39.7311 11.9839 39.6904 11.708C39.7282 11.4332 39.7046 11.1534 39.6215 10.8887C39.5384 10.6241 39.3977 10.3811 39.2097 10.1771C39.0216 9.97322 38.7908 9.81341 38.5337 9.70917C38.2766 9.60494 37.9997 9.55885 37.7227 9.57422H36.5977V13.854Z" fill="white"/>
-<path d="M41.6807 12.4443C41.6524 12.1484 41.6862 11.8499 41.7801 11.5678C41.8739 11.2857 42.0257 11.0264 42.2256 10.8064C42.4255 10.5864 42.6693 10.4107 42.9411 10.2904C43.213 10.1701 43.507 10.108 43.8042 10.108C44.1015 10.108 44.3955 10.1701 44.6673 10.2904C44.9392 10.4107 45.1829 10.5864 45.3828 10.8064C45.5828 11.0264 45.7345 11.2857 45.8284 11.5678C45.9222 11.8499 45.9561 12.1484 45.9278 12.4443C45.9566 12.7406 45.9232 13.0396 45.8296 13.3221C45.736 13.6046 45.5843 13.8644 45.3843 14.0848C45.1843 14.3052 44.9404 14.4814 44.6683 14.6019C44.3962 14.7225 44.1018 14.7847 43.8042 14.7847C43.5066 14.7847 43.2123 14.7225 42.9401 14.6019C42.668 14.4814 42.4241 14.3052 42.2241 14.0848C42.0241 13.8644 41.8725 13.6046 41.7789 13.3221C41.6853 13.0396 41.6518 12.7406 41.6807 12.4443V12.4443ZM45.0137 12.4443C45.0137 11.4683 44.5752 10.8975 43.8057 10.8975C43.0332 10.8975 42.5987 11.4683 42.5987 12.4444C42.5987 13.4282 43.0333 13.9946 43.8057 13.9946C44.5752 13.9946 45.0137 13.4243 45.0137 12.4443H45.0137Z" fill="white"/>
-<path d="M51.5733 14.6978H50.6514L49.7207 11.3813H49.6504L48.7237 14.6978H47.8106L46.5694 10.1948H47.4707L48.2774 13.6308H48.3438L49.2696 10.1948H50.1221L51.0479 13.6308H51.1182L51.9209 10.1948H52.8096L51.5733 14.6978Z" fill="white"/>
-<path d="M53.8536 10.1948H54.709V10.9102H54.7754C54.8881 10.6532 55.0781 10.4379 55.319 10.2941C55.5598 10.1503 55.8396 10.0852 56.1192 10.1079C56.3383 10.0914 56.5583 10.1245 56.7629 10.2046C56.9675 10.2847 57.1514 10.4098 57.3011 10.5706C57.4508 10.7315 57.5624 10.9239 57.6276 11.1337C57.6928 11.3436 57.7099 11.5654 57.6778 11.7827V14.6977H56.7891V12.0059C56.7891 11.2822 56.4746 10.9224 55.8174 10.9224C55.6687 10.9154 55.5202 10.9408 55.3821 10.9966C55.244 11.0524 55.1197 11.1375 55.0176 11.2458C54.9154 11.3542 54.838 11.4834 54.7904 11.6245C54.7429 11.7657 54.7265 11.9154 54.7422 12.0635V14.6978H53.8535L53.8536 10.1948Z" fill="white"/>
-<path d="M59.0938 8.43701H59.9825V14.6978H59.0938V8.43701Z" fill="white"/>
-<path d="M61.2178 12.4443C61.1895 12.1484 61.2234 11.8498 61.3172 11.5677C61.4111 11.2857 61.5629 11.0263 61.7629 10.8063C61.9628 10.5863 62.2065 10.4106 62.4784 10.2903C62.7503 10.17 63.0443 10.1079 63.3416 10.1079C63.6389 10.1079 63.9329 10.17 64.2047 10.2903C64.4766 10.4106 64.7203 10.5863 64.9203 10.8063C65.1203 11.0263 65.272 11.2857 65.3659 11.5677C65.4598 11.8498 65.4936 12.1484 65.4654 12.4443C65.4942 12.7406 65.4607 13.0396 65.3671 13.3221C65.2734 13.6046 65.1218 13.8644 64.9217 14.0848C64.7217 14.3052 64.4778 14.4814 64.2057 14.6019C63.9335 14.7224 63.6392 14.7847 63.3416 14.7847C63.044 14.7847 62.7496 14.7224 62.4775 14.6019C62.2053 14.4814 61.9614 14.3052 61.7614 14.0848C61.5614 13.8644 61.4097 13.6046 61.3161 13.3221C61.2225 13.0396 61.189 12.7406 61.2178 12.4443V12.4443ZM64.5508 12.4443C64.5508 11.4683 64.1123 10.8975 63.3428 10.8975C62.5703 10.8975 62.1358 11.4683 62.1358 12.4444C62.1358 13.4282 62.5704 13.9946 63.3428 13.9946C64.1123 13.9946 64.5508 13.4243 64.5508 12.4443H64.5508Z" fill="white"/>
-<path d="M66.4009 13.4243C66.4009 12.6138 67.0044 12.1465 68.0757 12.0801L69.2954 12.0098V11.6211C69.2954 11.1455 68.981 10.877 68.3736 10.877C67.8775 10.877 67.5337 11.0591 67.4351 11.3775H66.5747C66.6656 10.604 67.3931 10.1079 68.4146 10.1079C69.5435 10.1079 70.1802 10.6699 70.1802 11.6211V14.6978H69.3247V14.065H69.2544C69.1117 14.292 68.9113 14.477 68.6737 14.6012C68.4361 14.7254 68.1697 14.7844 67.9019 14.772C67.7129 14.7916 67.5218 14.7715 67.341 14.7128C67.1603 14.6541 66.9938 14.5581 66.8524 14.4312C66.711 14.3042 66.5977 14.149 66.52 13.9756C66.4422 13.8022 66.4017 13.6144 66.4009 13.4243V13.4243ZM69.2954 13.0396V12.6631L68.1958 12.7334C67.5757 12.7749 67.2945 12.9859 67.2945 13.3828C67.2945 13.7881 67.646 14.0239 68.1295 14.0239C68.2711 14.0383 68.4142 14.024 68.5502 13.9819C68.6862 13.9398 68.8123 13.8708 68.9211 13.7789C69.0299 13.6871 69.1191 13.5743 69.1834 13.4473C69.2477 13.3203 69.2858 13.1816 69.2954 13.0396V13.0396Z" fill="white"/>
-<path d="M71.3482 12.4444C71.3482 11.0215 72.0796 10.1201 73.2173 10.1201C73.4987 10.1072 73.778 10.1746 74.0226 10.3145C74.2671 10.4544 74.4667 10.661 74.5982 10.9101H74.6646V8.43701H75.5533V14.6978H74.7017V13.9863H74.6314C74.4898 14.2338 74.2832 14.4378 74.0339 14.5763C73.7847 14.7148 73.5023 14.7825 73.2173 14.772C72.0718 14.772 71.3482 13.8706 71.3482 12.4444ZM72.2662 12.4444C72.2662 13.3994 72.7164 13.9741 73.4693 13.9741C74.2183 13.9741 74.6812 13.3911 74.6812 12.4483C74.6812 11.5098 74.2134 10.9185 73.4693 10.9185C72.7212 10.9185 72.2661 11.4971 72.2661 12.4444H72.2662Z" fill="white"/>
-<path d="M79.23 12.4443C79.2017 12.1484 79.2356 11.8499 79.3294 11.5678C79.4232 11.2857 79.575 11.0264 79.7749 10.8064C79.9749 10.5864 80.2186 10.4107 80.4904 10.2904C80.7623 10.1701 81.0563 10.108 81.3536 10.108C81.6508 10.108 81.9448 10.1701 82.2167 10.2904C82.4885 10.4107 82.7322 10.5864 82.9322 10.8064C83.1321 11.0264 83.2839 11.2857 83.3777 11.5678C83.4715 11.8499 83.5054 12.1484 83.4771 12.4443C83.5059 12.7406 83.4725 13.0396 83.3789 13.3221C83.2853 13.6046 83.1336 13.8644 82.9336 14.0848C82.7336 14.3052 82.4897 14.4814 82.2176 14.6019C81.9455 14.7225 81.6512 14.7847 81.3536 14.7847C81.0559 14.7847 80.7616 14.7225 80.4895 14.6019C80.2173 14.4814 79.9735 14.3052 79.7735 14.0848C79.5735 13.8644 79.4218 13.6046 79.3282 13.3221C79.2346 13.0396 79.2012 12.7406 79.23 12.4443V12.4443ZM82.563 12.4443C82.563 11.4683 82.1245 10.8975 81.355 10.8975C80.5826 10.8975 80.148 11.4683 80.148 12.4444C80.148 13.4282 80.5826 13.9946 81.355 13.9946C82.1245 13.9946 82.563 13.4243 82.563 12.4443Z" fill="white"/>
-<path d="M84.6695 10.1948H85.5249V10.9102H85.5913C85.704 10.6532 85.894 10.4379 86.1349 10.2941C86.3757 10.1503 86.6555 10.0852 86.9351 10.1079C87.1542 10.0914 87.3742 10.1245 87.5788 10.2046C87.7834 10.2847 87.9673 10.4098 88.117 10.5706C88.2667 10.7315 88.3783 10.9239 88.4435 11.1337C88.5087 11.3436 88.5258 11.5654 88.4937 11.7827V14.6977H87.605V12.0059C87.605 11.2822 87.2906 10.9224 86.6333 10.9224C86.4846 10.9154 86.3361 10.9408 86.198 10.9966C86.06 11.0524 85.9356 11.1375 85.8335 11.2458C85.7314 11.3542 85.6539 11.4834 85.6064 11.6245C85.5588 11.7657 85.5424 11.9154 85.5581 12.0635V14.6978H84.6695V10.1948Z" fill="white"/>
-<path d="M93.5152 9.07373V10.2153H94.4908V10.9639H93.5152V13.2793C93.5152 13.751 93.7095 13.9575 94.1519 13.9575C94.2651 13.9572 94.3783 13.9503 94.4908 13.937V14.6772C94.3312 14.7058 94.1695 14.721 94.0074 14.7226C93.0191 14.7226 92.6255 14.375 92.6255 13.5068V10.9638H91.9107V10.2153H92.6255V9.07373H93.5152Z" fill="white"/>
-<path d="M95.7046 8.43701H96.5855V10.9185H96.6558C96.7739 10.6591 96.9691 10.4425 97.2148 10.2982C97.4605 10.1539 97.7448 10.0888 98.0288 10.1118C98.2467 10.1 98.4646 10.1364 98.6669 10.2184C98.8692 10.3004 99.0509 10.4261 99.199 10.5864C99.3471 10.7468 99.458 10.9378 99.5238 11.146C99.5896 11.3541 99.6086 11.5742 99.5796 11.7905V14.6978H98.69V12.0098C98.69 11.2905 98.355 10.9263 97.7271 10.9263C97.5744 10.9137 97.4207 10.9347 97.277 10.9878C97.1332 11.0408 97.0027 11.1247 96.8948 11.2334C96.7868 11.3421 96.7038 11.4732 96.6518 11.6173C96.5997 11.7614 96.5798 11.9152 96.5933 12.0679V14.6977H95.7047L95.7046 8.43701Z" fill="white"/>
-<path d="M104.761 13.4819C104.641 13.8935 104.379 14.2495 104.022 14.4876C103.666 14.7258 103.236 14.8309 102.81 14.7847C102.513 14.7925 102.219 14.7357 101.946 14.6182C101.674 14.5006 101.43 14.3252 101.232 14.1041C101.034 13.8829 100.887 13.6214 100.8 13.3376C100.713 13.0537 100.689 12.7544 100.73 12.4605C100.691 12.1656 100.715 11.8656 100.801 11.581C100.888 11.2963 101.034 11.0335 101.231 10.8105C101.428 10.5874 101.671 10.4092 101.942 10.288C102.214 10.1668 102.509 10.1054 102.806 10.1079C104.059 10.1079 104.815 10.9639 104.815 12.3779V12.688H101.635V12.7378C101.621 12.9031 101.642 13.0694 101.696 13.2261C101.75 13.3829 101.837 13.5266 101.95 13.6481C102.062 13.7695 102.2 13.866 102.352 13.9314C102.504 13.9968 102.669 14.0297 102.835 14.0278C103.047 14.0533 103.262 14.0151 103.453 13.9178C103.644 13.8206 103.802 13.6689 103.906 13.4819L104.761 13.4819ZM101.635 12.0308H103.91C103.921 11.8796 103.9 11.7278 103.849 11.5851C103.798 11.4424 103.718 11.3119 103.614 11.2021C103.509 11.0922 103.383 11.0054 103.243 10.9472C103.103 10.8891 102.953 10.8608 102.801 10.8643C102.648 10.8623 102.495 10.8912 102.353 10.9491C102.21 11.0071 102.081 11.0929 101.972 11.2017C101.864 11.3104 101.778 11.4397 101.72 11.5821C101.662 11.7245 101.633 11.8771 101.635 12.0308H101.635Z" fill="white"/>
-</svg>

apps/smp-server/static/media/contact.js

@@ -1,66 +0,0 @@
-(function () {
-
-  let complete = false
-  run()
-  window.onload = run
-
-  async function run() {
-    const connURIel = document.getElementById("conn_req_uri_text");
-    const mobileConnURIanchor = document.getElementById("mobile_conn_req_uri");
-    const connQRCodes = document.getElementsByClassName("conn_req_uri_qrcode");
-    console.log(connQRCodes);
-    if (complete || !connURIel || !mobileConnURIanchor || connQRCodes < 2) return
-    complete = true
-    let connURI = document.location.toString()
-    const parsedURI = new URL(connURI)
-    const path = parsedURI.pathname.split("/")
-    const len = path.length
-    const action = path[len - (path[len - 1] == "" ? 2 : 1)]
-    parsedURI.protocol = "https"
-    parsedURI.pathname = "/" + action
-    connURI = parsedURI.toString()
-    console.log("connection URI: ", connURI)
-    mobileConnURIanchor.href = "simplex:" + parsedURI.pathname + parsedURI.hash
-    connURIel.innerText = "/c " + connURI
-    for (const connQRCode of connQRCodes) {
-      try {
-        await QRCode.toCanvas(connQRCode, connURI, {
-          errorCorrectionLevel: "M",
-          color: {dark: "#062D56"}
-        });
-        connQRCode.style.width = "320px";
-        connQRCode.style.height = "320px";
-      } catch (err) {
-        console.error(err);
-      }
-    }
-
-    function contentCopyWithTooltip(parent) {
-      const content = parent.querySelector(".content");
-      const tooltip = parent.querySelector(".tooltiptext");
-      console.log(parent.querySelector(".content_copy"), 111)
-      console.log(parent)
-      const copyButton = parent.querySelector(".content_copy");
-      copyButton.addEventListener("click", copyAddress)
-      copyButton.addEventListener("mouseout", resetTooltip)
-
-      function copyAddress() {
-        navigator.clipboard.writeText(content.innerText || content.value);
-        tooltip.innerHTML = "Copied!";
-      }
-
-      function resetTooltip() {
-        tooltip.innerHTML = "Copy to clipboard";
-      }
-    }
-
-    function copyAddress() {
-      navigator.clipboard.writeText(connURI);
-      tooltipEl.innerHTML = "Copied!";
-    }
-
-    function resetTooltip() {
-      tooltipEl.innerHTML = "Copy to clipboard";
-    }
-  }
-})();

apps/smp-server/static/media/f_droid.svg

@@ -1,372 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg
-   width="560"
-   height="164"
-   version="1.1"
-   id="svg1048"
-   sodipodi:docname="f_droid.svg"
-   inkscape:version="1.1.2 (0a00cf5339, 2022-02-04, custom)"
-   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
-   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
-   xmlns:xlink="http://www.w3.org/1999/xlink"
-   xmlns="http://www.w3.org/2000/svg"
-   xmlns:svg="http://www.w3.org/2000/svg">
-  <sodipodi:namedview
-     id="namedview1050"
-     pagecolor="#505050"
-     bordercolor="#ffffff"
-     borderopacity="1"
-     inkscape:pageshadow="0"
-     inkscape:pageopacity="0"
-     inkscape:pagecheckerboard="1"
-     showgrid="false"
-     inkscape:snap-bbox="true"
-     inkscape:bbox-paths="true"
-     inkscape:bbox-nodes="true"
-     inkscape:snap-bbox-edge-midpoints="true"
-     inkscape:snap-bbox-midpoints="true"
-     inkscape:snap-intersection-paths="true"
-     inkscape:object-paths="true"
-     inkscape:snap-smooth-nodes="true"
-     inkscape:snap-midpoints="true"
-     inkscape:snap-object-midpoints="true"
-     inkscape:snap-center="true"
-     inkscape:snap-text-baseline="true"
-     inkscape:snap-page="true"
-     fit-margin-top="0"
-     fit-margin-left="0"
-     fit-margin-right="0"
-     fit-margin-bottom="0"
-     inkscape:zoom="1.1996734"
-     inkscape:cx="186.71748"
-     inkscape:cy="100.02722"
-     inkscape:window-width="1920"
-     inkscape:window-height="1007"
-     inkscape:window-x="0"
-     inkscape:window-y="0"
-     inkscape:window-maximized="1"
-     inkscape:current-layer="svg1048" />
-  <defs
-     id="defs974">
-    <linearGradient
-       id="a">
-      <stop
-         offset="0"
-         stop-color="#fff"
-         stop-opacity=".098"
-         id="stop968" />
-      <stop
-         offset="1"
-         stop-color="#fff"
-         stop-opacity="0"
-         id="stop970" />
-    </linearGradient>
-    <radialGradient
-       xlink:href="#a"
-       id="b"
-       cx="113"
-       cy="-12.89"
-       fx="113"
-       fy="-12.89"
-       r="59.661999"
-       gradientTransform="matrix(0,1.96105,-1.97781,0,254.507,78.763)"
-       gradientUnits="userSpaceOnUse" />
-  </defs>
-  <g
-     transform="translate(-332,-355.362)"
-     id="g1046">
-    <rect
-       style="stroke:none;marker:none"
-       width="560"
-       height="164"
-       x="332"
-       y="355.362"
-       rx="20"
-       ry="20"
-       color="#000000"
-       overflow="visible"
-       stroke="#a6a6a6"
-       stroke-width="4"
-       id="rect976" />
-    <text
-       y="402.367"
-       x="508.95099"
-       style="line-height:100%;-inkscape-font-specification:'DejaVu Sans';marker:none"
-       color="#000000"
-       font-weight="400"
-       font-size="12.395px"
-       font-family="'DejaVu Sans'"
-       letter-spacing="0"
-       word-spacing="0"
-       overflow="visible"
-       fill="#ffffff"
-       id="text980"><tspan
-         y="402.367"
-         x="508.95099"
-         style="-inkscape-font-specification:'DejaVu Sans'"
-         font-size="34.125px"
-         id="tspan978">GET IT ON</tspan></text>
-    <text
-       style="line-height:100%;-inkscape-font-specification:'Rokkitt Bold';text-align:start;marker:none"
-       x="508.21301"
-       y="489.36099"
-       color="#000000"
-       font-weight="700"
-       font-size="29.709px"
-       font-family="Rokkitt"
-       letter-spacing="0"
-       word-spacing="0"
-       overflow="visible"
-       fill="#ffffff"
-       id="text984"><tspan
-         x="508.21301"
-         y="489.36099"
-         style="line-height:100%;-inkscape-font-specification:'Roboto Slab Bold';text-align:start"
-         font-size="95px"
-         font-family="'Roboto Slab'"
-         id="tspan982">F-Droid</tspan></text>
-    <g
-       fill-rule="evenodd"
-       id="g994">
-      <path
-         d="m 2.589,1006.862 4.25,5.5"
-         fill="#8ab000"
-         stroke="#769616"
-         stroke-width="2.5"
-         stroke-linecap="round"
-         transform="matrix(-2.63159,0,0,2.63157,483.158,-2270.475)"
-         id="path986" />
-      <path
-         style="line-height:normal;text-indent:0;text-align:start;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;text-transform:none;isolation:auto;mix-blend-mode:normal"
-         d="m 476.286,375.862 c 1.193,0.031 2.004,0.497 2.58,1.18 -5.333,6.34 -6.232,7.347 -13.514,16.372 -2.683,3.472 -5.478,1.678 -2.795,-1.793 l 11.185,-14.474 c 0.602,-0.804 1.54,-1.258 2.544,-1.285 z"
-         color="#000000"
-         font-weight="400"
-         font-family="sans-serif"
-         white-space="normal"
-         overflow="visible"
-         fill="#ffffff"
-         fill-opacity="0.298"
-         id="path988" />
-      <path
-         style="line-height:normal;text-indent:0;text-align:start;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;text-transform:none;isolation:auto;mix-blend-mode:normal"
-         d="m 478.89,377.075 c 0.325,0.39 1.476,2.118 0.058,4.096 l -11.184,14.473 c -2.683,3.471 -3.026,-1.611 -3.026,-1.611 0,0 9.828,-11.869 14.151,-16.958 z"
-         color="#000000"
-         font-weight="400"
-         font-family="sans-serif"
-         white-space="normal"
-         overflow="visible"
-         fill="#263238"
-         fill-opacity="0.2"
-         id="path990" />
-      <path
-         style="line-height:normal;text-indent:0;text-align:start;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;text-transform:none;isolation:auto;mix-blend-mode:normal"
-         d="m 477.006,376.48 c 1.153,0 2.525,0.373 2.169,2.102 -0.273,1.32 -12.266,15.985 -12.266,15.985 -2.683,3.47 -6.562,1.78 -3.879,-1.691 l 11.143,-14.402 c 0.685,-0.763 1.602,-1.957 2.833,-1.994 z"
-         color="#000000"
-         font-weight="400"
-         font-family="sans-serif"
-         white-space="normal"
-         overflow="visible"
-         fill="#8ab000"
-         id="path992" />
-    </g>
-    <g
-       fill-rule="evenodd"
-       id="g1004">
-      <path
-         d="m 2.589,1006.862 4.25,5.5"
-         fill="#8ab000"
-         stroke="#769616"
-         stroke-width="2.5"
-         stroke-linecap="round"
-         transform="matrix(2.63159,0,0,2.63157,356.842,-2270.475)"
-         id="path996" />
-      <path
-         d="m 363.714,375.862 c -1.193,0.031 -2.004,0.497 -2.58,1.18 5.333,6.34 6.232,7.347 13.514,16.372 2.683,3.472 5.478,1.678 2.795,-1.793 l -11.185,-14.474 c -0.602,-0.804 -1.54,-1.258 -2.544,-1.285 z"
-         style="line-height:normal;text-indent:0;text-align:start;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;text-transform:none;isolation:auto;mix-blend-mode:normal"
-         color="#000000"
-         font-weight="400"
-         font-family="sans-serif"
-         white-space="normal"
-         overflow="visible"
-         fill="#ffffff"
-         fill-opacity="0.298"
-         id="path998" />
-      <path
-         d="m 361.11,377.075 c -0.325,0.39 -1.476,2.118 -0.058,4.096 l 11.184,14.473 c 2.683,3.471 3.026,-1.611 3.026,-1.611 0,0 -9.828,-11.869 -14.151,-16.958 z"
-         style="line-height:normal;text-indent:0;text-align:start;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;text-transform:none;isolation:auto;mix-blend-mode:normal"
-         color="#000000"
-         font-weight="400"
-         font-family="sans-serif"
-         white-space="normal"
-         overflow="visible"
-         fill="#263238"
-         fill-opacity="0.2"
-         id="path1000" />
-      <path
-         d="m 362.995,376.48 c -1.153,0 -2.526,0.373 -2.17,2.102 0.273,1.32 12.266,15.985 12.266,15.985 2.683,3.47 6.562,1.78 3.879,-1.691 l -11.143,-14.402 c -0.685,-0.763 -1.602,-1.957 -2.832,-1.994 z"
-         style="line-height:normal;text-indent:0;text-align:start;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;text-transform:none;isolation:auto;mix-blend-mode:normal"
-         color="#000000"
-         font-weight="400"
-         font-family="sans-serif"
-         white-space="normal"
-         overflow="visible"
-         fill="#8ab000"
-         id="path1002" />
-    </g>
-    <g
-       transform="matrix(2.63159,0,0,2.63157,467.369,-2270.475)"
-       id="g1014">
-      <rect
-         ry="3"
-         rx="3"
-         y="1010.36"
-         x="-37"
-         height="12.92"
-         width="38"
-         fill="#aeea00"
-         id="rect1006" />
-      <rect
-         width="38"
-         height="10"
-         x="-37"
-         y="1013.279"
-         rx="3"
-         ry="3"
-         fill="#263238"
-         fill-opacity="0.2"
-         id="rect1008" />
-      <rect
-         width="38"
-         height="10"
-         x="-37"
-         y="1010.362"
-         rx="3"
-         ry="3"
-         fill="#ffffff"
-         fill-opacity="0.298"
-         id="rect1010" />
-      <rect
-         width="38"
-         height="10.641"
-         x="-37"
-         y="1011.5"
-         rx="3"
-         ry="2.4560001"
-         fill="#aeea00"
-         id="rect1012" />
-    </g>
-    <g
-       transform="matrix(2.63159,0,0,2.63157,356.842,-2270.745)"
-       id="g1024">
-      <rect
-         ry="3"
-         rx="3"
-         y="1024.522"
-         x="5"
-         height="25.84"
-         width="38"
-         fill="#1976d2"
-         id="rect1016" />
-      <rect
-         width="38"
-         height="13"
-         x="5"
-         y="1037.3621"
-         rx="3"
-         ry="3"
-         fill="#263238"
-         fill-opacity="0.2"
-         id="rect1018" />
-      <rect
-         width="38"
-         height="13"
-         x="5"
-         y="1024.442"
-         rx="3"
-         ry="3"
-         fill="#ffffff"
-         fill-opacity="0.2"
-         id="rect1020" />
-      <rect
-         width="38"
-         height="23.559999"
-         x="5"
-         y="1025.662"
-         rx="3"
-         ry="2.7179999"
-         fill="#1976d2"
-         id="rect1022" />
-    </g>
-    <g
-       transform="matrix(2.63159,0,0,2.63157,356.842,396.264)"
-       id="g1030">
-      <path
-         d="m 24,17.75 c -2.88,0 -5.32,1.985 -6.033,4.65 H 21.18 A 3.215,3.215 0 0 1 24,20.75 3.228,3.228 0 0 1 27.25,24 3.228,3.228 0 0 1 24,27.25 3.219,3.219 0 0 1 21.07,25.4 h -3.154 c 0.642,2.766 3.132,4.85 6.084,4.85 3.434,0 6.25,-2.816 6.25,-6.25 0,-3.434 -2.816,-6.25 -6.25,-6.25 z"
-         style="line-height:normal;text-indent:0;text-align:start;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;text-transform:none;isolation:auto;mix-blend-mode:normal"
-         color="#000000"
-         font-weight="400"
-         font-family="sans-serif"
-         white-space="normal"
-         overflow="visible"
-         fill="#0d47a1"
-         id="path1026" />
-      <circle
-         r="9.5500002"
-         cy="24"
-         cx="24"
-         fill="none"
-         stroke="#0d47a1"
-         stroke-width="1.9"
-         stroke-linecap="round"
-         id="circle1028" />
-    </g>
-    <g
-       transform="matrix(2.63159,0,0,2.63157,356.842,-2269.159)"
-       id="g1036">
-      <ellipse
-         ry="3.875"
-         rx="3.375"
-         cx="14.375"
-         cy="1016.487"
-         fill="#263238"
-         fill-opacity="0.2"
-         id="ellipse1032" />
-      <circle
-         r="3.375"
-         cy="1016.987"
-         cx="14.375"
-         fill="#ffffff"
-         id="circle1034" />
-    </g>
-    <g
-       transform="matrix(2.63159,0,0,2.63157,408.158,-2269.159)"
-       id="g1042">
-      <ellipse
-         cy="1016.487"
-         cx="14.375"
-         rx="3.375"
-         ry="3.875"
-         fill="#263238"
-         fill-opacity="0.2"
-         id="ellipse1038" />
-      <circle
-         cx="14.375"
-         cy="1016.987"
-         r="3.375"
-         fill="#ffffff"
-         id="circle1040" />
-    </g>
-    <path
-       d="m 282.715,299.835 a 3.29,3.29 0 0 0 -2.662,5.336 l 9.474,12.261 A 7.894,7.894 0 0 0 289,320.257 v 18.21 a 7.877,7.877 0 0 0 7.895,7.895 h 84.21 A 7.877,7.877 0 0 0 389,338.468 v -18.211 c 0,-0.999 -0.19,-1.949 -0.525,-2.826 l 9.472,-12.26 a 3.29,3.29 0 0 0 -2.433,-5.334 3.29,3.29 0 0 0 -2.772,1.31 l -9.013,11.666 a 7.91,7.91 0 0 0 -2.624,-0.45 h -84.21 c -0.922,0 -1.8,0.163 -2.622,0.45 l -9.015,-11.666 a 3.29,3.29 0 0 0 -2.543,-1.312 z m 14.18,49.527 A 7.877,7.877 0 0 0 289,357.257 v 52.21 a 7.877,7.877 0 0 0 7.895,7.895 h 84.21 A 7.877,7.877 0 0 0 389,409.468 v -52.211 a 7.877,7.877 0 0 0 -7.895,-7.895 z"
-       style="line-height:normal;text-indent:0;text-align:start;text-decoration-line:none;text-decoration-style:solid;text-decoration-color:#000000;text-transform:none;isolation:auto;mix-blend-mode:normal;fill:url(#b)"
-       color="#000000"
-       font-weight="400"
-       font-family="sans-serif"
-       white-space="normal"
-       overflow="visible"
-       fill="url(#b)"
-       fill-rule="evenodd"
-       transform="translate(81,76)"
-       id="path1044" />
-  </g>
-</svg>

apps/smp-server/static/media/google_play.svg

@@ -1,39 +0,0 @@
-<svg width="135" height="41" viewBox="0 0 135 41" fill="none" xmlns="http://www.w3.org/2000/svg">
-<path d="M130 40.5H5C2.2 40.5 0 38.3 0 35.5V5.5C0 2.7 2.2 0.5 5 0.5H130C132.8 0.5 135 2.7 135 5.5V35.5C135 38.3 132.8 40.5 130 40.5Z" fill="black"/>
-<path d="M47.4 10.7C47.4 11.5 47.2 12.2 46.7 12.7C46.1 13.3 45.4 13.6 44.5 13.6C43.6 13.6 42.9 13.3 42.3 12.7C41.7 12.1 41.4 11.4 41.4 10.5C41.4 9.60002 41.7 8.90002 42.3 8.30002C42.9 7.70002 43.6 7.40002 44.5 7.40002C44.9 7.40002 45.3 7.50002 45.7 7.70002C46.1 7.90002 46.4 8.10002 46.6 8.40002L46.1 8.90002C45.7 8.40002 45.2 8.20002 44.5 8.20002C43.9 8.20002 43.3 8.40002 42.9 8.90002C42.4 9.30002 42.2 9.90002 42.2 10.6C42.2 11.3 42.4 11.9 42.9 12.3C43.4 12.7 43.9 13 44.5 13C45.2 13 45.7 12.8 46.2 12.3C46.5 12 46.7 11.6 46.7 11.1H44.5V10.3H47.4V10.7V10.7ZM52 8.20002H49.3V10.1H51.8V10.8H49.3V12.7H52V13.5H48.5V7.50002H52V8.20002ZM55.3 13.5H54.5V8.20002H52.8V7.50002H57V8.20002H55.3V13.5ZM59.9 13.5V7.50002H60.7V13.5H59.9ZM64.1 13.5H63.3V8.20002H61.6V7.50002H65.7V8.20002H64V13.5H64.1ZM73.6 12.7C73 13.3 72.3 13.6 71.4 13.6C70.5 13.6 69.8 13.3 69.2 12.7C68.6 12.1 68.3 11.4 68.3 10.5C68.3 9.60002 68.6 8.90002 69.2 8.30002C69.8 7.70002 70.5 7.40002 71.4 7.40002C72.3 7.40002 73 7.70002 73.6 8.30002C74.2 8.90002 74.5 9.60002 74.5 10.5C74.5 11.4 74.2 12.1 73.6 12.7ZM69.8 12.2C70.2 12.6 70.8 12.9 71.4 12.9C72 12.9 72.6 12.7 73 12.2C73.4 11.8 73.7 11.2 73.7 10.5C73.7 9.80002 73.5 9.20002 73 8.80002C72.6 8.40002 72 8.10002 71.4 8.10002C70.8 8.10002 70.2 8.30002 69.8 8.80002C69.4 9.20002 69.1 9.80002 69.1 10.5C69.1 11.2 69.3 11.8 69.8 12.2ZM75.6 13.5V7.50002H76.5L79.4 12.2V7.50002H80.2V13.5H79.4L76.3 8.60002V13.5H75.6V13.5Z" fill="white" stroke="white" stroke-width="0.2" stroke-miterlimit="10"/>
-<path d="M68.1 22.3C65.7 22.3 63.8 24.1 63.8 26.6C63.8 29 65.7 30.9 68.1 30.9C70.5 30.9 72.4 29.1 72.4 26.6C72.4 24 70.5 22.3 68.1 22.3ZM68.1 29.1C66.8 29.1 65.7 28 65.7 26.5C65.7 25 66.8 23.9 68.1 23.9C69.4 23.9 70.5 24.9 70.5 26.5C70.5 28 69.4 29.1 68.1 29.1ZM58.8 22.3C56.4 22.3 54.5 24.1 54.5 26.6C54.5 29 56.4 30.9 58.8 30.9C61.2 30.9 63.1 29.1 63.1 26.6C63.1 24 61.2 22.3 58.8 22.3ZM58.8 29.1C57.5 29.1 56.4 28 56.4 26.5C56.4 25 57.5 23.9 58.8 23.9C60.1 23.9 61.2 24.9 61.2 26.5C61.2 28 60.1 29.1 58.8 29.1ZM47.7 23.6V25.4H52C51.9 26.4 51.5 27.2 51 27.7C50.4 28.3 49.4 29 47.7 29C45 29 43 26.9 43 24.2C43 21.5 45.1 19.4 47.7 19.4C49.1 19.4 50.2 20 51 20.7L52.3 19.4C51.2 18.4 49.8 17.6 47.8 17.6C44.2 17.6 41.1 20.6 41.1 24.2C41.1 27.8 44.2 30.8 47.8 30.8C49.8 30.8 51.2 30.2 52.4 28.9C53.6 27.7 54 26 54 24.7C54 24.3 54 23.9 53.9 23.6H47.7V23.6ZM93.1 25C92.7 24 91.7 22.3 89.5 22.3C87.3 22.3 85.5 24 85.5 26.6C85.5 29 87.3 30.9 89.7 30.9C91.6 30.9 92.8 29.7 93.2 29L91.8 28C91.3 28.7 90.7 29.2 89.7 29.2C88.7 29.2 88.1 28.8 87.6 27.9L93.3 25.5L93.1 25V25ZM87.3 26.4C87.3 24.8 88.6 23.9 89.5 23.9C90.2 23.9 90.9 24.3 91.1 24.8L87.3 26.4ZM82.6 30.5H84.5V18H82.6V30.5ZM79.6 23.2C79.1 22.7 78.3 22.2 77.3 22.2C75.2 22.2 73.2 24.1 73.2 26.5C73.2 28.9 75.1 30.7 77.3 30.7C78.3 30.7 79.1 30.2 79.5 29.7H79.6V30.3C79.6 31.9 78.7 32.8 77.3 32.8C76.2 32.8 75.4 32 75.2 31.3L73.6 32C74.1 33.1 75.3 34.5 77.4 34.5C79.6 34.5 81.4 33.2 81.4 30.1V22.5H79.6V23.2V23.2ZM77.4 29.1C76.1 29.1 75 28 75 26.5C75 25 76.1 23.9 77.4 23.9C78.7 23.9 79.7 25 79.7 26.5C79.7 28 78.7 29.1 77.4 29.1ZM101.8 18H97.3V30.5H99.2V25.8H101.8C103.9 25.8 105.9 24.3 105.9 21.9C105.9 19.5 103.9 18 101.8 18V18ZM101.9 24H99.2V19.7H101.9C103.3 19.7 104.1 20.9 104.1 21.8C104 22.9 103.2 24 101.9 24ZM113.4 22.2C112 22.2 110.6 22.8 110.1 24.1L111.8 24.8C112.2 24.1 112.8 23.9 113.5 23.9C114.5 23.9 115.4 24.5 115.5 25.5V25.6C115.2 25.4 114.4 25.1 113.6 25.1C111.8 25.1 110 26.1 110 27.9C110 29.6 111.5 30.7 113.1 30.7C114.4 30.7 115 30.1 115.5 29.5H115.6V30.5H117.4V25.7C117.2 23.5 115.5 22.2 113.4 22.2V22.2ZM113.2 29.1C112.6 29.1 111.7 28.8 111.7 28C111.7 27 112.8 26.7 113.7 26.7C114.5 26.7 114.9 26.9 115.4 27.1C115.2 28.3 114.2 29.1 113.2 29.1V29.1ZM123.7 22.5L121.6 27.9H121.5L119.3 22.5H117.3L120.6 30.1L118.7 34.3H120.6L125.7 22.5H123.7V22.5ZM106.9 30.5H108.8V18H106.9V30.5Z" fill="white"/>
-<path d="M10.4 8C10.1 8.3 10 8.8 10 9.4V31.5C10 32.1 10.2 32.6 10.5 32.9L10.6 33L23 20.6V20.4L10.4 8Z" fill="url(#paint0_linear_7_408)"/>
-<path d="M27 24.8L22.9 20.7V20.4L27 16.3L27.1 16.4L32 19.2C33.4 20 33.4 21.3 32 22.1L27 24.8V24.8Z" fill="url(#paint1_linear_7_408)"/>
-<path d="M27.1 24.7L22.9 20.5L10.4 33C10.9 33.5 11.6 33.5 12.5 33.1L27.1 24.7" fill="url(#paint2_linear_7_408)"/>
-<path d="M27.1 16.3001L12.5 8.00005C11.6 7.50005 10.9 7.60005 10.4 8.10005L22.9 20.5001L27.1 16.3001V16.3001Z" fill="url(#paint3_linear_7_408)"/>
-<path opacity="0.2" d="M27 24.6L12.5 32.8C11.7 33.3 11 33.2 10.5 32.8L10.4 32.9L10.5 33C11 33.4 11.7 33.5 12.5 33L27 24.6Z" fill="black"/>
-<path opacity="0.12" d="M10.4 32.8C10.1 32.5 10 32 10 31.4V31.5C10 32.1 10.2 32.6 10.5 32.9V32.8H10.4ZM32 21.8L27 24.6L27.1 24.7L32 21.9C32.7 21.5 33 21 33 20.5C33 21 32.6 21.4 32 21.8V21.8Z" fill="black"/>
-<path opacity="0.25" d="M12.5 8.10003L32 19.2C32.6 19.6 33 20 33 20.5C33 20 32.7 19.5 32 19.1L12.5 8.00003C11.1 7.20003 10 7.80003 10 9.40003V9.50003C10 8.00003 11.1 7.30003 12.5 8.10003Z" fill="white"/>
-<defs>
-<linearGradient id="paint0_linear_7_408" x1="21.8" y1="9.21" x2="5.017" y2="25.992" gradientUnits="userSpaceOnUse">
-<stop stop-color="#00A0FF"/>
-<stop offset="0.007" stop-color="#00A1FF"/>
-<stop offset="0.26" stop-color="#00BEFF"/>
-<stop offset="0.512" stop-color="#00D2FF"/>
-<stop offset="0.76" stop-color="#00DFFF"/>
-<stop offset="1" stop-color="#00E3FF"/>
-</linearGradient>
-<linearGradient id="paint1_linear_7_408" x1="33.834" y1="20.501" x2="9.63699" y2="20.501" gradientUnits="userSpaceOnUse">
-<stop stop-color="#FFE000"/>
-<stop offset="0.409" stop-color="#FFBD00"/>
-<stop offset="0.775" stop-color="#FFA500"/>
-<stop offset="1" stop-color="#FF9C00"/>
-</linearGradient>
-<linearGradient id="paint2_linear_7_408" x1="24.827" y1="22.796" x2="2.069" y2="45.554" gradientUnits="userSpaceOnUse">
-<stop stop-color="#FF3A44"/>
-<stop offset="1" stop-color="#C31162"/>
-</linearGradient>
-<linearGradient id="paint3_linear_7_408" x1="7.29699" y1="0.676051" x2="17.46" y2="10.8391" gradientUnits="userSpaceOnUse">
-<stop stop-color="#32A071"/>
-<stop offset="0.069" stop-color="#2DA771"/>
-<stop offset="0.476" stop-color="#15CF74"/>
-<stop offset="0.801" stop-color="#06E775"/>
-<stop offset="1" stop-color="#00F076"/>
-</linearGradient>
-</defs>
-</svg>

apps/smp-server/static/media/logo-symbol-dark.svg

@@ -1,10 +0,0 @@
-<svg width="34" height="35" viewBox="0 0 34 35" fill="none" xmlns="http://www.w3.org/2000/svg">
-<path fill-rule="evenodd" clip-rule="evenodd" d="M3.02958 8.60922L8.622 14.2013L14.3705 8.45375L17.1669 11.2498L11.4183 16.9972L17.0114 22.5895L14.1373 25.4633L8.54422 19.871L2.79636 25.6187L0 22.8227L5.74794 17.075L0.155484 11.483L3.02958 8.60922Z" fill="white"/>
-<path fill-rule="evenodd" clip-rule="evenodd" d="M14.0923 25.5156L16.944 22.6642L16.9429 22.6634L22.6467 16.9612L17.0513 11.3675L17.0523 11.367L14.2548 8.56979L8.65972 2.97535L11.5114 0.123963L17.1061 5.71849L22.8099 0.015625L25.6074 2.81285L19.9035 8.51562L25.4984 14.1099L31.2025 8.40729L34 11.2045L28.2958 16.907L33.8917 22.5017L31.0399 25.3531L25.4442 19.7584L19.7409 25.4611L25.3365 31.0559L22.4848 33.9073L16.8892 28.3124L11.1864 34.0156L8.38885 31.2184L14.0923 25.5156Z" fill="url(#paint0_linear_656_10815)"/>
-<defs>
-<linearGradient id="paint0_linear_656_10815" x1="12.8381" y1="-0.678252" x2="9.54355" y2="31.4493" gradientUnits="userSpaceOnUse">
-<stop stop-color="#01F1FF"/>
-<stop offset="1" stop-color="#0197FF"/>
-</linearGradient>
-</defs>
-</svg>

apps/smp-server/static/media/logo-symbol-light.svg

@@ -1,15 +0,0 @@
-<svg width="34" height="34" viewBox="0 0 34 34" fill="none" xmlns="http://www.w3.org/2000/svg">
-<g clip-path="url(#clip0_14_10)">
-<path fill-rule="evenodd" clip-rule="evenodd" d="M3.02972 8.59396L8.62219 14.186L14.3703 8.43848L17.1668 11.2346L11.4182 16.982L17.0112 22.5742L14.1371 25.448L8.5441 19.8557L2.79651 25.6035L0 22.8074L5.74813 17.0597L0.155656 11.4678L3.02972 8.59396Z" fill="#023789"/>
-<path fill-rule="evenodd" clip-rule="evenodd" d="M14.0922 25.5L16.9434 22.6486L16.9423 22.6478L22.6464 16.9456L17.0512 11.3519L17.0518 11.3514L14.2542 8.55418L8.65961 2.95973L11.5114 0.108337L17.106 5.70288L22.8095 0L25.607 2.79722L19.903 8.5L25.4981 14.0943L31.2022 8.39169L33.9997 11.1889L28.2957 16.8914L33.8914 22.4861L31.0396 25.3375L25.4439 19.7428L19.7404 25.4454L25.3361 31.0403L22.4843 33.8917L16.8887 28.2968L11.1862 34L8.38867 31.2028L14.0922 25.5Z" fill="url(#paint0_linear_14_10)"/>
-</g>
-<defs>
-<linearGradient id="paint0_linear_14_10" x1="12.8379" y1="-0.693875" x2="9.54344" y2="31.4337" gradientUnits="userSpaceOnUse">
-<stop stop-color="#01F1FF"/>
-<stop offset="1" stop-color="#0197FF"/>
-</linearGradient>
-<clipPath id="clip0_14_10">
-<rect width="34" height="34" fill="white"/>
-</clipPath>
-</defs>
-</svg>

apps/smp-server/static/media/moon.svg

@@ -1,3 +0,0 @@
-<svg width="16" height="16" viewBox="0 0 16 16" fill="none" xmlns="http://www.w3.org/2000/svg">
-<path d="M2.92814 12.6789C6.17655 15.9347 11.7044 15.6463 14.5425 12.0117C14.6636 11.8566 14.6825 11.6448 14.5907 11.4708C14.4989 11.2967 14.3136 11.1926 14.1172 11.2049C11.5269 11.3673 8.97627 10.4315 7.0743 8.52765C5.17264 6.62414 4.23958 4.06868 4.40169 1.47281C4.41397 1.2762 4.30965 1.09069 4.13526 0.999048C3.96088 0.907402 3.74893 0.926696 3.59396 1.04833C3.36099 1.23117 3.13828 1.42685 2.92823 1.63726C-0.111372 4.68223 -0.111585 9.63533 2.92814 12.6789Z" stroke="black" stroke-miterlimit="10" stroke-linejoin="round"/>
-</svg>

apps/smp-server/static/media/script.js

@@ -1,39 +0,0 @@
-const isMobile = {
-    Android: () => navigator.userAgent.match(/Android/i),
-    iOS: () => navigator.userAgent.match(/iPhone|iPad|iPod/i)
-};
-
-window.addEventListener('click', clickHandler)
-
-if (isMobile.iOS) {
-    for (const btn of document.getElementsByClassName("close-overlay-btn")) {
-        btn.addEventListener("touchend", (e) => setTimeout(() => closeOverlay(e), 100))
-    }
-}
-
-function clickHandler(e) {
-    if (e.target.closest('.contact-tab-btn')) {
-        e.target.closest('.contact-tab').classList.toggle('active')
-    }
-}
-
-window.addEventListener('load', () => {
-    const googlePlayBtn = document.querySelector('.google-play-btn');
-    const appleStoreBtn = document.querySelector('.apple-store-btn');
-    const fDroidBtn = document.querySelector('.f-droid-btn');
-    if (!googlePlayBtn || !appleStoreBtn || !fDroidBtn) return;
-
-
-    if (isMobile.Android()) {
-        googlePlayBtn.classList.remove('hidden');
-        fDroidBtn.classList.remove('hidden');
-    }
-    else if (isMobile.iOS()) {
-        appleStoreBtn.classList.remove('hidden');
-    }
-    else {
-        appleStoreBtn.classList.remove('hidden');
-        googlePlayBtn.classList.remove('hidden');
-        fDroidBtn.classList.remove('hidden');
-    }
-})

apps/smp-server/static/media/style.css

@@ -1,410 +0,0 @@
-@font-face {
-  font-family: Gilroy;
-  src: url("GilroyRegular.woff2") format("woff2");
-  font-weight: 400;
-  font-style: normal;
-}
-
-@font-face {
-  font-family: Gilroy;
-  src: url("GilroyLight.woff2") format("woff2");
-  font-weight: 300;
-  font-style: normal;
-}
-
-@font-face {
-  font-family: Gilroy;
-  src: url("GilroyMedium.woff2") format("woff2");
-  font-weight: 500;
-  font-style: normal;
-}
-
-@font-face {
-  font-family: Gilroy;
-  src: url("GilroyBold.woff2") format("woff2");
-  font-weight: 700;
-  font-style: normal;
-}
-
-@font-face {
-  font-family: Gilroy;
-  src: url("GilroyRegularItalic.woff2") format("woff2");
-  font-weight: 400;
-  font-style: italic;
-}
-
-html {
-  scroll-behavior: smooth;
-  font-family: Gilroy, Helvetica, sans-serif;
-  ;
-  letter-spacing: 0.003em;
-}
-
-img {
-  user-select: none;
-  -webkit-user-select: none;
-  /* For Safari and older Chrome versions */
-  -moz-user-select: none;
-  /* For Firefox */
-  -ms-user-select: none;
-  /* For Internet Explorer and Edge */
-}
-
-/* NEW SITE */
-.container,
-.container-fluid,
-.container-xxl,
-.container-xl,
-.container-lg,
-.container-md,
-.container-sm {
-  width: 100%;
-  /* padding: 0 20px; */
-  margin-right: auto;
-  margin-left: auto;
-}
-
-@media (min-width: 576px) {
-
-  .container-sm,
-  .container {
-    max-width: 540px;
-  }
-}
-
-@media (min-width: 768px) {
-
-  .container-md,
-  .container-sm,
-  .container {
-    max-width: 720px;
-  }
-}
-
-@media (min-width: 992px) {
-
-  .container-lg,
-  .container-md,
-  .container-sm,
-  .container {
-    max-width: 960px;
-  }
-}
-
-@media (min-width: 1200px) {
-
-  .container-xl,
-  .container-lg,
-  .container-md,
-  .container-sm,
-  .container {
-    max-width: 1140px;
-  }
-}
-
-@media (min-width: 1400px) {
-
-  .container-xxl,
-  .container-xl,
-  .container-lg,
-  .container-md,
-  .container-sm,
-  .container {
-    max-width: 1320px;
-  }
-}
-
-.gradient-text {
-  background: -webkit-linear-gradient(to bottom, #53C1FF -50%, #0053D0 160%);
-  background: linear-gradient(to bottom, #53C1FF -50%, #0053D0 160%);
-  -webkit-background-clip: text;
-  -webkit-text-fill-color: transparent;
-  background-clip: text;
-  text-fill-color: transparent;
-}
-
-.dark .border-gradient {
-  background:
-    linear-gradient(#11182F, #11182F) padding-box,
-    linear-gradient(to bottom, transparent, #01F1FF 58%) border-box;
-  border: 1px solid transparent;
-}
-
-.dark .only-light {
-  display: none;
-}
-
-.only-dark {
-  display: none;
-}
-
-.dark .only-dark {
-  display: inherit;
-}
-
-.menu-link {
-  font-size: 16px;
-  line-height: 33.42px;
-  color: #0D0E12;
-}
-
-.dark .menu-link {
-  color: #fff;
-}
-
-.nav-link ul li a.active {
-  color: #0053D0;
-
-}
-
-.dark .nav-link ul li a.active {
-  color: #66D9E2;
-}
-
-@media (min-width:1024px) {
-
-  .nav-link-text,
-  .menu-link {
-    display: inline-block;
-    position: relative;
-    color: #0D0E12;
-  }
-
-  .nav-link-text::before,
-  .active .nav-link-text::before,
-  .menu-link::before {
-    content: "";
-    position: absolute;
-    width: 0;
-    height: 1px;
-    bottom: 0;
-    right: 0;
-    /* background-color: initial; */
-    transition: width 0.25s ease-out;
-  }
-
-  .menu-link::before {
-    background-color: #0D0E12;
-  }
-
-  .dark .menu-link::before {
-    background-color: #fff;
-  }
-
-  .active .nav-link-text::before {
-    width: 100%;
-  }
-
-  .nav-link:hover .nav-link-text::before,
-  .menu-link:hover::before {
-    width: 100%;
-    left: 0;
-    right: auto;
-  }
-}
-
-
-.sub-menu {
-  visibility: hidden;
-  opacity: 0;
-  color: #505158;
-}
-
-.sub-menu .no-hover {
-  color: #505158 !important;
-}
-
-.dark .sub-menu,
-.dark .sub-menu .no-hover {
-  color: #fff !important;
-}
-
-.dark .sub-menu li:hover {
-  color: #66D9E2;
-}
-
-.sub-menu li:hover {
-  color: #0053D0;
-}
-
-.sub-menu {
-  transition: all .3s ease !important;
-}
-
-.nav-link span svg,
-header nav {
-  transition: all 0.5s ease;
-}
-
-.nav-link:hover span svg {
-  transform: rotate(180deg);
-}
-
-@media (min-width:1024px) {
-
-  .nav-link:hover .sub-menu,
-  .nav-link:focus-within .sub-menu {
-    visibility: visible;
-    opacity: 1;
-    margin-top: 0;
-  }
-}
-
-@media (max-width: 1024px) {
-  .sub-menu {
-    max-height: 0;
-    transform: translateY(-10px);
-    transition: all .7s ease !important;
-  }
-
-  .active .sub-menu {
-    max-height: 600px;
-    transform: translateY(0px);
-    opacity: 1;
-    visibility: visible;
-    margin-top: 0;
-  }
-
-  header nav {
-    visibility: hidden;
-    opacity: 0;
-    transform: translateX(100%);
-  }
-
-  header nav.open {
-    visibility: visible;
-    opacity: 1;
-    transform: translateX(0);
-  }
-}
-
-.lock-scroll {
-  overflow: hidden;
-}
-
-/* hero */
-header {
-  transition: all .7s ease;
-}
-
-.primary-header {
-  background: linear-gradient(270deg, #0053D0 35.85%, #0197FF 94.78%);
-  -webkit-background-clip: text;
-  -webkit-text-fill-color: transparent;
-  background-clip: text;
-  text-shadow: 0px 4px 74px #e9e7e2;
-}
-
-.dark .primary-header {
-  background: linear-gradient(270deg, #70F0F9 100%, #70F0F9 100%);
-  -webkit-background-clip: text;
-  -webkit-text-fill-color: transparent;
-  background-clip: text;
-  text-shadow: none;
-}
-
-.secondary-header {
-  color: #606c71;
-  text-shadow: 0px 4px 74px #e9e7e2;
-}
-
-.dark .secondary-header {
-  color: #fff;
-  text-shadow: none;
-}
-
-.description {
-  width: 31rem;
-}
-
-p a {
-  color: #0053D0;
-  text-decoration: underline;
-  text-underline-offset: 2px;
-}
-
-.dark p a {
-  color: #70F0F9;
-}
-
-/* For Contact & Invitation Page */
-.primary-header-contact {
-  background: linear-gradient(251.16deg, #53c1ff 1.1%, #0053d0 100.82%);
-  -webkit-background-clip: text;
-  -webkit-text-fill-color: transparent;
-  background-clip: text;
-  text-shadow: 0px 4px 74px #e9e7e2;
-}
-
-.dark .primary-header-contact {
-  background: linear-gradient(270deg, #70F0F9 100%, #70F0F9 100%);
-  -webkit-background-clip: text;
-  -webkit-text-fill-color: transparent;
-  background-clip: text;
-  text-shadow: none;
-}
-
-.secondary-header-contact {
-  text-shadow: 0px 4px 74px #e9e7e2;
-}
-
-.dark .secondary-header-contact {
-  text-shadow: none;
-}
-
-.content_copy_with_tooltip {
-  background-color: #f8f8f6;
-  border-radius: 50px;
-  padding-bottom: 4px;
-  padding-top: 8px;
-  margin-top: 16px;
-  margin-bottom: 16px;
-}
-
-.content_copy_with_tooltip .tooltip {
-  vertical-align: -6px;
-}
-
-.content_copy_with_tooltip .content {
-  font-size: 15px;
-}
-
-.contact-tab>.contact-tab-content,
-.job-tab>.job-tab-content {
-  opacity: 0;
-  max-height: 0;
-  transition: all 0.5s ease;
-  visibility: hidden;
-  transform: translateY(10px);
-  overflow: hidden;
-}
-
-.contact-tab svg,
-.job-tab svg {
-  transform: rotate(-180deg);
-  transition: all .5s ease;
-}
-
-.contact-tab.active>.contact-tab-content,
-.job-tab.active>.job-tab-content {
-  opacity: 1;
-  max-height: 300px;
-  visibility: visible;
-  transform: translateY(0px);
-}
-
-.for-tablet .contact-tab.active>.contact-tab-content,
-.for-tablet .job-tab.active>.job-tab-content {
-  min-height: 450px;
-}
-
-.contact-tab.active svg,
-.contact-tab:hover svg,
-.job-tab.active svg,
-.job-tab:hover svg {
-  transform: rotate(0deg);
-}
-
-.d-none-if-js-disabled {
-  display: none !important;
-}

apps/smp-server/static/media/sun.svg

@@ -1,11 +0,0 @@
-<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
-<path d="M23.9958 12.2815C23.9363 12.3954 23.8849 12.5146 23.8158 12.6224C23.5945 12.9674 23.2766 13.1624 22.8654 13.1685C22.2182 13.1782 21.5707 13.1764 20.9234 13.17C20.2781 13.1636 19.7772 12.6464 19.7773 11.9999C19.7774 11.3535 20.2754 10.8389 20.9237 10.8303C21.532 10.8221 22.1405 10.8258 22.7488 10.8278C23.3522 10.8298 23.7281 11.0908 23.9462 11.6508C23.956 11.6761 23.9789 11.6964 23.9958 11.719C23.9958 11.9064 23.9958 12.094 23.9958 12.2815Z" fill="white"/>
-<path d="M11.7154 24.0003C11.6217 23.9526 11.5256 23.9088 11.4345 23.8564C11.0545 23.6377 10.836 23.3104 10.8286 22.87C10.8175 22.2149 10.8179 21.5593 10.828 20.9042C10.8378 20.2738 11.3597 19.7812 11.9967 19.7812C12.6336 19.7812 13.155 20.2739 13.1654 20.9042C13.1757 21.5359 13.1717 22.168 13.1682 22.7998C13.1652 23.3392 12.8885 23.7369 12.3906 23.937C12.3509 23.9529 12.3153 23.979 12.2779 24.0003C12.0904 24.0003 11.9029 24.0003 11.7154 24.0003Z" fill="white"/>
-<path d="M17.2592 11.9958C17.2733 14.8825 14.9232 17.2468 12.0032 17.2612C9.11732 17.2754 6.75397 14.9264 6.73836 12.0041C6.72295 9.12027 9.07502 6.75326 11.9946 6.73835C14.8788 6.72363 17.2449 9.07587 17.2592 11.9958Z" stroke="white" stroke-width="1.5"/>
-<path d="M13.1693 2.11324C13.1692 2.43329 13.1744 2.75345 13.1682 3.07341C13.1555 3.7216 12.6425 4.21934 11.995 4.21864C11.3493 4.21789 10.8358 3.71808 10.828 3.06768C10.8204 2.42766 10.8201 1.78736 10.8283 1.14738C10.8365 0.500704 11.3562 -0.000843934 12.0007 1.06615e-06C12.6437 0.000846066 13.1564 0.504314 13.1684 1.15307C13.1743 1.47303 13.1694 1.79318 13.1693 2.11324Z" fill="white"/>
-<path d="M2.10878 13.1714C1.78877 13.1714 1.46872 13.1754 1.14885 13.1705C0.504832 13.1605 -0.000422735 12.6426 2.65407e-07 11.9987C0.000423265 11.3553 0.503376 10.838 1.15138 10.8301C1.79126 10.8223 2.43138 10.8222 3.07126 10.8303C3.72034 10.8385 4.21822 11.3541 4.21794 12.0012C4.21766 12.6477 3.71555 13.1609 3.06872 13.1706C2.7488 13.1753 2.42875 13.1714 2.10878 13.1714Z" fill="white"/>
-<path d="M6.85268 5.524C6.82732 6.152 6.60944 6.52005 6.16969 6.72981C5.73844 6.93552 5.29738 6.90378 4.94534 6.58208C4.41604 6.09838 3.90431 5.59148 3.42451 5.05894C3.02923 4.62023 3.09727 3.9209 3.51626 3.50792C3.9361 3.09409 4.63284 3.03567 5.06893 3.43194C5.59381 3.90888 6.09569 4.41446 6.57188 4.93996C6.73726 5.12252 6.79642 5.4014 6.85268 5.524Z" fill="white"/>
-<path d="M17.1426 18.4446C17.1749 17.8424 17.389 17.4819 17.8198 17.2738C18.2418 17.07 18.6812 17.0888 19.0265 17.3998C19.5706 17.8899 20.0919 18.4099 20.5814 18.9544C20.9675 19.384 20.895 20.0764 20.485 20.4873C20.0824 20.8907 19.3961 20.9756 18.9718 20.5988C18.4129 20.1026 17.89 19.5625 17.3864 19.0096C17.2323 18.8405 17.1926 18.5671 17.1426 18.4446Z" fill="white"/>
-<path d="M18.2026 6.84235C17.8449 6.82333 17.4821 6.61377 17.2723 6.18256C17.0626 5.7515 17.0878 5.30837 17.4061 4.95629C17.8919 4.41887 18.4055 3.90234 18.945 3.41897C19.3826 3.02693 20.0905 3.1037 20.4947 3.52429C20.9057 3.95198 20.9561 4.64003 20.5568 5.07805C20.0843 5.59645 19.576 6.08306 19.071 6.5708C18.8688 6.76619 18.6057 6.84832 18.2026 6.84235Z" fill="white"/>
-<path d="M5.54205 17.1445C6.14812 17.1747 6.51058 17.385 6.72137 17.8153C6.9323 18.2459 6.90765 18.6892 6.58942 19.0415C6.1037 19.5791 5.58933 20.0948 5.05088 20.5795C4.62165 20.9659 3.93035 20.8989 3.51681 20.4933C3.09875 20.0833 3.02864 19.3789 3.4227 18.942C3.908 18.404 4.42706 17.8934 4.96382 17.4066C5.13982 17.247 5.41663 17.1985 5.54205 17.1445Z" fill="white"/>
-</svg>

apps/smp-server/web/Static.hs

@@ -1,176 +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 as B
-import Data.Maybe (fromMaybe)
-import Data.String (fromString)
-import Data.Text.Encoding (encodeUtf8)
-import Network.Wai.Application.Static as S
-import Network.Wai.Handler.Warp as W
-import qualified Network.Wai.Handler.WarpTLS as W
-import Simplex.Messaging.Encoding.String (strEncode)
-import Simplex.Messaging.Server.Information
-import Simplex.Messaging.Server.Main (EmbeddedWebParams (..), WebHttpsParams (..))
-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)
-
-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)"
-    W.runTLS (W.tlsSettings cert key) (mkSettings port) (S.staticApp $ S.defaultFileServerSettings webStaticPath)
-  where
-    mkSettings port = setPort port defaultSettings
-
-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),
-            ("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", fmap encodeUtf8 $ serverCountry =<< information)
-          ]
-
--- 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 <> "}"

apps/smp-server/web/Static/Embedded.hs

@@ -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/")

apps/xftp-server/Main.hs

@@ -1,21 +0,0 @@
-module Main where
-
-import Control.Logger.Simple
-import Simplex.Messaging.Server.CLI (getEnvPath)
-import Simplex.FileTransfer.Server.Main
-
-defaultCfgPath :: FilePath
-defaultCfgPath = "/etc/opt/simplex-xftp"
-
-defaultLogPath :: FilePath
-defaultLogPath = "/var/opt/simplex-xftp"
-
-logCfg :: LogConfig
-logCfg = LogConfig {lc_file = Nothing, lc_stderr = True}
-
-main :: IO ()
-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

apps/xftp/Main.hs

@@ -1,6 +0,0 @@
-module Main where
-
-import Simplex.FileTransfer.Client.Main
-
-main :: IO ()
-main = xftpClientCLI

cabal.project

@@ -1,30 +1,6 @@
 packages: .
--- packages: . ../direct-sqlcipher ../sqlcipher-simple
--- packages: . ../hs-socks
--- packages: . ../http2
--- packages: . ../network-transport
-
-index-state: 2023-12-12T00:00:00Z
-
-package cryptostore
-    flags: +use_crypton
 
 source-repository-package
     type: git
-    location: https://github.com/simplex-chat/aeson.git
-    tag: aab7b5a14d6c5ea64c64dcaee418de1bb00dcc2b
-
-source-repository-package
-    type: git
-    location: https://github.com/simplex-chat/hs-socks.git
-    tag: a30cc7a79a08d8108316094f8f2f82a0c5e1ac51
-
-source-repository-package
-    type: git
-    location: https://github.com/simplex-chat/direct-sqlcipher.git
-    tag: f814ee68b16a9447fbb467ccc8f29bdd3546bfd9
-
-source-repository-package
-    type: git
-    location: https://github.com/simplex-chat/sqlcipher-simple.git
-    tag: a46bd361a19376c5211f1058908fc0ae6bf42446
+    location: git://github.com/simplex-chat/aeson.git
+    tag: 3eb66f9a68f103b5f1489382aad89f5712a64db7

cbits/README.md

@@ -1,3 +0,0 @@
-# Streamlined NTRU Prime: sntrup761
-
-The implementation of sntrup761 is the _exact_ copy from this [Internet draft](https://www.ietf.org/archive/id/draft-josefsson-ntruprime-streamlined-00.html).

cbits/sha512.c

@@ -1,9 +0,0 @@
-#include <openssl/sha.h>
-#include "sha512.h"
-
-void crypto_hash_sha512 (unsigned char *out,
-                         const unsigned char *in,
-                         unsigned long long inlen)
-{
-  SHA512(in, inlen, out);
-}

cbits/sha512.h

@@ -1,3 +0,0 @@
-void crypto_hash_sha512 (unsigned char *out,
-                         const unsigned char *in,
-                         unsigned long long inlen);

cbits/sntrup761.h

@@ -1,33 +0,0 @@
-/*
- * Derived from public domain source, written by (in alphabetical order):
- * - Daniel J. Bernstein
- * - Chitchanok Chuengsatiansup
- * - Tanja Lange
- * - Christine van Vredendaal
- */
-
-#ifndef SNTRUP761_H
-#define SNTRUP761_H
-
-#include <string.h>
-#include <stdint.h>
-
-#define SNTRUP761_SECRETKEY_SIZE 1763
-#define SNTRUP761_PUBLICKEY_SIZE 1158
-#define SNTRUP761_CIPHERTEXT_SIZE 1039
-#define SNTRUP761_SIZE 32
-
-typedef void sntrup761_random_func (void *ctx, size_t length, uint8_t *dst);
-
-void
-sntrup761_keypair (uint8_t *pk, uint8_t *sk,
-                   void *random_ctx, sntrup761_random_func *random);
-
-void
-sntrup761_enc (uint8_t *c, uint8_t *k, const uint8_t *pk,
-               void *random_ctx, sntrup761_random_func *random);
-
-void
-sntrup761_dec (uint8_t *k, const uint8_t *c, const uint8_t *sk);
-
-#endif /* SNTRUP761_H */

fourmolu.yaml

@@ -1,30 +0,0 @@
-indentation: 2
-column-limit: none
-function-arrows: trailing
-comma-style: trailing
-import-export-style: trailing
-indent-wheres: true
-record-brace-space: true
-newlines-between-decls: 1
-haddock-style: single-line
-haddock-style-module: null
-let-style: inline
-in-style: right-align
-single-constraint-parens: never
-unicode: never
-respectful: true
-fixities:
-  - infixr 9 .
-  - infixr 8 .:, .:., .=
-  - infixr 6 <>
-  - infixr 5 ++
-  - infixl 4 <$>, <$, $>,  <$$>, <$?>
-  - infixl 4 <*>, <*, *>, <**>
-  - infix 4 ==, /=
-  - infixr 3 &&
-  - infixl 3 <|>
-  - infixr 2 ||
-  - infixl 1 >>, >>=
-  - infixr 1 =<<, >=>, <=<
-  - infixr 0 $, $!
-reexports: []

img/linode.svg

@@ -1 +1 @@
-<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 506.94 131.5"><path d="m109.65 58.21-18.21-10.07-15.37 9.38-.19 9.59-7.47-4.92-10.16 6.19-.44-10.48-10.48-7 10-5.17c-.08 0 0 1-1.48-34.34l-23.65-11.39-32.2 10 7.19 34.63 10.81 8.37-8.22 3.9 5.37 26.1 7.55 7.09-5.4 3.29 4.19 20.18 16.94 17.94c.08-.1 1.78-1.41 21.79-17.32l-.58-13.71 8.58 7.28c.12-.12 1.84-1.39 17.56-13.89l.61-10.14 6.48 4.5c.13-.12 1.58-1.22 14.26-11.33z" fill="#231f20"/><path d="m94.54 69 15.11-10.79-18.21-10.07-15.37 9.38z"/><path d="m92.87 88.2 1.67-19.2-18.47-11.48-.38 18.75z" fill="#004b16"/><path d="m68.22 107.73v-19.89l-18.66-14.15 1.47 19.54z" fill="#004b16"/><path d="m68.22 87.84 18.74-13.43-18.55-12.22-18.85 11.5z"/><path d="m38.43 131.48-2.98-20.32-18.15-17.8 4.19 20.18z" fill="#004b16"/><path d="m35.45 111.16 23.91-17.06-18.53-15.09-23.53 14.35z"/><path d="m33.9 100.6-3.94-26.88-20.22-16.81 5.41 26.07z" fill="#004b16"/><path d="m29.96 73.72 27.85-15.82-20.8-13.94-27.27 12.95z"/><path d="m28.07 60.88-5.4-36.81-22.67-14.06 7.19 34.62z" fill="#004b16"/><path d="m22.67 24.07 33.14-12.7-23.61-11.37-32.2 10.01z"/><g fill="#1cb35c"><path d="m107.13 76.87c-14.02 11.13-14.33 11.33-14.26 11.33 1.74-20.1 1.59-19.2 1.67-19.2 16-11.45 15-10.79 15.11-10.79z"/><path d="m85.78 93.84c-17.35 13.8-17.63 13.89-17.56 13.89-.17-20.82-.07-19.89 0-19.89 20-14.3 18.67-13.43 18.74-13.43z"/><path d="m60.22 114.16c-21.66 17.22-21.86 17.32-21.79 17.32-3.07-20.94-3-20.32-3-20.32 25.47-18.16 23.86-17.06 23.93-17.06z"/><path d="m55.81 11.37c1.52 35.37 1.4 34.34 1.48 34.34-28.66 14.89-29.29 15.17-29.22 15.17-5.52-37.63-5.47-36.81-5.4-36.81z"/><path d="m57.81 57.9c1.15 26.81 1 25.88 1.11 25.88-24.81 16.67-25.09 16.82-25 16.82-4-27.58-4-26.88-3.94-26.88z"/></g><path xmlns="http://www.w3.org/2000/svg" d="m151.61 14.24 16.58-4v79.88q0 13.13 7.83 15.65-3.84 7.31-13.13 7.3-11.28 0-11.28-15.66z"/><path d="m186.66 111.72v-57.42h-9.08v-13.6h25.86v71zm8.56-98.54a9.62 9.62 0 1 1 -9.62 9.62 9.63 9.63 0 0 1 9.62-9.62z"/><path d="m262.94 111.74v-41.06c0-6.05-1.16-10.48-3.48-13.26s-6.11-4.18-11.37-4.18a17.74 17.74 0 0 0 -7.8 2.06 18 18 0 0 0 -6.46 5.1v51.34h-16.59v-71h11.94l3 6.64q6.76-8 20-8 12.66 0 20 7.59t7.33 21.19v43.58z"/><path d="m288.42 76.06q0-16.26 9.38-26.47t24.77-10.21q16.19 0 25.14 9.82t9 26.86q0 17-9.12 27t-25 10q-16.18 0-25.17-10.12t-9-26.88zm17.24 0q0 23.47 16.91 23.48a14.54 14.54 0 0 0 12.31-6.11q4.55-6.09 4.54-17.37 0-23.14-16.85-23.15a14.61 14.61 0 0 0 -12.33 6.09q-4.58 6.11-4.58 17.06z"/><path d="m412.37 111.74v-4.31c-1.37 1.5-3.71 2.82-7 3.95a31.33 31.33 0 0 1 -10.15 1.69q-14.87 0-23.38-9.42t-8.52-26.27q0-16.84 9.78-27.42a32 32 0 0 1 24.51-10.58 32.37 32.37 0 0 1 14.72 3.32v-28.46l16.58-4v101.5zm0-54.06a17.6 17.6 0 0 0 -11.07-4.24q-10 0-15.33 6.07t-5.37 17.41q0 22.15 21.36 22.15a16.11 16.11 0 0 0 5.87-1.42c2.32-1 3.83-1.92 4.54-2.89z"/><path d="m505.55 81.3h-50.74q.46 8.49 5.83 13.2t14.46 4.7q11.34 0 17.25-5.9l6.43 12.7q-8.75 7.09-26.13 7.1-16.25 0-25.7-9.52t-9.45-26.58q0-16.78 10.38-27.2a33.91 33.91 0 0 1 24.9-10.41q15.45 0 24.81 9.22t9.35 23.48a46.28 46.28 0 0 1 -1.39 9.21zm-50.15-12.47h34.89q-1.73-15.58-17.24-15.59-14.2 0-17.65 15.59z"/></svg>
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 506.94 131.5"><path d="m109.65 58.21-18.21-10.07-15.37 9.38-.19 9.59-7.47-4.92-10.16 6.19-.44-10.48-10.48-7 10-5.17c-.08 0 0 1-1.48-34.34l-23.65-11.39-32.2 10 7.19 34.63 10.81 8.37-8.22 3.9 5.37 26.1 7.55 7.09-5.4 3.29 4.19 20.18 16.94 17.94c.08-.1 1.78-1.41 21.79-17.32l-.58-13.71 8.58 7.28c.12-.12 1.84-1.39 17.56-13.89l.61-10.14 6.48 4.5c.13-.12 1.58-1.22 14.26-11.33z" fill="#231f20"/><path d="m94.54 69 15.11-10.79-18.21-10.07-15.37 9.38z"/><path d="m92.87 88.2 1.67-19.2-18.47-11.48-.38 18.75z" fill="#004b16"/><path d="m68.22 107.73v-19.89l-18.66-14.15 1.47 19.54z" fill="#004b16"/><path d="m68.22 87.84 18.74-13.43-18.55-12.22-18.85 11.5z"/><path d="m38.43 131.48-2.98-20.32-18.15-17.8 4.19 20.18z" fill="#004b16"/><path d="m35.45 111.16 23.91-17.06-18.53-15.09-23.53 14.35z"/><path d="m33.9 100.6-3.94-26.88-20.22-16.81 5.41 26.07z" fill="#004b16"/><path d="m29.96 73.72 27.85-15.82-20.8-13.94-27.27 12.95z"/><path d="m28.07 60.88-5.4-36.81-22.67-14.06 7.19 34.62z" fill="#004b16"/><path d="m22.67 24.07 33.14-12.7-23.61-11.37-32.2 10.01z"/><g fill="#1cb35c"><path d="m107.13 76.87c-14.02 11.13-14.33 11.33-14.26 11.33 1.74-20.1 1.59-19.2 1.67-19.2 16-11.45 15-10.79 15.11-10.79z"/><path d="m85.78 93.84c-17.35 13.8-17.63 13.89-17.56 13.89-.17-20.82-.07-19.89 0-19.89 20-14.3 18.67-13.43 18.74-13.43z"/><path d="m60.22 114.16c-21.66 17.22-21.86 17.32-21.79 17.32-3.07-20.94-3-20.32-3-20.32 25.47-18.16 23.86-17.06 23.93-17.06z"/><path d="m55.81 11.37c1.52 35.37 1.4 34.34 1.48 34.34-28.66 14.89-29.29 15.17-29.22 15.17-5.52-37.63-5.47-36.81-5.4-36.81z"/><path d="m57.81 57.9c1.15 26.81 1 25.88 1.11 25.88-24.81 16.67-25.09 16.82-25 16.82-4-27.58-4-26.88-3.94-26.88z"/></g><path xmlns="http://www.w3.org/2000/svg" d="m151.61 14.24 16.58-4v79.88q0 13.13 7.83 15.65-3.84 7.31-13.13 7.3-11.28 0-11.28-15.66z"/><path d="m186.66 111.72v-57.42h-9.08v-13.6h25.86v71zm8.56-98.54a9.62 9.62 0 1 1 -9.62 9.62 9.63 9.63 0 0 1 9.62-9.62z"/><path d="m262.94 111.74v-41.06c0-6.05-1.16-10.48-3.48-13.26s-6.11-4.18-11.37-4.18a17.74 17.74 0 0 0 -7.8 2.06 18 18 0 0 0 -6.46 5.1v51.34h-16.59v-71h11.94l3 6.64q6.76-8 20-8 12.66 0 20 7.59t7.33 21.19v43.58z"/><path d="m288.42 76.06q0-16.26 9.38-26.47t24.77-10.21q16.19 0 25.14 9.82t9 26.86q0 17-9.12 27t-25 10q-16.18 0-25.17-10.12t-9-26.88zm17.24 0q0 23.47 16.91 23.48a14.54 14.54 0 0 0 12.31-6.11q4.55-6.09 4.54-17.37 0-23.14-16.85-23.15a14.61 14.61 0 0 0 -12.33 6.09q-4.58 6.11-4.58 17.06z"/><path d="m412.37 111.74v-4.31c-1.37 1.5-3.71 2.82-7 3.95a31.33 31.33 0 0 1 -10.15 1.69q-14.87 0-23.38-9.42t-8.52-26.27q0-16.84 9.78-27.42a32 32 0 0 1 24.51-10.58 32.37 32.37 0 0 1 14.72 3.32v-28.46l16.58-4v101.5zm0-54.06a17.6 17.6 0 0 0 -11.07-4.24q-10 0-15.33 6.07t-5.37 17.41q0 22.15 21.36 22.15a16.11 16.11 0 0 0 5.87-1.42c2.32-1 3.83-1.92 4.54-2.89z"/><path d="m505.55 81.3h-50.74q.46 8.49 5.83 13.2t14.46 4.7q11.34 0 17.25-5.9l6.43 12.7q-8.75 7.09-26.13 7.1-16.25 0-25.7-9.52t-9.45-26.58q0-16.78 10.38-27.2a33.91 33.91 0 0 1 24.9-10.41q15.45 0 24.81 9.22t9.35 23.48a46.28 46.28 0 0 1 -1.39 9.21zm-50.15-12.47h34.89q-1.73-15.58-17.24-15.59-14.2 0-17.65 15.59z"/></svg>

install.sh

@@ -1,144 +0,0 @@
-#!/usr/bin/env sh
-set -eu
-
-# Links to scripts/configs
-bin="https://github.com/simplex-chat/simplexmq/releases/latest/download"
-bin_smp="$bin/smp-server-ubuntu-20_04-x86-64"
-bin_xftp="$bin/xftp-server-ubuntu-20_04-x86-64"
-
-scripts="https://raw.githubusercontent.com/simplex-chat/simplexmq/stable/scripts/main"
-scripts_systemd_smp="$scripts/smp-server.service"
-scripts_systemd_xftp="$scripts/xftp-server.service"
-scripts_update="$scripts/simplex-servers-update"
-scripts_uninstall="$scripts/simplex-servers-uninstall"
-scripts_stopscript="$scripts/simplex-servers-stopscript"
-
-# Default installation paths
-path_bin="/usr/local/bin"
-path_bin_smp="$path_bin/smp-server"
-path_bin_xftp="$path_bin/xftp-server"
-path_bin_update="$path_bin/simplex-servers-update"
-path_bin_uninstall="$path_bin/simplex-servers-uninstall"
-path_bin_stopscript="$path_bin/simplex-servers-stopscript"
-
-path_conf_etc="/etc/opt"
-path_conf_var="/var/opt"
-path_conf_smp="$path_conf_etc/simplex $path_conf_var/simplex"
-path_conf_xftp="$path_conf_etc/simplex-xftp $path_conf_var/simplex-xftp /srv/xftp"
-
-path_systemd="/etc/systemd/system"
-path_systemd_smp="$path_systemd/smp-server.service"
-path_systemd_xftp="$path_systemd/xftp-server.service"
-
-# Defaut users
-user_smp="smp"
-user_xftp="xftp"
-
-GRN='\033[0;32m'
-BLU='\033[1;34m'
-YLW='\033[1;33m'
-RED='\033[0;31m'
-NC='\033[0m'
-
-logo='
- ____  _                 _     __  __
-/ ___|(_)_ __ ___  _ __ | | ___\ \/ /
-\___ \| | '"'"'_ ` _ \| '"'"'_ \| |/ _ \\  / 
- ___) | | | | | | | |_) | |  __//  \ 
-|____/|_|_| |_| |_| .__/|_|\___/_/\_\
-                  |_|                            
-'
-
-welcome="Welcome to SMP/XFTP installation script! Here's what we're going to do:
-${GRN}1.${NC} Install latest binaries from GitHub releases:
-    - smp: ${YLW}${path_bin_smp}${NC}
-    - xftp: ${YLW}${path_bin_xftp}${NC}
-${GRN}2.${NC} Create server directories:
-    - smp: ${YLW}${path_conf_smp}${NC}
-    - xftp: ${YLW}${path_conf_xftp}${NC}
-${GRN}3.${NC} Setup user for each server:
-    - xmp: ${YLW}${user_smp}${NC}
-    - xftp: ${YLW}${user_xftp}${NC}
-${GRN}4.${NC} Create systemd services:
-    - smp: ${YLW}${path_systemd_smp}${NC}
-    - xftp: ${YLW}${path_systemd_xftp}${NC}
-${GRN}5.${NC} Install stopscript (systemd), update and uninstallation script:
-    - all: ${YLW}${path_bin_update}${NC}, ${YLW}${path_bin_uninstall}${NC}, ${YLW}${path_bin_stopscript}${NC}
-
-Press ${GRN}ENTER${NC} to continue or ${RED}Ctrl+C${NC} to cancel installation"
-
-end="Installtion is complete!
-
-Please checkout our server guides:
-- smp: ${GRN}https://simplex.chat/docs/server.html${NC}
-- xftp: ${GRN}https://simplex.chat/docs/xftp-server.html${NC}
-
-To uninstall with full clean-up, simply run: ${YLW}sudo /usr/local/bin/simplex-servers-uninstall${NC}
-"
-
-setup_bins() {
- curl --proto '=https' --tlsv1.2 -sSf -L "$bin_smp" -o "$path_bin_smp" && chmod +x "$path_bin_smp"
- curl --proto '=https' --tlsv1.2 -sSf -L "$bin_xftp" -o "$path_bin_xftp" && chmod +x "$path_bin_xftp"
-}
-
-setup_users() {
- useradd -M "$user_smp" 2> /dev/null || true
- useradd -M "$user_xftp" 2> /dev/null || true
-}
-
-setup_dirs() {
- # Unquoted varibles, so field splitting can occur
- mkdir -p $path_conf_smp
- chown "$user_smp":"$user_smp" $path_conf_smp
- mkdir -p $path_conf_xftp
- chown "$user_xftp":"$user_xftp" $path_conf_xftp
-}
-
-setup_systemd() {
- curl --proto '=https' --tlsv1.2 -sSf -L "$scripts_systemd_smp" -o "$path_systemd_smp"
- curl --proto '=https' --tlsv1.2 -sSf -L "$scripts_systemd_xftp" -o "$path_systemd_xftp"
-}
-
-setup_scripts() {
- curl --proto '=https' --tlsv1.2 -sSf -L "$scripts_update" -o "$path_bin_update" && chmod +x "$path_bin_update"
- curl --proto '=https' --tlsv1.2 -sSf -L "$scripts_uninstall" -o "$path_bin_uninstall" && chmod +x "$path_bin_uninstall"
- curl --proto '=https' --tlsv1.2 -sSf -L "$scripts_stopscript" -o "$path_bin_stopscript" && chmod +x "$path_bin_stopscript"
- }
-
-checks() {
- if [ "$(id -u)" -ne 0 ]; then
-  printf "This script is intended to be run with root privileges. Please re-run script using sudo."
-  exit 1
- fi
-}
-
-main() {
- checks
- 
- printf "%b\n%b\n" "${BLU}$logo${NC}" "$welcome"
- read ans
-
- printf "Installing binaries..."
- setup_bins
- printf "${GRN} Done!${NC}\n"
-
- printf "Creating users..."
- setup_users
- printf "${GRN} Done!${NC}\n"
- 
- printf "Creating directories..."
- setup_dirs
- printf "${GRN} Done!${NC}\n"
-
- printf "Creating systemd services..."
- setup_systemd
- printf "${GRN} Done!${NC}\n"
-
- printf "Installing stopscript, update and uninstallation script..."
- setup_scripts
- printf "${GRN} Done!${NC}\n"
-
- printf "%b" "$end"
-}
-
-main

notes-flow.txt

@@ -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

package.yaml

@@ -1,7 +1,7 @@
 name: simplexmq
-version: 5.8.0.10
+version: 1.0.3
 synopsis: SimpleXMQ message broker
-description: |
+description:  |
   This package includes <./docs/Simplex-Messaging-Server.html server>,
   <./docs/Simplex-Messaging-Client.html client> and
   <./docs/Simplex-Messaging-Agent.html agent> for SMP protocols:
@@ -20,132 +20,64 @@ category: Chat, Network, Web, System, Cryptography
 extra-source-files:
   - README.md
   - CHANGELOG.md
-  - cbits/sha512.h
-  - cbits/sntrup761.h
-  - apps/smp-server/static/*.html
-  - apps/smp-server/static/media/*
 
 dependencies:
-  - aeson == 2.2.*
+  - aeson == 2.0.*
   - ansi-terminal >= 0.10 && < 0.12
   - asn1-encoding == 0.9.*
   - asn1-types == 0.3.*
   - async == 2.2.*
   - attoparsec == 0.14.*
-  - base >= 4.14 && < 5
+  - base >= 4.7 && < 5
   - base64-bytestring >= 1.0 && < 1.3
-  - case-insensitive == 1.2.*
+  - bytestring == 0.10.*
   - composition == 1.0.*
   - constraints >= 0.12 && < 0.14
   - containers == 0.6.*
-  - crypton == 0.34.*
-  - crypton-x509 == 1.7.*
-  - crypton-x509-store == 1.6.*
-  - crypton-x509-validation == 1.6.*
-  - cryptostore == 0.3.*
+  - cryptonite >= 0.27 && < 0.30
+  - cryptostore == 0.2.*
   - data-default == 0.7.*
-  - direct-sqlcipher == 2.3.*
+  - direct-sqlite == 2.3.*
   - directory == 1.3.*
   - filepath == 1.4.*
-  - hourglass == 0.2.*
   - http-types == 0.12.*
-  - http2 >= 4.2.2 && < 4.3
-  - ini == 0.4.1
-  - iproute == 1.7.*
+  - generic-random >= 1.3 && < 1.5
   - iso8601-time == 0.1.*
-  - memory == 0.18.*
-  - mtl >= 2.3.1 && < 3.0
-  - network >= 3.1.2.7 && < 3.2
-  - network-info >= 0.2 && < 0.3
-  - network-transport == 0.5.6
-  - network-udp >= 0.0 && < 0.1
-  - optparse-applicative >= 0.15 && < 0.17
-  - process == 1.6.*
+  - memory == 0.15.*
+  - mtl == 2.2.*
+  - network == 3.1.*
+  - network-transport == 0.5.*
+  - QuickCheck == 2.14.*
   - random >= 1.1 && < 1.3
   - simple-logger == 0.1.*
-  - socks == 0.6.*
-  - sqlcipher-simple == 0.4.*
+  - sqlite-simple == 0.4.*
   - stm == 2.5.*
-  - temporary == 1.3.*
-  - time == 1.12.*
-  - time-manager == 0.0.*
-  - tls >= 1.7.0 && < 1.8
-  - transformers == 0.6.*
+  - template-haskell == 2.16.*
+  - text == 1.2.*
+  - time == 1.9.*
+  - tls >= 1.5.7 && < 1.6
+  - transformers == 0.5.*
   - unliftio == 0.2.*
   - unliftio-core == 0.2.*
   - websockets == 0.12.*
-  - yaml == 0.11.*
-  - zstd == 0.1.3.*
-
-flags:
-  swift:
-    description: Enable swift JSON format
-    manual: True
-    default: False
-  use_crypton:
-    description: Use crypton etc. in cryptostore
-    manual: True
-    default: True
-
-# cpp-options:
-#   - -Dslow_servers
-
-when:
-  - condition: flag(swift)
-    cpp-options:
-      - -DswiftJSON
-  - condition: impl(ghc >= 9.6.2)
-    dependencies:
-      - bytestring == 0.11.*
-      - template-haskell == 2.20.*
-      - text >= 2.0.1 && < 2.2
-  - condition: impl(ghc < 9.6.2)
-    dependencies:
-      - bytestring == 0.10.*
-      - template-haskell == 2.16.*
-      - text >= 1.2.3.0 && < 1.3
+  - x509 == 1.7.*
+  - x509-store == 1.6.*
+  - x509-validation == 1.6.*
 
 library:
   source-dirs: src
-  c-sources:
-    - cbits/sha512.c
-    - cbits/sntrup761.c
-  include-dirs: cbits
-  extra-libraries: crypto
 
 executables:
   smp-server:
-    source-dirs:
-    - apps/smp-server
-    - apps/smp-server/web
-    main: Main.hs
-    dependencies:
-      - file-embed
-      - simplexmq
-      - wai-app-static
-      - warp
-      - warp-tls
-    ghc-options:
-      - -threaded
-      - -rtsopts
-
-  ntf-server:
-    source-dirs: apps/ntf-server
+    source-dirs: apps/smp-server
     main: Main.hs
     dependencies:
+      - ini == 0.4.*
+      - optparse-applicative >= 0.15 && < 0.17
+      - process == 1.6.*
       - simplexmq
     ghc-options:
       - -threaded
-      - -rtsopts
-
-  xftp-server:
-    source-dirs: apps/xftp-server
-    main: Main.hs
-    dependencies:
-      - simplexmq
-    ghc-options:
-      - -threaded
-      - -rtsopts
 
   smp-agent:
     source-dirs: apps/smp-agent
@@ -154,67 +86,25 @@ executables:
       - simplexmq
     ghc-options:
       - -threaded
-      - -rtsopts
-
-  xftp:
-    source-dirs: apps/xftp
-    main: Main.hs
-    dependencies:
-      - simplexmq
-    ghc-options:
-      - -threaded
-      - -rtsopts
 
 tests:
-  simplexmq-test:
+  smp-server-test:
     source-dirs: tests
     main: Test.hs
     dependencies:
       - simplexmq
-      - deepseq == 1.4.*
-      - generic-random == 1.5.*
-      - hspec == 2.11.*
-      - hspec-core == 2.11.*
+      - hspec == 2.7.*
+      - hspec-core == 2.7.*
       - HUnit == 1.6.*
       - QuickCheck == 2.14.*
-      - silently == 1.2.*
-      - main-tester == 0.2.*
       - timeit == 2.0.*
-    ghc-options:
-      - -threaded
-      - -rtsopts
-      - -with-rtsopts=-A64M
-      - -with-rtsopts=-N1
 
 ghc-options:
   # - -haddock
-  - -Weverything
-  - -Wno-missing-exported-signatures
-  - -Wno-missing-import-lists
-  - -Wno-missed-specialisations
-  - -Wno-all-missed-specialisations
-  - -Wno-unsafe
-  - -Wno-safe
-  - -Wno-missing-local-signatures
-  - -Wno-missing-kind-signatures
-  - -Wno-missing-deriving-strategies
-  - -Wno-monomorphism-restriction
-  - -Wno-prepositive-qualified-module
-  - -Wno-unused-packages
-  - -Wno-implicit-prelude
-  - -Wno-missing-safe-haskell-mode
-  - -Wno-missing-export-lists
-  - -Wno-partial-fields
+  - -Wall
   - -Wcompat
-  - -Werror=incomplete-record-updates
   - -Werror=incomplete-patterns
-  - -Werror=incomplete-uni-patterns
-  - -Werror=missing-methods
-  - -Werror=tabs
   - -Wredundant-constraints
   - -Wincomplete-record-updates
+  - -Wincomplete-uni-patterns
   - -Wunused-type-patterns
-  - -O2
-
-default-extensions:
-  - StrictData

protocol/diagrams/duplex-messaging/duplex-creating-v2.mmd

@@ -1,71 +0,0 @@
-sequenceDiagram
-  participant A as Alice
-  participant AA as Alice's<br>agent
-  participant AS as Alice's<br>server
-  participant BS as Bob's<br>server
-  participant BA as Bob's<br>agent
-  participant B as Bob
-
-  note over AA, BA: status (receive/send): NONE/NONE
-
-  note over A, AA: 1. request connection<br>from agent
-  A ->> AA: NEW: create<br>duplex connection
- 
-  note over AA, AS: 2. create Alice's SMP queue
-  AA ->> AS: NEW: create SMP queue
-  AS ->> AA: IDS: SMP queue IDs
-  note over AA: status: NEW/NONE
-
-  AA ->> A: INV: invitation<br>to connect
-
-  note over A, B: 3. out-of-band invitation
-  A ->> B: OOB: invitation to connect
-
-  note over BA, B: 4. accept connection
-  B ->> BA: JOIN:<br>via invitation info
-  note over BA: status: NONE/NEW
-
-  note over BA, BS: 5. create Bob's SMP queue
-  BA ->> BS: NEW: create SMP queue
-  BS ->> BA: IDS: SMP queue IDs
-  note over BA: status: NEW/NEW
-
-  note over BA, AA: 6. establish Alice's SMP queue
-  BA ->> AS: SEND: Bob's info and sender server key (SMP confirmation with reply queues)
-  note over BA: status: NEW/CONFIRMED
-
-  AS ->> AA: MSG: Bob's info and<br>sender server key
-  note over AA: status: CONFIRMED/NONE
-  AA ->> AS: ACK: confirm message
-  AA ->> A: CONF: connection request ID<br>and Bob's info
-  A ->> AA: LET: accept connection request,<br>send Alice's info
-  AA ->> AS: KEY: secure queue
-  note over AA: status: SECURED/NONE
-
-  AA ->> BS: SEND: Alice's info and sender's server key (SMP confirmation without reply queues)
-  note over AA: status: SECURED/CONFIRMED
-
-  BS ->> BA: MSG: Alice's info and<br>sender's server key
-  note over BA: status: CONFIRMED/CONFIRMED
-  BA ->> B: INFO: Alice's info
-  BA ->> BS: ACK: confirm message
-  BA ->> BS: KEY: secure queue
-  note over BA: status: SECURED/CONFIRMED
-
-  BA ->> AS: SEND: HELLO: only needs to be sent once in v2
-
-  note over BA: status: SECURED/ACTIVE
-  note over BA, B: 7a. notify Bob<br>about connection success
-  BA ->> B: CON: connected
-
-  AS ->> AA: MSG: HELLO: Alice's agent<br>knows Bob can send
-  note over AA: status: SECURED/ACTIVE
-  AA ->> AS: ACK: confirm message
-  note over A, AA: 7a. notify Alice<br>about connection success
-  AA ->> A: CON: connected
-
-  AA ->> BS: SEND: HELLO: only needs to be sent once in v2
-  note over AA: status: ACTIVE/ACTIVE
-  BS ->> BA: MSG: HELLO: Bob's agent<br>knows Alice can send
-  note over BA: status: ACTIVE/ACTIVE
-  BA ->> BS: ACK: confirm message

protocol/diagrams/duplex-messaging/duplex-creating.mmd

@@ -33,8 +33,8 @@ sequenceDiagram
   AS ->> AA: MSG: Bob's info and<br>sender server key
   note over AA: status: CONFIRMED/NONE
   AA ->> AS: ACK: confirm message
-  AA ->> A: CONF: connection request ID<br>and Bob's info
-  A ->> AA: LET: accept connection request,<br>send Alice's info
+  AA ->> A: REQ: connection request ID<br>and Bob's info
+  A ->> AA: ACPT: accept connection request,<br>send Alice's info
   AA ->> AS: KEY: secure queue
   note over AA: status: SECURED/NONE
 

protocol/diagrams/notifications/register-token.mmd

@@ -1,30 +0,0 @@
-sequenceDiagram
-  participant M as mobile app
-  participant C as chat core
-  participant A as agent
-  participant P as push server
-  participant APN as APN
-
-  note over M, APN: get device token
-  M ->> APN: registerForRemoteNotifications()
-  APN ->> M: device token
-
-  note over M, P: register device token with push server
-  M ->> C: /_ntf register <token>
-  C ->> A: registerNtfToken(<token>)
-  A ->> P: TNEW
-  P ->> A: ID (tokenId)
-  A ->> C: registered
-  C ->> M: registered
-
-  note over M, APN: verify device token
-  P ->> APN: E2E encrypted code<br>in background<br>notification
-  APN ->> M: deliver background notification with e2ee verification token
-  M ->> C: /_ntf verify <e2ee code>
-  C ->> A: verifyNtfToken(<e2ee code>)
-  A ->> P: TVFY code
-  P ->> A: OK / ERR
-  A ->> C: verified
-  C ->> M: verified
-
-  note over M, APN: now token ID can be used

protocol/diagrams/notifications/subscription.mmd

@@ -1,40 +0,0 @@
-sequenceDiagram
-  participant M as mobile app
-  participant C as chat core
-  participant A as agent
-  participant S as SMP server
-  participant N as NTF server
-  participant APN as APN
-
-  note over M, APN: register subscription
-
-  alt register existing
-    M -->> A: on /_ntf register, for subscribed queues
-  else create new connection
-    A -->> S: NEW / JOIN
-    note over A, S: ...<br>Connection handshake<br>...
-    S -->> A: CON
-  end
-  A ->> S: NKEY nKey
-  S ->> A: NID nId
-  A ->> N: SNEW tknId dhKey (smpServer, nId, nKey)
-  N ->> A: ID subId dhKey
-  N ->> S: NSUB nId
-  S ->> N: OK [/ NMSG]
-
-  note over M, APN: notify about message
-
-  S ->> N: NMSG
-  N ->> APN: APNSMutableContent<br>ntfQueue, nonce
-  APN ->> M: UNMutableNotificationContent
-  note over M, S: ...<br>Client awaken, message is received<br>...
-  S ->> M: message
-  note over M: mutate notification
-
-  note over M, APN: change APN token
-
-  APN ->> M: new device token
-  M -->> C: /_ntf_sub update tkn
-  C -->> A: updateNtfToken()
-  A -->> N: TUPD tknId newDeviceToken
-  note over M, N: ...<br>Verify token<br>...

protocol/simplex-messaging.md

@@ -24,7 +24,6 @@
     - [Subscribe to queue](#subscribe-to-queue)
     - [Secure queue command](#secure-queue-command)
     - [Enable notifications command](#enable-notifications-command)
-    - [Disable notifications command](#disable-notifications-command)
     - [Acknowledge message delivery](#acknowledge-message-delivery)
     - [Suspend queue](#suspend-queue)
     - [Delete queue](#delete-queue)
@@ -51,8 +50,6 @@ It's designed with the focus on communication security and integrity, under the
 
 It is designed as a low level protocol for other application protocols to solve the problem of secure and private message transmission, making [MITM attack][1] very difficult at any part of the message transmission system.
 
-This document describes SMP protocol versions 3 and 4, the previous versions are discontinued.
-
 ## Introduction
 
 The objective of Simplex Messaging Protocol (SMP) is to facilitate the secure and private unidirectional transfer of messages from senders to recipients via persistent simplex queues managed by the message broker (server).
@@ -149,61 +146,61 @@ To create and start using a simplex queue Alice and Bob follow these steps:
 
 1. Alice creates a simplex queue on the server:
 
-   1. Decides which SMP server to use (can be the same or different server that Alice uses for other queues) and opens secure encrypted transport connection to the chosen SMP server (see [Appendix A](#appendix-a)).
+    1. Decides which SMP server to use (can be the same or different server that Alice uses for other queues) and opens secure encrypted transport connection to the chosen SMP server (see [Appendix A](#appendix-a)).
 
-   2. Generates a new random public/private key pair (encryption key - `EK`) that she did not use before for Bob to encrypt the messages.
+    2. Generates a new random public/private key pair (encryption key - `EK`) that she did not use before for Bob to encrypt the messages.
 
-   3. Generates another new random public/private key pair (recipient key - `RK`) that she did not use before for her to sign commands and to decrypt the transmissions received from the server.
+    3. Generates another new random public/private key pair (recipient key - `RK`) that she did not use before for her to sign commands and to decrypt the transmissions received from the server.
 
-   4. Generates one more random key pair (recipient DH key - `RDHK`) to negotiate symmetric key that will be used by the server to encrypt message bodies delivered to Alice (to avoid shared cipher-text inside transport connection).
+    4. Generates one more random key pair (recipient DH key - `RDHK`) to negotiate symmetric key that will be used by the server to encrypt message bodies delivered to Alice (to avoid shared cipher-text inside transport connection).
 
-   5. Sends `"NEW"` command to the server to create a simplex queue (see `create` in [Create queue command](#create-queue-command)). This command contains previously generated unique "public" keys `RK` and `RDHK`. `RK` will be used to verify the following commands related to the same queue signed by its private counterpart, for example to subscribe to the messages received to this queue or to update the queue, e.g. by setting the key required to send the messages (initially Alice creates the queue that accepts unsigned messages, so anybody could send the message via this queue if they knew the queue sender's ID and server address).
+    5. Sends `"NEW"` command to the server to create a simplex queue (see `create` in [Create queue command](#create-queue-command)). This command contains previously generated unique "public" keys `RK` and `RDHK`. `RK` will be used to verify the following commands related to the same queue signed by its private counterpart, for example to subscribe to the messages received to this queue or to update the queue, e.g. by setting the key required to send the messages (initially Alice creates the queue that accepts unsigned messages, so anybody could send the message via this queue if they knew the queue sender's ID and server address).
 
-   6. The server sends `"IDS"` response with queue IDs (`queueIds`):
+    6. The server sends `"IDS"` response with queue IDs (`queueIds`):
 
-      - Recipient ID `RID` for Alice to manage the queue and to receive the messages.
+        - Recipient ID `RID` for Alice to manage the queue and to receive the messages.
 
-      - Sender ID `SID` for Bob to send messages to the queue.
+        - Sender ID `SID` for Bob to send messages to the queue.
 
-      - Server public DH key (`SDHK`) to negotiate a shared secret for message body encryption, that Alice uses to derive a shared secret with the server `SS`.
+        - Server public DH key (`SDHK`) to negotiate a shared secret for message body encryption, that Alice uses to derive a shared secret with the server `SS`.
 
 2. Alice sends an out-of-band message to Bob via the alternative channel that both Alice and Bob trust (see [protocol abstract](#simplex-messaging-protocol-abstract)). The message must include:
 
-   - Unique "public" key (`EK`) that Bob must use for E2E key agreement.
+    - Unique "public" key (`EK`) that Bob must use for E2E key agreement.
 
-   - SMP server hostname and information to open secure encrypted transport connection (see [Appendix A](#appendix-a)).
+    - SMP server hostname and information to open secure encrypted transport connection (see [Appendix A](#appendix-a)).
 
-   - Sender queue ID `SID` for Bob to use.
+    - Sender queue ID `SID` for Bob to use.
 
 3. Bob, having received the out-of-band message from Alice, connects to the queue:
 
-   1. Generates a new random public/private key pair (sender key - `SK`) that he did not use before for him to sign messages sent to Alice's server.
+    1. Generates a new random public/private key pair (sender key - `SK`) that he did not use before for him to sign messages sent to Alice's server.
 
-   2. Prepares the confirmation message for Alice to secure the queue. This message includes:
+    2. Prepares the confirmation message for Alice to secure the queue. This message includes:
 
-      - Previously generated "public" key `SK` that will be used by Alice's server to authenticate Bob's messages, once the queue is secured.
+        - Previously generated "public" key `SK` that will be used by Alice's server to authenticate Bob's messages, once the queue is secured.
 
-      - Optionally, any additional information (application specific, e.g. Bob's profile name and details).
+        - Optionally, any additional information (application specific, e.g. Bob's profile name and details).
 
-   3. Encrypts the confirmation body with the "public" key `EK` (that Alice provided via the out-of-band message).
+    3. Encrypts the confirmation body with the "public" key `EK` (that Alice provided via the out-of-band message).
 
-   4. Sends the encrypted message to the server with queue ID `SID` (see `send` in [Send message](#send-message)). This initial message to the queue must not be signed - signed messages will be rejected until Alice secures the queue (below).
+    4. Sends the encrypted message to the server with queue ID `SID` (see `send` in [Send message](#send-message)). This initial message to the queue must not be signed - signed messages will be rejected until Alice secures the queue (below).
 
 4. Alice receives Bob's message from the server using recipient queue ID `RID` (possibly, via the same transport connection she already has opened - see `message` in [Deliver queue message](#deliver-queue-message)):
 
-   1. She decrypts received message body using the secret `SS`.
+    1. She decrypts received message body using the secret `SS`.
 
-   2. She decrypts received message with [key agreed with sender using] "private" key `EK`.
+    2. She decrypts received message with [key agreed with sender using] "private" key `EK`.
 
-   3. Even though anybody could have sent the message to the queue with ID `SID` before it is secured (e.g. if communication is compromised), Alice would ignore all messages until the decryption succeeds (i.e. the result contains the expected message format). Optionally, in the client application, she also may identify Bob using the information provided, but it is out of scope of SMP protocol.
+    3. Even though anybody could have sent the message to the queue with ID `SID` before it is secured (e.g. if communication is compromised), Alice would ignore all messages until the decryption succeeds (i.e. the result contains the expected message format). Optionally, in the client application, she also may identify Bob using the information provided, but it is out of scope of SMP protocol.
 
 5. Alice secures the queue `RID` with `"KEY"` command so only Bob can send messages to it (see [Secure queue command](#secure-queue-command)):
 
-   1. She sends the `KEY` command with `RID` signed with "private" key `RK` to update the queue to only accept requests signed by "private" key `SK` provided by Bob. This command contains unique "public" key `SK` previously generated by Bob.
+    1. She sends the `KEY` command with `RID` signed with "private" key `RK` to update the queue to only accept requests signed by "private" key `SK` provided by Bob. This command contains unique "public" key `SK` previously generated by Bob.
 
-   2. From this moment the server will accept only signed commands to `SID`, so only Bob will be able to send messages to the queue `SID` (corresponding to `RID` that Alice has).
+    2. From this moment the server will accept only signed commands to `SID`, so only Bob will be able to send messages to the queue `SID` (corresponding to `RID` that Alice has).
 
-   3. Once queue is secured, Alice deletes `SID` and `SK` - even if Alice's client is compromised in the future, the attacker would not be able to send messages pretending to be Bob.
+    3. Once queue is secured, Alice deletes `SID` and `SK` - even if Alice's client is compromised in the future, the attacker would not be able to send messages pretending to be Bob.
 
 6. The simplex queue `RID` is now ready to be used.
 
@@ -217,21 +214,21 @@ Bob now can securely send messages to Alice:
 
 1. Bob sends the message:
 
-   1. He encrypts the message to Alice with "public" key `EK` (provided by Alice, only known to Bob, used only for one simplex queue).
+    1. He encrypts the message to Alice with "public" key `EK` (provided by Alice, only known to Bob, used only for one simplex queue).
 
-   2. He signs `"SEND"` command to the server queue `SID` using the "private" key `SK` (that only he knows, used only for this queue).
+    2. He signs `"SEND"` command to the server queue `SID` using the "private" key `SK` (that only he knows, used only for this queue).
 
-   3. He sends the command to the server (see `send` in [Send message](#send-message)), that the server will authenticate using the "public" key `SK` (that Alice earlier received from Bob and provided to the server via `"KEY"` command).
+    3. He sends the command to the server (see `send` in [Send message](#send-message)), that the server will authenticate using the "public" key `SK` (that Alice earlier received from Bob and provided to the server via `"KEY"` command).
 
 2. Alice receives the message(s):
 
-   1. She signs `"SUB"` command to the server to subscribe to the queue `RID` with the "private" key `RK` (see `subscribe` in [Subscribe to queue](#subscribe-to-queue)).
+    1. She signs `"SUB"` command to the server to subscribe to the queue `RID` with the "private" key `RK` (see `subscribe` in [Subscribe to queue](#subscribe-to-queue)).
 
-   2. The server, having authenticated Alice's command with the "public" key `RK` that she provided, delivers Bob's message(s) (see `message` in [Deliver queue message](#deliver-queue-message)).
+    2. The server, having authenticated Alice's command with the "public" key `RK` that she provided, delivers Bob's message(s) (see `message` in [Deliver queue message](#deliver-queue-message)).
 
-   3. She decrypts Bob's message(s) with the "private" key `EK` (that only she has).
+    3. She decrypts Bob's message(s) with the "private" key `EK` (that only she has).
 
-   4. She acknowledges the message reception to the server with `"ACK"` so that the server can delete the message and deliver the next messages.
+    4. She acknowledges the message reception to the server with `"ACK"` so that the server can delete the message and deliver the next messages.
 
 This flow is show on sequence diagram below.
 
@@ -347,7 +344,7 @@ Simplex messaging server implementations MUST NOT create, store or send to any o
 
 - Snapshots of the database they use to store queues and messages (instead simplex messaging clients must manage redundancy by using more than one simplex messaging server). In-memory persistence is recommended.
 
-- Any other information that may compromise privacy or [forward secrecy][4] of communication between clients using simplex messaging servers (the servers cannot compromise forward secrecy of any application layer protocol, such as double ratchet).
+- Any other information that may compromise privacy or [forward secrecy][4] of communication between clients using simplex messaging servers.
 
 ## Message delivery notifications
 
@@ -358,22 +355,18 @@ To protect the privacy of the recipients, there are several commands in SMP prot
 The clients can optionally instruct a dedicated push notification server to subscribe to notifications and deliver push notifications to the device, which can then retrieve the messages in the background and send local notifications to the user - this is out of scope of SMP protocol. The commands that SMP protocol provides to allow it:
 
 - `enableNotifications` (`"NKEY"`) with `notifierId` (`"NID"`) response - see [Enable notifications command](#enable-notifications-command).
-- `disableNotifications` (`"NDEL"`) - see [Disable notifications command](#disable-notifications-command).
 - `subscribeNotifications` (`"NSUB"`) - see [Subscribe to queue notifications](#subscribe-to-queue-notifications).
 - `messageNotification` (`"NMSG"`) - see [Deliver message notification](#deliver-message-notification).
 
-[`SEND` command](#send-message) includes the notification flag to instruct SMP server whether to send the notification - this flag is forwarded to the recepient inside encrypted envelope, together with the timestamp and the message body, so even if TLS is compromised this flag cannot be used for traffic correlation.
+## SMP Transmission structure
 
-## SMP Transmission and transport block structure
+Each transport block (SMP transmission) has a fixed size of 16384 bytes for traffic uniformity.
 
-Each transport block has a fixed size of 16384 bytes for traffic uniformity.
-
-From SMP version 4 each block can contain multiple transmissions, version 3 blocks have 1 transmission.
 Some parts of SMP transmission are padded to a fixed size; this padding is uniformly added as a word16 encoded in network byte order - see `paddedString` syntax.
 
 In places where some part of the transmission should be padded, the syntax for `paddedNotation` is used:
 
-```abnf
+```
 paddedString = originalLength string pad
 originalLength = 2*2 OCTET
 pad = N*N"#" ; where N = paddedLength - originalLength - 2
@@ -383,42 +376,32 @@ paddedNotation = <padded(string, paddedLength)>
 ; paddedLength - required length after padding, including 2 bytes for originalLength
 ```
 
-Each transmission/block for SMP v3 between the client and the server must have this format/syntax:
+Each transmission between the client and the server must have this format/syntax:
 
-```abnf
+```
 paddedTransmission = <padded(transmission), 16384>
-transmission = signature signed
-signed = sessionIdentifier corrId queueId smpCommand
+transmission = [signature] SP signed
+signed = sessionIdentifier SP [corrId] SP [queueId] SP smpCommand
 ; corrId is required in client commands and server responses,
 ; it is empty in server notifications.
-corrId = length *OCTET
-queueId = length *OCTET
+corrId = 1*32(%x21-7F) ; any characters other than control/whitespace
+queueId = encoded ; max 32 bytes when decoded (24 bytes is used),
 ; empty queue ID is used with "create" command and in some server responses
-signature = length *OCTET
+signature = encoded
 ; empty signature can be used with "send" before the queue is secured with secure command
 ; signature is always empty with "ping" and "serverMsg"
-length = 1*1 OCTET
+encoded = <base64 encoded binary>
 ```
 
 `base64` encoding should be used with padding, as defined in section 4 of [RFC 4648][9]
 
-Transport block for SMP v4 has this syntax:
-
-```abnf
-paddedTransportBlock = <padded(transportBlock), 16384>
-transportBlock = transmissionCount transmissions
-transmissionCount = 1*1 OCTET ; equal or greater than 1
-transmissions = transmissionLength transmission [transmissions]
-transmissionLength = 2*2 OCTET ; word16 encoded in network byte order
-```
-
 ## SMP commands
 
 Commands syntax below is provided using [ABNF][8] with [case-sensitive strings extension][8a].
 
 ```abnf
 smpCommand = ping / recipientCmd / send / subscribeNotifications / serverMsg
-recipientCmd = create / subscribe / secure / enableNotifications / disableNotifications /
+recipientCmd = create / subscribe / secure / enableNotifications /
                acknowledge / suspend / delete
 serverMsg = queueIds / message / notifierId / messageNotification /
             unsubscribed / ok / error
@@ -519,42 +502,22 @@ Once the queue is secured only signed messages can be sent to it.
 This command is sent by the recipient to the server to add notifier's key to the queue, to allow push notifications server to receive notifications when the message arrives, via a separate queue ID, without receiving message content.
 
 ```abnf
-enableNotifications = %s"NKEY " notifierKey recipientNotificationDhPublicKey
+enableNotifications = %s"NKEY " notifierKey
 notifierKey = length x509encoded
 ; the notifier's Ed25519 or Ed448 public key public key to verify NSUB command for this queue
-
-recipientNotificationDhPublicKey = length x509encoded
-; the recipient's Curve25519 key for DH exchange to derive the secret
-; that the server will use to encrypt notification metadata (encryptedNMsgMeta in NMSG)
-; using [NaCl crypto_box][16] encryption scheme (curve25519xsalsa20poly1305).
 ```
 
 The server will respond with `notifierId` response if notifications were enabled and the notifier's key was successfully added to the queue:
 
 ```abnf
-notifierId = %s"NID " notifierId srvNotificationDhPublicKey
+notifierId = %s"NID " notifierId
 notifierId = length *OCTET ; 16-24 bytes
-srvNotificationDhPublicKey = length x509encoded
-; the server's Curve25519 key for DH exchange to derive the secret
-; that the server will use to encrypt notification metadata to the recipient (encryptedNMsgMeta in NMSG)
 ```
 
 This response is sent with the recipient's queue ID (the third part of the transmission).
 
 To receive the message notifications, `subscribeNotifications` command ("NSUB") must be sent signed with the notifier's key.
 
-#### Disable notifications command
-
-This command is sent by the recipient to the server to remove notifier's credentials from the queue:
-
-```abnf
-disableNotifications = %s"NDEL"
-```
-
-The server must respond `ok` to this command if it was successful.
-
-Once notifier's credentials are removed server will no longer send "NMSG" for this queue to notifier.
-
 #### Acknowledge message delivery
 
 The recipient should send the acknowledgement of message delivery once the message was stored in the client, to notify the server that the message should be deleted:
@@ -602,9 +565,7 @@ Currently SMP defines only one command that can be used by senders - `send` mess
 This command is sent to the server by the sender both to confirm the queue after the sender received out-of-band message from the recipient and to send messages after the queue is secured:
 
 ```abnf
-send = %s"SEND " msgFlags SP smpEncMessage
-msgFlags = notificationFlag reserved
-notificationFlag = %s"T" / %s"F"
+send = %s"SEND " smpEncMessage
 smpEncMessage = smpPubHeader sentMsgBody ; message up to 16088 bytes
 smpPubHeader = smpClientVersion ("1" senderPublicDhKey / "0")
 smpClientVersion = word16
@@ -746,11 +707,9 @@ See its syntax in [Create queue command](#create-queue-command)
 The server must deliver messages to all subscribed simplex queues on the currently open transport connection. The syntax for the message delivery is:
 
 ```abnf
-message = %s"MSG " msgId encryptedRcvMsgBody
+message = %s"MSG " msgId SP timestamp SP encryptedMsgBody
 encryptedMsgBody = <encrypt paddedSentMsgBody> ; server-encrypted padded sent msgBody
 paddedSentMsgBody = <padded(sentMsgBody, maxMessageLength + 2)> ; maxMessageLength = 16088
-encryptedRcvMsgBody = <encrypt rcvMsgBody> ; server-encrypted meta-data and padded sent msgBody
-rcvMsgBody = timestamp msgFlags SP paddedSentMsgBody
 msgId = length 24*24OCTET
 timestamp = 8*8OCTET
 ```
@@ -776,19 +735,10 @@ See its syntax in [Enable notifications command](#enable-notifications-command)
 The server must deliver message notifications to all simplex queues that were subscribed with `subscribeNotifications` command ("NSUB") on the currently open transport connection. The syntax for the message notification delivery is:
 
 ```abnf
-messageNotification = %s"NMSG " nmsgNonce encryptedNMsgMeta
-
-encryptedNMsgMeta = <encrypted message metadata passed in notification>
-; metadata E2E encrypted between server and recipient containing server's message ID and timestamp (allows extension),
-; to be passed to the recipient by the notifier for them to decrypt
-; with key negotiated in NKEY and NID commands using nmsgNonce
-
-nmsgNonce = <nonce used in NaCl crypto_box encryption scheme>
-; nonce used by the server for encryption of message metadata, to be passed to the recipient by the notifier
-; for them to use in decryption of E2E encrypted metadata
+messageNotification = %s"NMSG"
 ```
 
-Message notification does not contain any message data or non E2E encrypted metadata.
+Message notification does not contain any message data or meta-data, it only notifies that the message is available.
 
 #### Subscription END notification
 
@@ -820,7 +770,7 @@ The syntax for error responses:
 ```abnf
 error = %s"ERR " errorType
 errorType = %s"BLOCK" / %s"SESSION" / %s"CMD " cmdError / %s"AUTH" / %s"LARGE_MSG" /%s"INTERNAL"
-cmdError = %s"SYNTAX" / %s"PROHIBITED" / %s"NO_AUTH" / %s"HAS_AUTH" / %s"NO_ENTITY"
+cmdError = %s"SYNTAX" / %s"PROHIBITED" / %s"NO_AUTH" / %s"HAS_AUTH" / %s"NO_QUEUE"
 ```
 
 Server implementations must aim to respond within the same time for each command in all cases when `"ERR AUTH"` response is required to prevent timing attacks (e.g., the server should perform signature verification even when the queue does not exist on the server or the signature of different size is sent, using any RSA key with the same size as the signature size).
@@ -842,7 +792,6 @@ ok = %s"OK"
 Both the recipient and the sender can use TCP or some other, possibly higher level, transport protocol to communicate with the server. The default TCP port for SMP server is 5223.
 
 For scenarios when meta-data privacy is critical, it is recommended that clients:
-
 - communicating over Tor network,
 - establish a separate connection for each SMP queue,
 - send noise traffic (using PING command).
@@ -850,14 +799,12 @@ For scenarios when meta-data privacy is critical, it is recommended that clients
 In addition to that, the servers can be deployed as Tor onion services.
 
 The transport protocol should provide the following:
-
 - server authentication (by matching server certificate hash with `serverIdentity`),
 - forward secrecy (by encrypting the traffic using ephemeral keys agreed during transport handshake),
 - integrity (preventing data modification by the attacker without detection),
 - unique channel binding (`sessionIdentifier`) to include in the signed part of SMP transmissions.
 
 By default, the client and server communicate using [TLS 1.3 protocol][13] restricted to:
-
 - TLS_CHACHA20_POLY1305_SHA256 cipher suite (for better performance on mobile devices),
 - ed25519 and ed448 EdDSA algorithms for signatures,
 - x25519 and x448 ECDHE groups for key exchange.

protocol/simplex-uri-request.txt

@@ -13,6 +13,6 @@ Change controller: Evgeny Poberezkin <ep@simplex.chat>
 
 References:
 The syntax for connection requests in the latest version of SimpleX Agent Protocol:
-https://github.com/simplex-chat/simplexmq/blob/master/protocol/agent-protocol.md#connection-request
+https://github.com/simplex-chat/simplexmq/blob/v5/protocol/agent-protocol.md#connection-request
 SimpleX Messaging Protocol:
-https://github.com/simplex-chat/simplexmq/blob/master/protocol/simplex-messaging.md
+https://github.com/simplex-chat/simplexmq/blob/v5/protocol/simplex-messaging.md

protocol/smp-uri-request.txt

@@ -13,4 +13,4 @@ Change controller: Evgeny Poberezkin <ep@simplex.chat>
 
 References:
 The syntax for message queue URIs in the latest version of SimpleX Messaging Protocol:
-https://github.com/simplex-chat/simplexmq/blob/master/protocol/simplex-messaging.md#smp-queue-uri
+https://github.com/simplex-chat/simplexmq/blob/v5/protocol/simplex-messaging.md#smp-queue-uri

protocol/xftp-uri-request.txt

@@ -1,16 +0,0 @@
-Scheme name: xftp
-
-Status: Provisional
-
-Applications/protocols that use this scheme name:
-This scheme is used for URIs of XFTP (SimpleX File Transfer Protocol) servers,
-a client-server protocol for asynchronous file transfer via relays,
-preserving file meta-data (including size and name) and content privacy.
-
-Contact: Evgeny Poberezkin <ep@simplex.chat>
-
-Change controller: Evgeny Poberezkin <ep@simplex.chat>
-
-References:
-The syntax for server URIs in the provisional specification for SimpleX File Transfer Protocol:
-https://github.com/simplex-chat/simplexmq/blob/master/rfcs/2022-12-26-simplex-file-transfer.md#server-address-syntax

protocol/xrcp-uri-request.txt

@@ -1,15 +0,0 @@
-Scheme name: xrcp
-
-Status: Provisional
-
-Applications/protocols that use this scheme name:
-This scheme is used for URIs of controller sessions via SimpleX Remote Control protocol (XRCP),
-a protocol for remote access and management of hosts via insecure network.
-
-Contact: Evgeny Poberezkin <ep@simplex.chat>
-
-Change controller: Evgeny Poberezkin <ep@simplex.chat>
-
-References:
-The syntax for server URIs in the provisional specification for SimpleX File Transfer Protocol:
-https://github.com/simplex-chat/simplexmq/blob/master/rfcs/2023-10-25-remote-control.md#session-invitation

rfcs/2022-04-20-smp-conf-timeout-recovery.md

@@ -1,21 +0,0 @@
-# SMP confirmation timeout recovery
-
-## 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;
-- 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;
-- 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.
-
-## Solution
-
-A possible solution is to keep and try to reuse same credentials on subsequent attempts:
-- joining party has to remember invitation link when saving the connection;
-- if SMP confirmation fails due to network timeout joining party doesn't delete the connection and keeps the credentials;
-- when joining, joining party checks whether such invitation link was already used for a connection, if yes:
-  - joining party tries to send SMP confirmation with the same credentials;
-  - if this SMP confirmation fails with authorization error (for example it can happen due to race condition explained above) joining party tries to send HELLO message;
-  - if HELLO message fails with authorization error (it can happen if connection was deleted or secured with different credentials), the recovery is no longer possible and connection can be deleted.

rfcs/2022-12-26-simplex-file-transfer.md

@@ -1,173 +0,0 @@
-# SimpleX File Transfer protocol
-
-## Problem
-
-Sending files as currently implemented in SimpleX Chat is inefficient for these reasons:
-
-1. Slow: message delivery requires acknowledgement for each message before the server sends the next message.
-2. Not fully asynchronous:
-   a. SMP queue size is limited, so the whole file cannot be sent/stored in server memory.
-   b. Recipient needs to accept the file before it is sent.
-3. No broadcast: sending the same file to multiple recipients requires sending it multiple times.
-
-## Possible solutions
-
-These problems could be solved within SMP protocol:
-
-- streaming messages without waiting for acknowledgements.
-- bigger queue sizes stored on hard drive and accepting large files without waiting for the recipient confirmation.
-- adding broadcast to SMP servers.
-
-These solution are complex and they do not scale well.
-
-Another approach would be adopting some open-source file storage, possibly S3-compatible, to host files while "in transit". The downsides are:
-
-1. Missing features. S3-compatible file servers require a service layer that we would need to develop to manage user accounts and permissions. There are solutions that allow self-registering users and uploading files without service layer, but they are not flexible enough in managing policies for these files.
-2. Limited meta-data protection, both on the application and on transport layer: same address for sending and receiving a file, file size is known to the server, etc.
-3. More difficult to self-host for the users when the server has 2 components (a 3rd party solution with our service component).
-
-We are not considering P2P solutions because of their bad meta-data privacy and requirement of having a single network - the same reason why P2P design is not used for SimpleX messaging network.
-
-A proposed solution is to develop a file hosting service (SimpleX File Transfer service) that would have better meta-data protection and functionality than the alternatives, using the ideas from SMP protocol design.
-
-The parameters of the solution would be:
-
-1. The server does not have knowledge of the users and actual files – only anonymously uploaded fixed-size chunks (considered 8Mb, maybe we should allow 2 sizes, e.g. 1Mb and 8Mb).
-2. The server should allow broadcast, so that a chunk can be downloaded by multiple recipients.
-3. There should be no identifiers and ciphertext in common inside TLS between sender and recipient traffic, and between the traffic of different recipients of the same file. This approach can be extended to support public chunks that have persistent identifiers.
-4. The server should prevent multiple uploads of the same chunk. This can be extended to allow multiple downloads from the same persistent address.
-5. Clients can send the chunks from the same file via multiple servers, both by splitting chunks between them and for redundancy.
-
-## Design approach
-
-File transfer servers will be chosen by file senders. The servers will allow senders to anonymously upload fixed-size file chunks.
-
-### 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.
-- 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).
-
-The reasons to use HTTP2:
-
-- avoid the need to have two hostnames (or two different ports) for commands and file uploads.
-- compatibility with the existing HTTP2 client libraries.
-
-The reason not to use JSON bodies:
-
-- bigger request size, so fewer recipient keys would fit in a single request
-- signature over command has to be outside of JSON anyway.
-
-The reason not to use URI segments / HTTP verbs / REST semantics is to have consistent request size.
-
-### Required server commands:
-
-- File sender:
-  - create file chunk record.
-    - Parameters:
-      - Ed25519 key for subsequent sender commands and Ed25519 keys for commands of each recipient.
-      - chunk size.
-    - Response:
-      - chunk ID for the sender and different IDs for all recipients.
-  - add recipients to file chunk
-    - Parameters:
-      - sender's chunk ID
-      - Ed25519 keys for commands of each recipient.
-    - Response:
-      - chunk IDs for new recipients.
-  - upload file chunk.
-  - delete file chunk (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.
-
-### Storage model
-
-Same as for SMP and notifications server - in-memory storage of the records, with adding to append-only log, restored and compacted on server restart.
-
-### Sending file
-
-To send the file, the sender will:
-
-- compute SHA512 digest
-- pad the file to match the whole number of chunks in size,
-- encrypt it with a randomly chosen symmetric key and IV (e.g., using NaCL crypto_secretbox),
-- split into fixed size chunks
-- upload each chunk to a randomly chosen server.
-
-The sending client should generate more per-recipient keys than the actual number of recipients, possibly rounding up to a power of 2, to conceal the actual number of intended recipients.
-
-Then the sending client will combine addresses of all chunks and other information into "file description", different for each file recipient, that will include:
-
-- an encryption key that was used to encrypt the file (the same for all recipients).
-- file SHA512 digest
-- 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
-
-To reduce the size, chunk descriptions will be grouped by the server host.
-
-This "file description" itself will be sent as a small file over an authenticated channel, to prevent file description modification. To estimate its size:
-
-- each chunk \* redundancy per chunk, assuming chunks are grouped per server:
-  - 1-based chunk number in the file - 8 bytes (including any overhead)
-  - Ed25519 key (different for each recipient / chunk combination) - 32 bytes \* 4/3 (base64, assuming text encoding)
-  - chunk ID (different for each recipient) - 64 bytes \* 4/3
-  - optional (only in the first chunk occurence) chunk sha512 digests - 64 bytes \* 4/3
-- server addresses - say, 128 bytes per server
-- sha512 digest - 64 bytes \* 4/3
-- encryption key - 32 bytes \* 4/3
-- IV - 32 bytes \* 4/3
-- encoding overhead - say, 256 bytes
-
-For 1gb file, sent via 4 different servers, in 8Mb chunks, with redundancy 2, the size of "file description", assuming text encoding, will be ~45kb (`128 * (8 + 32 + 64) * 2 * 4/3 + 128 * 64 * 4/3 + 128 * 4 + (64 + 32 + 32) * 4/3 + 256`).
-
-File description format (yml):
-
-```
-name: file.ext
-size: 33200000
-chunk: 8mb
-hash: abc=
-key: abc=
-iv: abc=
-parts:
-  - server: xftp://abc=@example1.com
-    chunks: [1:abc=:def=:ghi=, 3:abc=:def=:ghi=]
-  - server: xftp://abc=@example2.com
-    chunks: [2:abc=:def=:ghi=, 4:abc=:def=:ghi=:2mb]
-  - server: xftp://abc=@example3.com
-    chunks: [1:abc=:def=, 4:abc=:def=]
-  - server: xftp://abc=@example4.com
-    chunks: [2:abc=:def=, 3:abc=:def=]
-```
-
-This file description is sent to all recipients via normal messages, split to 15780 byte chunks if needed.
-
-### Server address syntax
-
-The server address is a URI with the following format:
-
-```abnf
-xftpServerURI = %s"xftp://" xftpServer
-xftpServer = serverIdentity "@" srvHost [":" port]
-srvHost = <hostname> ; RFC1123, RFC5891
-port = 1*DIGIT
-serverIdentity = base64url
-base64url = <base64url encoded binary> ; RFC4648, section 5
-```
-
-### Receiving file
-
-Having received the description, the recipient will:
-
-- download all chunks falling back to secondary servers, if needed
-- combine the chunks into a file
-- decrypt the file
-- un-pad it
-- validate file digest

rfcs/2022-12-27-queue-quota.md

@@ -1,20 +0,0 @@
-# SMP and SMP agent protocol extensions to manage queue quotas
-
-## Problem
-
-SMP servers define a limit on the number of messages that can be stored on the server. When the sender reaches this limit, they continue trying to send the message with exponential back off, until the server allows it. To reduce the traffic we added expiration on unsent messages of 2 days that:
-
-- adds its own set of problems because of expired control messages - e.g., group fragmentation.
-- doesn't solve problem of traffic in active groups with many inactive members - there are still too many retries in queues that reached capacity.
-
-## Solution
-
-Sending agent permanently stops trying to send messages having received `ERR QUOTA` (or, for the period of clients migration, increases TTL much more than in cases of network errors).
-
-Add SMP server event that means "quota reached" (e.g. `QTA` or `MSG QUOTA`) - it will be delivered to the recipient once all messages are retrieved at the same point in message stream where the sender received `ERR QUOTA`. Alternatively, it could be a message flag that is set on the last message in the queue at a point the sender received `ERR QUOTA`.
-
-Add SMP agent message that means "quota available, resume sending" (e.g. `A_QTA` or `A_RESUME`) – the receiving agent will send it via the reply queue to the sending agent that will resume sending messages at this point.
-
-Possibly, increase TTL for local messages to 30 days. That might require separately addressing the problem of permanently failing servers.
-
-We discussed a possible solution of merging all messages to one server into one delivery queue, so that having multiple failing queues on this server will not result in multiple connection attempts, and this proposal also answers the question what to do with the messages when quota is exceeded - the whole queue can be marked as suspended, and processed separately from others - TBD.

rfcs/2023-05-02-resync-ratchets.md

@@ -1,58 +0,0 @@
-# Re-sync encryption ratchets, queue rotation, message delivery receipts
-
-This is very unfocussed doc outlining several problems that seem somewhat related, and some possible solution approaches.
-
-## Problems
-
-When old database backup is used, the sending client encrypts the messages in a way that the receiving client cannot decrypt them, because it does not store the old keys, and does not try to decrypt ratchet headers using the old keys. When receiving the messages, the client that uses the old database is unable to decrypt them, either the header or the message itself (if more than 500 messages are skipped, or if root ratchet step happened).
-
-The same symptoms happen during the queue rotation, unfortunately, as we do not keep the history of received messages once they are acknowledged, so the client reports these error to the users.
-
-While these are two different problems, to the users they manifest in the same way, so it is difficult to differentiate.
-
-Another ratchet problem that should be solved as well is not deleting unused skipped keys after some time or some number of events, possibly it should be considered at the same time.
-
-While it is tempting to consider delivery receipts as an isolated problem, it is somewhat coupled, as the requests to re-sync ratchets and to re-deliver skipped messages are effectively delivery receipts.
-
-A naive solution to delivery receipts when each message is responded to with a confirmation has two downsides:
-
-- it doubles the traffic.
-- in the absense of delays, it also leaks some information about the network latency, that can be used to track user's location.
-
-Both problems can be mitigated by sending delivery receipts with a random delay, to confirm all messages sent, not each one. But this would only reduce the traffic when the sender sends many messages. Alternatively, we could think how to reduce the block size for SMP commands. The challenge is profile pictures and image previews, so to reduce traffic we need to start sending them as XFTP files, potentially with a smaller 64kb chunks (that would also increase preview quality).
-
-## Solution for queue rotation
-
-We need to:
-- store and show the rotation status in the UI to prevent attempts to rotate the queue multiple times.
-- process multiple message delivery events while there is a redundancy, to avoid errors in terminal.
-- differentiate between decryption errors during queue rotation - that would require keeping the messages for some time, at least keeping their IDs and hashes together with some additional status. In this case when duplicate or old message arrives, we can check whether this message was already processed, and do not show error if it was.
-
-## Solution to re-sync ratchets
-
-When we establish that the receiving client is indeed unable to decrypt messages, we should:
-- notify the user - it is already happening, but it happens in case of rotation as well.
-- optionally, notify another client that message was not decrypted - this effectively becomes a delivery receipt. That could be a separate command triggered by the user in the UI.
-- clients can get into this state at the same time, how do we handle concurrent requests? Possibly, we could design these messages so this is irrelevant whether the message is sent in response or not, and calculate the new ratchet keys once the clients have both the sent and received messages. After that both clients can send "ratchet reset" message:
-  - EKEY - message containing a new set of keys to initialize the ratchets
-  - EREADY - message confirming that the ratchet is ready, already e2e encrypted
-
-The downside of this approach, is that unlike the initial handshake, where the second ratchet key is sent in e2e encrypted response, this message will be sent only encrypted with queue key. We could change this protocol by adding EREPLY message, and the clients would know to ingnore EKEY with bigger hash of the keys, so that the client who sent keys with smaller hash would be processing response from another client (that is if EKEY is received after EKEY is sent).
-
-```
-A                B
-
-EKEY 1 ->        <- EKEY 2 (e2e encrypted with per-queue key only)
-EKEY 2 <-        -> EKEY 1
-1 < 2, wait      2 > 1, reply EREPLY 3 (e2e encrypted with ratchets)
-ratchet: 1, 3   ratchet: 3, 1
-```
-
-Once ratchets are re-synched the clients could additionally request delivery of skipped messages. As ratchets being out of sync is not the only problem when messages can be lost, it may be managed independently from the ratchet re-sync. This problem seems tied with delivery receipts too, as requesting to re-deliver some messages automatically confirms that some other messages were delivered.
-
-Alternatively, the request for ratchet sync can already contain the ID of the first failed message - that would allow the agent:
-- stop sending messages until ratchets are in sync.
-- re-deliver failed messages first.
-- only then deliver any pending messages.
-
-This approach would probably result in a better UX (no out of order delivery), but requires tracking pending messages that are not attempted to deliver and to also insert old messages in the delivery queue with the old IDs.

rfcs/2023-05-03-delivery-receipts.md

@@ -1,170 +0,0 @@
-# Delivery receipts
-
-## Problems
-
-User experience - users need to know that the messages are delivered to the recipient, as this confirms that the system is functioning.
-
-The downside of communicating message delivery as it confirms that the recipient was online, and, unless there is a delay in confirming, can be used to track the location via the variation in network latency. So delivery receipts should be delayed with a randomized interval and should be opt in or opt out.
-
-Another problem of message receipts is that they increase network traffic and server load. This could be avoided if delivery receipts are communicated as part of normal message delivery flow.
-
-Some other existing and planned features implicitely confirm message delivery and, possibly, should depend on message delivery being enabled:
-- agent message to resume delivery when quota was exceeded (implemented, [rfc](./2022-12-27-queue-quota.md))
-- agent message to re-deliver skipped messages or to re-negotiate double ratchet.
-
-## Solution
-
-There are three layers where delivery receipts can be implemented:
-- chat protocol. Pro: logic of when to deliver it is decoupled from the message flow, Con: extra traffic, can only work in duplex connections.
-- agent client protocol. Pro: can be automated and combined with the protocol to re-deliver skipped messages. Con: extra traffic.
-- SMP protocol. Pro: minimal extra traffic, Con: complicates server design as it would require pushing receipts when there is no next message.
-
-The last approach seems the most promising for avoiding additional traffic:
-- modify client ACK command to include whether delivery receipt should be provided to sender, and, possibly, any e2e encrypted data that should be included in the receipt (e.g., that the receiving client already saw this message in case we use "feedback" variant of roumor-mongering protocol for groups).
-- server would manage delaying of the receipts, by randomizing the time after which the receipt will be available to the sender, and by combining the receipts when possible.
-- modify response to SEND command to include any available delivery receipts.
-- add a separate delivery receipt that will be pushed to the sender in the connection where the message was received by the server.
-
-## SMP protocol changes
-
-```haskell
-data Command (p :: Party) where
-  -- ...
-  ACK :: MsgId -> Maybe ByteString -> Command Recipient
-  -- the presense of ByteString in ACK indicates that the delivery needs to be confirmed.
-  -- the protocol does not define the format of this confirmation, it is application specific, and can be -- an empty string.
-  -- And open question is how to e2e encrypt information in this string - this probably can be handled on Agent client protocol level, and could be the same ratchet key that was used to encrypt and decrypt the message. The downside of this approach is that this key currently is not stored, and storing it requires additional logic to clear these keys if unused after some time.
-  -- TODO consider what could be a better approach.
-  SENT :: MsgId -> [(MsgId, UTCTime, ByteString)] -> Command Sender
-  -- or
-  -- SENT :: MsgId -> Command Sender
-  -- in case we just batch
-  -- this response will be sent to SEND command and will include a sender's message ID generated by the server (currently it does not exist), and posibly an empty list of delivery receipts with the same message IDs as in responses to SEND, timestamps when these receipts became available, and e2e encrypted ByteString passed in ACK command.
-  -- The ID in this response should be different from the ID used in MSG, to keep the promise of not having shared identifiers in sent/received traffic even inside TLS tunnel.
-  -- Keeping the quality of shared ciphertext also requires adding additional encryption layer between the server and the sender, this can be achieved in one of two ways:
-  -- 1) passing a separate DH key in each SEND command, and server including additional DH key in each SENT response, with computed DH secret per message later used to encrypt and decrypt the delivery receipt payloads. This is probably a bad idea as it would increase a cryptographic load on both the server and the client.
-  -- 2) agree a key per queue, in the same way it is done for the recipient. Possibly, it requires additional DH key in confirmation message that the recipient then uses to secure the queue, and passing this key in KEY (secure queue) command. The response to this secure command would the include server's DH key returned to the recipient that would be passed to the sender in HELLO message. Even though recipient could observe both public DH keys, they won't know the computed shared secret. Recipient that controls the server could perform MITM attack on this key exchange, but it doesn't give any benefit over what recipient can do when they have access to the server - the threat model remains the same. The downside of this approach is that it also requires additional changes in client protocol level (confirmation message format and HELLO message).
-  -- 3) also agree on a key per queue, but via separate commands between the sender and the server, once the sender was notified that the queue is secured. This approach is probably better, and the server would simply delay the delivery of delivery receipts until the shared secret is agreed.
-  SKEY :: C.PublicKeyX25519 -> Command Sender
-  SBKEY :: C.PublicKeyX25519 -> BrokerMsg
-  -- these are the command and response to agree secret to encrypt delivery receipt payloads for option 3
-  SSUB :: Command Sender
-  -- subscribe to receive delivery receipts for a given queue - will be sent when the conversation is opened (unless there is an active subscription already), not all queues at once, and won't be re-subscribed on losing the server connection (TBC).
-  RCVD :: MsgId -> UTCTime -> ByteString -> Command Recipient
-  -- delivery receipt. UTCTime is the time when it became available, not the time when ACK was sent by the recipient, to avoid leaking location via network latency.
-```
-
-Possibly, there is no need to include delivery receipts into SENT response and instead just use batching of responses that is already supported. As server responses are not signed, there is no per-response overhead that is substantial, and a lot of receipts that are available can be packed into one block (depending on the size of payload that has to be fixed not to leak metadata).
-
-This all seems rather complicated for SMP protocol, and the approach of doing it on a higher level seems more attractive than initially. Possibly we should reconsider, and reduce traffic by reducing block sizes... Reducing block sizes unfortunately requires supporting variable block sizes, and would leak some metadata during the transition period.
-
-## Another approach
-
-Above represents substantial complexity, and at least doubles server code complexity for the feature that is definitely not doubling the value of server software. Moving to variable block size is simpler, but also has a lot of complexity, reduces metadata privacy (at least for the duration of migration period), reduces image preview quality, and requires postponing this feature for multiple releases, until all clients migrate.
-
-Given that the main traffic is generated by the groups, and direct messages do not create a lot of traffic, a much simpler and better solution is to simply send delivery receipts as the message, in direct conversations only, either as chat protocol message or as agent client protocol message (either on the message or on the envelope layer).
-
-### Comparison of these two approaches:
-
-**Chat protocol message**
-
-Pros:
-- simpler, more contained change - SMP layer is not aware of this feature
-- easier to extend protocol with additional application specific payload, e.g. references to group DAG
-Cons:
-- ?
-
-```json
-  // ...
-  "x.msg.delivered": {
-    "properties": {
-      "msgId": {"ref": "base64url"},
-      "params": {
-        "properties": {
-          "msgId": {"ref": "base64url"},
-        },
-        "optionalProperties": {
-          "data": {} // possibly the initial protocol does not need it, with JSON can be added later
-        }
-      }
-    }
-  },
-  // ...
-```
-
-**Agent client protocol envelope**
-
-Pros:
-- possibility of using it in a wider range of the applications
-- possibility to include received message hash to increase communication integrity - the sending client would be then notified, and it can be exposed in the UI, that the received message is not the same as sent.
-
-Cons:
-- additional implementation complexity - requires additional events to communicate between chat and agent.
-
-```haskell
-data AMessage =
-  -- ...
-  | A_RCVD AgentMsgId MsgHash ByteString -- references to the received message
-  -- ...
-```
-
-The weirdness of the above design is that it refers to the data present in the header of another message, the alternative would be to have a separate envelope for delivery receipt:
-
-```haskell
-data AgentMessage =
-  -- ...
-  AgentMessageRcvd APrivHeader AgentMsgId MsgHash ByteString -- references to the received message
-  -- ...
-```
-
-But probably the first one is a bit better, TBC.
-
-In any case there should be an additional event to notify chat client:
-
-```haskell
-data ACommand (p :: AParty) (e :: AEntity) where
-  -- ...
-  RCVD AgentMsgId MsgMeta ByteString -> ACommand Agent AEConn
-  -- ...
-```
-
-On the balance of things, implementing on the level of Agent Client protocol seems better, as the additional complexity is marginal, but it allows for wider range of applications, and also allows for additional delivery integrity validation. The format for payload still requires chat protocol message encoding once we want to add it, but initially it could be just an empty string.
-
-## Implementation plan
-
-Currently, we delete sent messages once delivered to the server. It would be helpful if we could keep the records in snd_messages table, and then use them to process delivery receipts, although it may be insufficient (we could add fields). Probably it is not possible to keep them as there is a foreign key constraint with `on delete cascade`.
-
-The new table will be used to track sent message hashes to correlate their IDs with delivery receipts (that will also be stored in messages/rcv_messages). Receipts need to be processed in chat in the same way as normal messages, so they would be sent to chat with MsgMeta, and the chat will need to ack them once processed.
-
-Agent ackMessage function will be also used to automatically schedule sending delivery receipts if they are enabled for connection, only for normal messages - no sending receipts to receipts.
-
-There can be receipt re-delivery to the chat in the same cases as when normal message can be re-delivered (in case of AGENT A_DUPLICATE when it was not ack'd by the user).
-
-## Other considerations
-
-### How clients decide whether to send delivery receipts
-
-Two options are possible - local settings per conversation or chat preferences framework, that allows to have mutual on/off. The latter seems preferable as without knowing whether the other party is sending receipts, it is not possible to uderstand what the absense of the receipt means - network malfunction or receipts disabled.
-
-Groups are a special case, as while some groups may enable sending the delivery receipts, the group members should be able to disable it locally. This should probably be done via a separate conversation setting in the same way as enabling notifications or favourites. In this case the receipt would only be sent to the group if it is enabled in the group and not disabled by the member. The toggle may be located in the same page as chat preferences, but it should be a separate setting. We might want though to communicate somehow whether a given member sends delivery receipts so that other members know whether to expect them or not.
-
-### How this functionality is released
-
-5.2:
-- support for sending and receiving delivery receipts preference, both in direct messages and in groups (for forward compatibility).
-- support for sending and receiving delivery receipts in direct chats only, but disable sending them
-
-5.3:
-- show receipt preferences in the UI
-- enable sending receipts in direct chats where they are enabled
-
-A separate question is how to enable this functionality for the existing contacts. Possible options are:
-
-1. Enable (as per default) for all contacts, show notification to the user when they open the app for update that delivery notifications are now sent by default to all contacts. Pro: no extra logic to implement. Con: may be perceived as a privacy violation, as to some contacts the delivery receipts will be sent before the user had chance to disable them.
-2. Ask the user when the new version first runs whether they want to use delivery receipts and offer these options:
-  1) keep enabled for all profiles (and for all contacts)
-  2) enable for all profiles in ~12 or in ~24 hours giving users the chance to review all contacts / profiles and disable some of them. The problem here is also in possibility of the correlation in case they all start sending receipts at the same time. Possibly the option could be to set a random time in 12-15 or 24-30 hours range to avoid the possibility of such correlation.
-  3) disable for all profiles – it will require sending profile updates to all contacts, so the delivery receipts should be kept disabled and profile updates should be sent after random intervals, one by one (not scheduled all at once, as the time may pass while the app is off).
-3. Offer an option to enable globally later - we could keep it as a one-off option, available only to existing users, and visible on the top level of the Settings - once enabled, the option will disappear and it won't be possible to disable again. The downside here is that the new contacts would be receiving the profile with enabled notifications but they still won't be delivered...
-4. Another option is to have all new contacts decided based on a global user default (that can be set in the settings and in the dialog on first start), but for the existing contacts keep in unset state that is not interpreted as either on or off, but interpreted as unknown until the user makes a choice... That might be an optimal solution for the users but it would probably require changing the preferences framework or some ad-hoc hacks. That still keeps the question open how to avoid correlation between profiles.
-5. That might be the case for version agreement too - the availability of the option per contact will depend on the version. It doesn't answer the question what to do with global defaults though...

rfcs/2023-05-24-smp-delivery-proxy.md

@@ -1,34 +0,0 @@
-# SMP and XFTP delivery relays
-
-## Problem
-
-SimpleX network relies on SMP relays to hold sent messages while the recipient is offline. This design provides many advantages over pure p2p designs [1]. The threat model for relays is covered in [2].
-
-The problem with this design is that the relays are chosen by the recipients, and they as a result can be used to record transport addresses of the senders.
-
-Similar problem, but reversed, exists with XFTP design - XFTP relays are chosen by the senders and also can be modified to record transport addresses of the recipients.
-
-The current solution to this problem is to use onion routing to access relays, and many users do it already. The downside is that it requires additional configuration and can be complex to some users.
-
-## Solution approach
-
-Add a second type of relays to the network design.
-
-For SMP protocol, these relays would accept messages from the senders and deliver them to the recipients. If the recipient were to modify the relay used to receive the messages to also records senders' IP addresses, then they would only succeed in recording the IP address of the relay, not the sender.
-
-Similar relay can be introduced for XFTP protocol.
-
-The additional advantage of using the relays is the reduced number of network connections that need to be used, and reduced traffic.
-
-Compared with Tor this approach has:
-- lower latency
-- no centralized components or the registry of the servers
-- still no visibility of the whole network to the relays, as sending relays do not need to randomly choose the next relay, but would forward the messages directly to the destination relay.
-
-The downside of this approach is that relays will have more visibility of the network than in the current design.
-
-## Implementation considerations
-
-1. Should this new relays be included in the existing SMP and XFTP protocols and servers, or should they be designed as separate protocols and servers?
-
-2. Should the client aim to choose the same host for delivery relay as the destination server (to reduce the traffic), if possible, or should it aim to choose a different host (to reduce metadata available to single host)? The answer to this would affect the answer to the first question.

rfcs/2023-06-08-resync-ratchets.md

@@ -1,366 +0,0 @@
-# Re-sync encryption ratchets
-
-## Problem
-
-See https://github.com/simplex-chat/simplexmq/pull/743/files for problem and high-level solution.
-
-## Implementation
-
-### Diagnosing ratchet de-synchronization
-
-Message decryption happens in `agentClientMsg`, in `agentRatchetDecrypt`, which can return decryption result or error. Decryption error can be differentiated in `agentClientMsg` result pattern match, in Left cases, where we already differentiate duplicate error (`AGENT A_DUPLICATE`).
-
-Question: Which decryption errors can be diagnosed as ratchet de-synchronization?
-
-Possibly any `AGENT A_CRYPTO` error. Definitely on `RATCHET_HEADER`, TBC other. See `cryptoError :: C.CryptoError -> AgentErrorType` for conversion from decryption errors to `A_CRYPTO` or other agent errors. We're only interested in crypto errors, as other are either other client implementation errors, internal errors, or already processed duplicate error.
-
-Proposed classification of crypto errors, based on `AgentCryptoError`:
-
-`DECRYPT_AES` -> re-sync allowed (recommended/required?)
-
-`DECRYPT_CB` -> re-sync allowed (recommended/required?)
-
-`RATCHET_HEADER` -> **re-sync required**
-
-`RATCHET_EARLIER` -> re-sync allowed
-
-`RATCHET_SKIPPED` -> **re-sync required**
-
-Ratchet re-synchronization could be started automatically on diagnosing de-synchronization, based on these errors. As a potentially dangerous feature (e.g., implementation error could lead to infinite re-sync loop causing large traffic consumption), initially it will be available via agent functional api for client to call. Ratchet de-synchronization will instead produce an event prompting client to re-synchronize.
-
-Diagnosing possible ratchet de-synchronization also will be recorded as connection state - `ratchet_desync_state` field in `connections` table. Client should be prohibited to start ratchet re-synchronization unless `ratchet_desync_state` is set.
-
-Event should not be repeated for following received messages that can't be decrypted - based on `ratchet_desync_state`. If a received message can be decrypted, `ratchet_desync_state` should be set to NULL and a new event sent, indicating ratchet has healed.
-
-New event - `RDESYNC :: RatchetDesyncState -> ConnectionStats -> ACommand Agent AEConn`
-
-```haskell
-data RatchetDesyncState
-  = RDResyncAllowed
-  | RDResyncRequired
-  | RDHealed
-```
-
-New field should be added to `ConnectionStats` - `ratchetDesyncState :: Maybe RatchetDesyncState`, based on `ratchet_desync_state`.
-
-> On `RDESYNC` events chat should create chat item, prompting ratchet re-synchronization or notifying it has healed.
-> If connection has diagnosed ratchet de-sync, chat item should have a button to start ratchet re-sync.
-> We'd have to get `ConnectionStats` on chat level for this instead of chat info.
-> This wouldn't work for groups. One option is to add `ConnectionStats` to `GroupMember` type and update on events.
-> Same could be done for `Contact` then.
-
-To consider - allow to start ratchet re-synchronization at any time regardless of this field as an experimental feature. In chat it could be behind "Developer tools" + additional "Experimental" toggle. Agent api would have `force :: Bool` as parameter, allowing to bypass `ratchet_desync_state`. Should `ratchet_resync_state` (see below) still be honored in this case?
-
-### Re-synchronization process
-
-\*\*\*\*\*
-
-Basic idea is the following:
-
-Both agents send new ratchet keys and compute a new shared secret. Agent that starts re-synchronization should record this fact in the connection state. Agent that receives a new key should respond with a key of its own, unless it has recorded that it itself started re-synchronization in the connection state.
-
-It can happen that both agents start re-synchronizing simultaneously. In this case they both would record it in the connection state and would not respond with a new message - instead they would use each other's already sent keys.
-
-Agent has both keys if:
-
-- It initiates with the first key, and then receives the second key;
-- It receives the first key and then generates its own in response.
-
-After agent has both keys, it initiates new ratchet depending on keys ordering. The agent that sent the lower key should use `initRcvRatchet` function, the agent that sent the greater key should use `initSndRatchet` (or vice versa - but they should deterministically choose different sides).
-
-\*\*\*\*\*
-
-State whether the ratchet re-synchronization is in progress should be tracked in database via `connections` table new `ratchet_resync_state` field.
-
-New functional api:
-
-```haskell
-resyncConnectionRatchet :: AgentErrorMonad m => AgentClient -> ConnId -> m ConnectionStats
-```
-
-or if we want to allow re-synchronizing ratchet at any time even if de-synchronization wasn't diagnosed:
-
-```haskell
-resyncConnectionRatchet :: AgentErrorMonad m => AgentClient -> ConnId -> Bool -> m ConnectionStats
-resyncConnectionRatchet c connId force = ...
-```
-
-Possibly client command?
-
-``` haskell
-data ACommand (p :: AParty) (e :: AEntity) where
-  ...
-  RESYNC_RATCHET :: Bool -> ACommand Client AEConn
-```
-
-New event - `RRESYNC :: RatchetResyncState -> ConnectionStats -> ACommand Agent AEConn`
-
-```haskell
-data RatchetResyncState
-  = RRStarted
-  | RRAgreedSnd
-  | RRAgreedRcv
-  | RRComplete
-```
-
-New `ConnectionStats` field - `ratchetResyncState :: Maybe RatchetResyncState`.
-
-When called, it should:
-
-- Generate new keys.
-- Update database connection state.
-  - Set `ratchet_desync_state` to NULL.
-  - Set `ratchet_resync_state` to `RRStarted`.
-  - Delete old ratchet from `ratchets` (is it safe?), create new ratchet.
-- Send `AgentRatchetKey` message.
-- Return updated `ConnectionStats` to client.
-
-> On `RRESYNC` events chat should create chat item, and reset connection verification.
-> Parameterized `RRESYNC` allows to distinguish: start and end of re-synchronization for initiating party; chat item direction - `RRESYNC RRStarted` is snd, `RRESYNC RRAgreedSnd/Rcv` and `RRESYNC RRComplete` are rcv (`RRESYNC RRAgreedSnd/Rcv` chat item could be omitted).
-
-AgentRatchetKey is a new message on the level of AgentMsgEnvelope - encrypted with queue level e2e encryption, but not with connection level e2e encryption (since ratchet de-synchronized).
-
-```haskell
-data AgentMsgEnvelope
-  = ...
-  | AgentRatchetKey
-      { agentVersion :: Version,
-        e2eEncryption :: E2ERatchetParams 'C.X448,
-        info :: ByteString -- for extension
-      }
-```
-
-On receiving `AgentRatchetKey`, if the receiving client hasn't started the ratchet re-synchronization itself (check `ratchet_resync_state`), it should:
-
-- Generate new keys and compute new shared secret, initializing ratchet based on keys comparison.
-- Update database connection state.
-  - Set `ratchet_resync_state` to `RRAgreedSnd/Rcv` (depending on whether ratchet was initialized as sending or receiving).
-  - Delete old ratchet from `ratchets`, create new ratchet.
-- Reply with its own `AgentRatchetKey`.
-- Notify client with `RRESYNC RRAgreedSnd/Rcv`.
-- If ratchet was initialized as sending, send `EREADY` message, notifying other agent ratchet is re-synced.
-
-New agent message:
-
-```haskell
-data AMessage
-  = ...
-  | -- ratchet re-synchronization is complete, with last decrypted sender message id
-    EREADY PrevExternalSndId
-```
-
-On receiving `AgentRatchetKey`, if the receiving client started re-sync:
-
-- Compute new shared secret, initializing ratchet based on keys comparison.
-- Update database connection state.
-  - Set `ratchet_resync_state` to `RRAgreedSnd/Rcv` (depending on whether ratchet was initialized as sending or receiving).
-  - Update ratchet.
-- Notify client with `RRESYNC RRAgreedSnd/Rcv`.
-- If ratchet was initialized as sending, send `EREADY` message.
-
-After agent receives `EREADY` (or any other message that successfully decrypts):
-
-- Reset `ratchet_resync_state` to NULL.
-- Notify client with `RRESYNC RRComplete`.
-- If ratchet was initialized as receiving, send reply `EREADY` message.
-
-### State transitions
-
-For initiating party:
-
-```
-    +------------+
-    | Ratchet ok |
-    +------------+
-          |
-          | message received, decryption error
-   * ---->|-----------------------------------+
-          |                                   |
-          V          new (clarifying)         V
-  +-----------------+     error      +------------------+
-  | Re-sync allowed |--------------->| Re-sync required |
-  +-----------------+                +------------------+
-          |                                   |
-          |-----------------------------------|
-          |                                   | alternative - message received,
-          | re-sync started by client         | successfully decrypted
-          V                                   V
-  +-----------------+                   +------------+
-  | Re-sync started |                   | Ratchet ok |
-  +-----------------+                   +------------+
-          |
-          | other party replied with new ratchet key
-          V
-  +----------------+
-  | Re-sync agreed |----> * message received, decryption error
-  |   snd / rcv    |        (should remember agreed state for reply EREADY?)
-  +----------------+
-          |
-          | message received, successfully decrypted
-          | (can be, but not necessarily, EREADY)
-          V
-    +------------+
-    | Ratchet ok |
-    +------------+
-```
-
-For replying party:
-
-```
-    +------------+
-    | Ratchet ok |
-    +------------+
-          |
-          | other party sent new ratchet key
-          V
-  +----------------+
-  | Re-sync agreed |
-  |   snd / rcv    |
-  +----------------+
-          |
-          | message received, successfully decrypted
-          | (can be, but not necessarily, EREADY)
-          V
-    +------------+
-    | Ratchet ok |
-    +------------+
-```
-
-### Ratchet state model
-
-#### 2 state variables
-
-Above we considered model with separate de-sync and re-sync state.
-
-| Desync \ Resync      | Nothing | RRStarted | RRAgreedSnd | RRAgreedRcv |
-| ---                  |  :---:  |   :---:   |    :---:    |    :---:    |
-| **Nothing**          | 1       | 3         | 4           | 4           |
-| **RDResyncAllowed**  | 2       |           | 5           | 5           |
-| **RDResyncRequired** | 2       |           | 5           | 5           |
-
-1: Ratchet is ok.
-
-2: Re-sync diagnosed, not in progress.
-
-3: Rs-sync started, diagnosing de-sync is prohibited.
-
-4: Re-sync agreed.
-
-5: Re-sync agreed, new de-sync is diagnosed.
-
-Combination 5 is possible in case de-sync was diagnosed before message that could be decrypted is received, for example if `EREADY` failed to deliver and no other decryptable message followed. We shouldn't prohibit diagnosing de-sync in this case, because agent may never exit "Agreed" state (if new decryptable message is never received). We also shouldn't overwrite/forget state of re-sync, even if we diagnose new possible de-sync, because if the decryptable `EREADY` is received and ratchet is in `RRAgreedRcv` state, it should respond with reply `EREADY`.
-
-Some combinations should be impossible:
-
-  - `RDResyncAllowed` with `RRStarted`.
-
-  - `RDResyncRequired` with `RRStarted`.
-
-`RDHealed` is equivalent to `Nothing` and only used for `RDESYNC` event, `Maybe RatchetDesyncState` can be replaced with `RatchetDesyncState`, with single new constructor `RDNoDesync` replacing `Nothing` and `RDHealed`.
-
-`RRComplete` is equivalent to `Nothing` and only used for `RRESYNC` event, `Maybe RatchetResyncState` can be replaced with `RatchetResyncState`, with single new constructor `RDNoResync` replacing `Nothing` and `RRComplete`.
-
-#### Single state variable
-
-Another option is two have a single state variable describing ratchet.
-
-```haskell
-data RatchetState
-  = RSOk
-  | RSResyncAllowed
-  | RSResyncRequired
-  | RSResyncStarted
-  | RRResyncAgreedSnd
-  | RRResyncAgreedRcv
-
--- When `resyncConnectionRatchet` is not prohibited. Can override with `force`.
--- Currently we check:`(isJust ratchetDesyncState || force) && ratchetResyncState /= Just RRStarted`.
-resyncConnectionRatchetAllowed :: RatchetState -> Bool
-resyncConnectionRatchetAllowed = \case
-  RSOk -> False
-  RSResyncAllowed -> True
-  RSResyncRequired -> True
-  RSResyncStarted -> False -- `force` shouldn't override
-  RRResyncAgreedSnd -> False
-  RRResyncAgreedRcv -> False
-
--- When we register and notify about ratchet de-synchronization.
--- Currently we check: `(isNothing ratchetDesyncState && ratchetResyncState /= Just RRStarted)`.
--- We should also allow to update from Allowed to Required.
-shouldNotifyRDESYNC :: RatchetState -> Bool
-shouldNotifyRDESYNC = \case
-  RSOk -> True
-  RSResyncAllowed -> False -- only if new error implies Required
-  RSResyncRequired -> False
-  RSResyncStarted -> False
-  RRResyncAgreedSnd -> True
-  RRResyncAgreedRcv -> True
-
--- When we prohibit connection switch, for `checkRatchetDesync`.
--- Currently we check: `(ratchetDesyncState == Just RDResyncRequired || ratchetResyncState == Just RRStarted)`
--- Also use in `runSmpQueueMsgDelivery` to pause delivery?
-ratchetDesynced :: RatchetState -> Bool
-ratchetDesynced = \case
-  RSOk -> False
-  RSResyncAllowed -> False
-  RSResyncRequired -> True
-  RSResyncStarted -> True
-  RRResyncAgreedSnd -> False
-  RRResyncAgreedRcv -> False
-```
-
-Having a single state variable limits differentiation described for combination 5 in matrix. It also limits possible differentiations in client between events when ratchet is healed on its own, and when ratchet re-sync is completed after agents negotiation. Overall, since matrix is not very sparse and allows for more fine-grained decision-making, having separate state variables for de-sync and re-sync seems preferred.
-
-#### Single state variable simplified (final version)
-
-```haskell
-data RatchetSyncState
-  = RSOk
-  | RSAllowed
-  | RSRequired
-  | RSStarted
-  | RSAgreed
-
--- event
-RSYNC :: RatchetSyncState -> ConnectionStats -> ACommand Agent AEConn`
-
--- ConnectionStats field
-ratchetSyncState :: RatchetSyncState
-```
-
-Updated design decisions:
-
-1. Single constructor for "Agreed" state. Differentiating `RRResyncAgreedSnd` and `RRResyncAgreedRcv` allowed for easier processing of `EREADY` by helping to determine whether reply `EREADY` has to be sent. However, it duplicated information already present in ratchet's state, and can be instead worked around by remembering and analyzing ratchet state pre decryption.
-
-2. Prohibit transition from "Agreed" state to "Desync" states. This would make possible edge-cases that leave ratchet in de-synchronized state without ability to progress (e.g. failed delivery of `AgentRatchetKey`), but would simplify state machine by removing dedicated "Desync" variable. Besides, there's still a recovery way with a `force` option.
-
-3. Treat "Agreed" as unfinished state - prohibit new messages to be enqueued, etc. Reception of any decryptable message transitions ratchet to "Ok" state.
-
-Possible improvements:
-
-- Repeatedly triggering re-synchronization while in "Started"/"Agreed" state re-sends same keys and EREADY.
-- Cooldown period, during which repeat re-synchronization is prohibited.
-
-### Skipped messages
-
-Options:
-
-1. Ignore skipped messages.
-2. Stop sending new messages while connection re-synchronizes (can use `ratchet_resync_state`).
-
-- Initiator shouldn't send new messages until receives `AgentRatchetKey` from second party.
-- Second party knows new shared secret immediately after processing first `AgentRatchetKey`, so it's not necessary to limit?
-
-3. 2 + Re-send skipped messages first.
-
-- Add `last_external_snd_msg_id` to `AgentRatchetKey`? + see link above
-
-4. Re-send only messages after the latest ratchet step. \*
-
-It may be okay to ignore skipped messages, or at most implement option 2, as ratchet de-synchronization is usually caused by misuse (human error) - the most common cause of ratchet de-sync seems to be sending and receiving messages after running agent with old database backup. In this case user has already seen most skipped messages, and it can be expected to not have them after switching to an old backup. So in this case the only "really skipped" messages are those that were sent during the latest ratchet step and failed to decrypt, triggering ratchet re-sync (\* another option is to only re-send those).
-
-Besides, depending on time of backup there may be an arbitrary large number of skipped messages, which may consume a lot of traffic and may halt delivery of up-to-date messages for some time.
-
-It may be better to have request for repeat delivery as a separate feature, that can be requested in necessary contexts - for example for group stability.
-
-Can servers delivery failure lead to de-sync? If message is lost on server and never delivered, ratchet wouldn't advance, so there's no room for de-sync? If yes, re-evaluate.

rfcs/2023-09-12-second-relays.md

@@ -1,295 +0,0 @@
-# Protecting IP addresses of the users from their contacts
-
-## Problem
-
-SMP protocol relays are chosen and can be controlled by the message recipients. It means that the recipients can find out IP addresses of message senders by modifying SMP relay code (or by using proxies and timing correlation), unless the senders use VPN or some overlay network. Tor is an adequate solution in most cases to mitigate it, but it requires additional technical knowledge to install and configure (even installing Orbot on Android is seen as "complex" by many users), and reduces usability because of higher latency.
-
-The lack of in-built IP address protection is the main concern of many users, particularly given that most people do not realize that it is lacking by default - without transport protection SimpleX is not perceived as a "whole product".
-
-Similarly, XFTP protocol relays are chosen by senders, and they can be used to detect file recipients' IP addresses.
-
-## Possible solutions
-
-1. Embed Tor in the client.
-
-Pros:
-- no changes in the protocols/servers
-- acceptable threat model for most users
-- removes complexity of installing and configuring Tor
-- probably, the most attractive option for Tor users
-
-Cons:
-- higher latency and error rate
-- higher resource usage
-- requires us updating Tor client regularly
-- restriction on Tor usage in some networks, so it would require supporting bridges in the app UI
-- legislative restrictions on Tor usage, so it may require supporting multiple app versions, and won't solve the problem where Tor is not embedded
-
-2. Thin clients with hosted accounts.
-
-Host some part of the current client on the server and have another part running on the devices.
-
-Pros:
-- substantially reduces the traffic for mobile clients
-- probably the most attractive option for mass market users who expect to have an account on the server and be able to access it from multiple devices and via web.
-
-Cons:
-- a lot of design and development
-- makes accounts visible to the server
-- the new protocol design to protect connections graph and message content from the hosting server.
-- quite different threat model
-
-Overall, this is not a viable or even appropriate option for the current stage.
-
-3. SMP / XFTP proxy.
-
-Introduce SMP and XFTP protocol extensions to allow message senders and file recipients to delegate the tasks of sending messages and receiving files to the proxies, so that peer-chosen relays can only observe IP addresses of the proxies and not of the users.
-
-Pros:
-- no dependency on and lower latency than via Tor
-- reduces client traffic, both due to retries handled by these proxies and due to the smaller number of connections to the peer-chosen relays. The flip side is that additional commands (and traffic) are needed to create the sessions with relays.
-- higher transport privacy: protects IP addresses from peers and makes transport correlation harder.
-- additional function: retrying pending messages, while the queue is not secured yet, without extra traffic for the clients.
-- improves current threat model by preventing session-based correlation of the traffic by the destination relay (assuming no information sharing with the proxies), as there will be one session between proxy and destination relay, mixing traffic from multiple users.
-
-Cons:
-- design and development cost
-- can undermine delivery stability
-
-This seems an attractive option, both from technical (reasonable complexity) and positioning (moving SimpleX closer to mix networks, while still avoiding server list visibility) points of view, and it is in the middle between embedding Tor, which would make the product more niche and has downsides and development costs too, and thin clients, which is 10x+ more work, and also creates a different threat model, that is not very attractive for the current stage and users.
-
-Below considers this design.
-
-## SMP/XFTP proxy design
-
-### Design requirements
-
-1. To avoid increasing the complexity of self-hosting, we should not create additional server types, and existing SMP and XFTP servers should be extended to provide proxy functions.
-
-2. SMP proxy should not be able to observe queue addresses and their count on the destination relays. This requirement is not needed for XFTP proxies, as each file chunk is downloaded only once, so there is no need to hide its address.
-
-3. There must be no identifiers and ciphertext in common in outgoing and incoming traffic inside TLS (the current designs have this quality).
-
-4. Traffic between the client and destination relays must be e2e encrypted, with MITM-by-proxy mitigated, relying on the relay identity (certificate fingerprint), ideally without any additional fingerprint in relay address.
-
-5. SMP proxy should implement retry logic and hold messages while they are delivered. They also should return relay replies to the client. To avoid any additional traffic the client should just add "sent to proxy" status and only show "sent" once proxy returns the response from the destination relay - there should be no additional response from the proxy confirming acceptance to delivery.
-
-This would also reduce the difference in how the traffic looks to the observer - sending via proxy may look similar to sending to the usual server (which can be further supported by friendly destination relays that could add latency for direct requests and reply quickly when response came via proxy and be undermined by hostile relays that would introduce some latency pattern to help traffic correlation. The latter problem can be mitigated by having a fixed response latency from proxy that may be "come back later for destination response").
-
-6. Sending messages to groups have to be batched in the client to avoid multiple requests for destination relay sessions - such requests can be batched to proxy, even though it leaks _some_ metadata - which destination relays are used by a given sender's IP address, it also reduces the overhead from proxies – it could be an option based on the privacy slider.
-
-6. SMP proxy may also increase utility and privacy of the platform:
-
-- holding messages and retrying them for the new connections while the receiving queue is not secured yet.
-- add delays in message delivery to make traffic correlation harder (same can be done in SMP relays).
-
-### Implementation considerations
-
-1. Block size. Possibly, there is not enough spare capacity in the current 16kb block to fit additional headers, any necessary metadata and encryption authentication tags, in which case we cannot send SMP and SMP-proxy traffic in the same transport connection (in case the same server plays both roles). In which case we will need to negotiate role during connection handshake and define a different (sub-)protocol for SMP-proxy.
-
-2. To be decided if we see it as extension of SMP protocol or as another protocol, irrespective of whether it's provided by the same or another server. Given different roles and block size it may be simpler to see it as a separate protocol, and which protocol is provided in the connection is determined during handshake.
-
-3. We probably should aim to avoid changing agent/client logic and see it instead as transport concern that can be dynamically decided at a point of sending a message, based on the current configuration.
-
-4. Configuration should probably allow to choose between not using proxies (particularly, during testing, when it would be the default), using proxies only for unknown relays, and using proxies for all relays (extra traffic, but more complex transport correlation - although randomizing this choice can be more beneficial to the transport privacy). The clients can aim to use proxy from another provider, to reduce the risks of sharing the information.
-
-### SMP-proxy protocol
-
-The flow of the messages will be:
-
-1. Client requests proxy to create session with the relay by sending `PRXY` command with the SMP relay address and optional proxy basic AUTH (below). It should be possible to batch multiple session requests into one block, to reduce traffic.
-
-2. Proxy connects to SMP relay, negotiating a shared secret via a handshake headers - it will be used to encrypt all sender blocks inside TLS (proxy-relay encryption). DH key returned by SMP relay in handshake will also be used to encrypt client commands, combining it with random per-command keys (sender-relay encryption, to hide metadata sent to the destination relay from proxy).
-
-3. Proxy replies to sender with `PKEY` message using "entityId" transmission field to indicate session ID for using in further requests, relay DH key for _s2r_ encryption with the client - this key is signed with the TLS online private key associated with the certificate (its fingerprint is included in the relay address), and the TLS session ID between proxy and relay (this session ID must be used in transmissions, to mitigate replay attacks as before).
-
-A possible attack here is that proxy can use this TLS session to replay commands received from the client. Possibly, it could be mitigated with a bloom filter per proxy/SMP relay connection that would reject the repeated DH keys (that need to be used for replay), and also with DH key expiration (this mitigation should allow some acceptable rate of false positives from the bloom filter).
-
-With 32 bits per key there will be ~1/1,000,000 false positives (see https://en.wikipedia.org/wiki/Bloom_filter), and the filter would use ~32mb per each proxy connection if we reset relay key every 1000000 messages or more frequently. Given that the only commands accepted via relay would be SEND, replaying it would be interpreted by the receiving client as duplicate message delivery, so a small number of replayed messages won't cause any problems. But without mitigation it could be used to flood the receiving SMP relay queues with repeated messages, effectively causing DoS on these queues, even in case when SMP relays require basic auth to create queues.
-
-Given that the client chooses proxy it has some trust to, maybe this replay attack risk can be accepted.
-
-It is important that the same public key from destination relay is returned to all clients, so proxy does not need to repeat this request to know relays while the key did not expire, as using different keys for different clients would allow destination relays to correlate requests to the clients. A proxy that colludes with the destination relay can pass different public keys to the same client, but it is not changing threat model as colluding proxy can share information as well. It is also important that the client uses a new random key for each command, as using the same key would allow the destination relay to identify these commands as comming from the same user, and using a different key for each queue while would protect privacy of the user from the destination relay, would make it visible to the proxy how many different queues the client has on destination relay.
-
-*Unrelated cosideration for SMP protocol privacy improvement*: instead of signing commands to the destination relay, the sender could have a ratchet per queue agreed with the destination relay that would simply use authenticated encryption with per-message symmetric key to encrypt the message on the way to relay, and this encryption would be used as a proof of sender.
-
-4. Now the client sends `PFWD` to proxy, which it then forwards to SMP relay as `RFWD`, applying _p2r_ encryption layer.
-
-5. SMP relay sends `RRES` to proxy applying _p2r_ encryption layer, which it then forwards to the client as `PRES`, removing the _p2r_ encryption layer.
-
-Effectively it works as a simplified two-hop onion routing with the first relay (proxy) chosen by the sending client and the second relay chosen by the recipient, not only protecting senders' IP addresses from the recipients' relays, but also preventing recipients' relays from correlating senders' traffic to different queues, as TLS session is owned by the proxy now and it mixes the traffic from multiple senders. To correlate traffic to users, proxy and relay would have to combine their information. SMP relays are still able to correlate traffic to receiving users via transport session.
-
-Sequence diagram for sending the message via SMP proxy:
-
-```
--------------               -------------                     -------------              -------------
-|  sending  |               |    SMP    |                     |    SMP    |              | receiving |
-|  client   |               |   proxy   |                     |   relay   |              |  client   |
--------------               -------------                     -------------              -------------
-     |           `PRXY`           |                                 |                          |
-     | -------------------------> |                                 |                          |
-     |                            | ------------------------------> |                          |
-     |                            |          SMP handshake          |                          |
-     |                            | <------------------------------ |                          |
-     |           `PKEY`           |                                 |                          |
-     | <------------------------- |                                 |                          |
-     |                            |                                 |                          |
-     |        `PFWD` (s2r)        |                                 |                          |
-     | -------------------------> |                                 |                          |
-     |                            |           `RFWD` (p2r)          |                          |
-     |                            | ------------------------------> |                          |
-     |                            |           `RRES` (p2r)          |                          |
-     |                            | <------------------------------ |                          |
-     |        `PRES` (s2r)        |                                 |           `MSG`          |
-     | <------------------------- |                                 | -----------------------> |
-     |                            |                                 |           `ACK`          |
-     |                            |                                 | <----------------------- |
-     |                            |                                 |                          |
-     |                            |                                 |                          |
-```
-
-Below diagram shows the encrypttion layers for `PFWD`/`RFWD` commands and `RRES`/`PRES` responses:
-
-- s2r (added) - encryption between client and SMP relay, with relay key returned in relay handshake, with MITM by proxy mitigated by verifying the certificate fingerprint included in the relay address.
-- e2e (exists now) - end-to-end encryption per SMP queue, with double ratchet e2e encryption inside it.
-- p2r (added) - additional encryption between proxy and SMP relay with the shared secret agreed in the handshake, to mitigate traffic correlation inside TLS.
-- r2c (exists now) additional encryption between SMP relay and client to prevent traffic correlation inside TLS.
-
-```
------------------             -----------------  -- TLS --  -----------------             -----------------
-|               |  -- TLS --  |               |  -- p2r --  |               |  -- TLS --  |               |
-|               |  -- s2r --  |               |  -- s2r --  |               |  -- r2c --  |               |
-|    sending    |  -- e2e --  |               |  -- e2e --  |               |  -- e2e --  |   receiving   |
-|    client     |     MSG     |   SMP proxy   |     MSG     |   SMP relay   |     MSG     |    client     |
-|               |  -- e2e --  |               |  -- e2e --  |               |  -- e2e --  |               |
-|               |  -- s2r --  |               |  -- s2r --  |               |  -- r2c --  |               |
-|               |  -- TLS --  |               |  -- p2r --  |               |  -- TLS --  |               |
------------------             -----------------  -- TLS --  -----------------             -----------------
-```
-
-Question: should proxy declare its role in handshake? When proxy connects to SMP relay it would indicate in the handshake that it will act as a proxy and the SMP relay would expect the same `forward` commands and reply with `response`s.
-
-Common SMP transmission format (v4), for reference:
-
-```abnf
-paddedTransmission = <padded(transmission), 16384>
-transmission = signature signed
-signature = 0 ; empty signatures here
-signed = sessionIdentifier corrId entityId (smpCommand / brokerMsg)
-```
-
-- `corrId` is fully random each time and used as a nonce for encrypted blocks.
-- `entityId` carries tlsUniq from the current proxy-to-relay connection.
-- `smpCommand` gets extended with `s2p_command / p2r_command`.
-- `brokerMsg` gets extended with `r_key / r_response`.
-
-```abnf
-s2p_command = proxy / forward
-p2r_command = p_handshake ; forward is
-proxy = %s"PRXY" SP relayUri SP basicAuth
-relayUri = length %s"smp://" serverIdentity "@" srvHost [":" port]
-forward = %s"PFWD" SP dhPublic SP encryptedBlock
-r_key = %s"PKEY" SP dhPublic
-r_response = %s"RRES" SP encryptedBlock
-dhPublic = length x509encoded
-```
-
-The above assumes that the client can only send one message to an SMP relay and then has to wait for response before sending the next message. Missing the response would cause re-delivery (further improvement is possible when proxy detects these redelieveries and not send them to relays but simply reply with the same response).
-
-### Implementation considerations for the client
-
-While client/server protocol is rather straightforward to implement, and it is already working, there are some decisions to make about how the client makes decisions about.
-
-1. When to use proxy and when to connect directly to the destination relay.
-
-While from the perspective of threat model improvement it may be beneficial to always use the proxy, choosing the proxy that is different from other relays in the connection, initially we need to make it opt-in, with an option to only use it for unknown destination relays, to minimize any unexpected adverse effect on the delivery latency.
-
-Proxy mode will be passed from the client via NetworkConfig.
-
-2. Which proxying relays to use.
-
-Ability to request access to the session with the destination relay (and to create such session) is protected with the same basic auth approach as creating queues - the logic here is that opening private servers to all users as proxies would increase the scenarios for DoS attacks (which is the case with the public servers).
-
-The open question is whether the client should choose proxies from:
-- all configured relays.
-- there should be a subset of configured relays.
-- there should be a separate list.
-
-E.g., there could be a second toggle in the relay configuration to allow using relay as proxy, in addition to the current toggle that allows creating queues.
-
-For simplicity, initially we will just use all enabled relays as potential proxies.
-
-3. How many proxying relays should be used during one session.
-
-This is not a simple question, and it creates a contradiction between two risks:
-- collusion between proxies and destination relays simplifies correlating sending clients by session - from the point of view of this risk, clients should follow the same policy for creating connections with proxies, that is to create a new connection for each user profile, and if transport isolation is set to "per connection" - for each destination queue.
-- traffic correlation by observable traffic sessions (particularly if an attacker can observe user's ISP traffic or multiple proxies) - from this point of view, it would be beneficial to use fewer proxies and fewer connections with proxies and see the risk of proxy colluding with the destination relay as lower than the risk of traffic observation that in the case of multiple sessions would allow to correlate traffic to rarely used destination relays (any private self-hosted relays) and the traffic of the user to a given proxy, to prove the fact of user communicating with the destination relay via the proxy.
-
-While we can transfer this choice on the users, it seems a complex decision to make, and overall the second risk (traffic correlation) seems more important to address than the first.
-
-In any case possible options are:
-1. Extreme option 1: Create a new proxy session, with the new random proxy, for each potential transport session that would exist if the user were to be connected to destination relays directly. That is, never to mix access to multiple relays from multiple user profiles (and in case of per-connection isolation, to multiple queues) into a one client session with proxy. This is a rather radical option that nullifies any advantages of having fewer sessions with proxies than there would have been with the destination relays and removes any benefits of batching destination server session requests (PRXY comands).
-2. Extreme option 2: Use only one proxy session at the time, mixing traffic from all user profiles and to all destination servers (and for all queues) into a session with one proxy. This minimizes the risks of traffic correlation in case of non-colluding proxy, but maximises the risk in case it colludes with the destination relays.
-3. Balanced option: Use one proxy session per user profile, but mix traffic to multiple queues irrespective of connection isolation option and to all destination servers. Given that connection isolation is an experimental option, this makes the most sense, but it would have to be disclosed.
-4. Less balanced option: take connection isolation option into account and create a new proxy connection for each destination queue. This feels worse than option 3.
-
-If option 3 is chosen, then the transport session key with the proxy would be different from the transport session key with the relay - proxy session will only use UserId as the key, and the relay session uses (UserId, Server, Maybe EntityId) as the key.
-
-If option 4 is chosen, the keys would also be different, as the proxy would then use (UserId, Maybe (Server, EntityId)) as the key.
-
-We could potentially key proxy sessions (and create proxy connections) per each destination relay, in the same way as we key relays themselves, but it seems to have the least sense, as we neither achieve isolation by queue in case proxy and destination relay collude, nor we sufficiently protect from traffic correlation by any observers.
-
-The implemented design is this:
-- for each destination relay a random proxy is chosen and used to send all messages - all requests from a client coalesce to a single session.
-- transport isolation mode is taken into account, that is if per-connection isolation is enabled, then a separate proxy connection will be created for each messaging queue.
-- supported modes when proxy is used: always, for unknown relays, for unknown relays when IP address is not protected, never.
-
-This decision is made because the argument for protection against collusion between proxy and relay and more balanced traffic distribution is stronger than the argument for protection against traffic correlation, because even mixing all messages to one proxy connection does not provide protection against traffic correlation by time, so in any case it requires adding delays.
-
-### Threat model for SMP proxy and changes to threat model for SMP
-
-#### SMP proxy
-
-*can:*
-
-- learn a user's IP address, as long as Tor is not used.
-
-- learn when a user with a given IP address is online.
-
-- know how many messages are sent from a given IP address and to a given destination SMP relay.
-
-- drop all messages from a given IP address or to a given destination relay.
-
-- unless SMP relay detects repeated public DH keys of senders, replay messages to a destination relay 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 relay, 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 SMP relay.
-
-- undetectably add, duplicate, or corrupt individual messages.
-
-- undetectably drop individual messages, so long as a subsequent message is delivered.
-
-- learn the contents of messages.
-
-- 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 destination relay via an active attack.
-
-#### SMP relay accessed via SMP proxy
-
-*still can:*
-
-- perform recipients' queue correlation (matching multiple queues to a single recipient) via either a re-used transport connection, user's IP Address, or connection timing regularities
-
-*no longer can:*
-
-- 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 SMP proxy.
-
-- 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.
-
-The rest of the threat model for SMP relays remains the same as in [overview](../protocol/overview-tjr.md#simplex-messaging-protocol-server).

rfcs/2023-10-25-remote-control.md

@@ -1,361 +0,0 @@
-# SimpleX Remote Control protocol
-
-Using profiles in SimpleX Chat mobile app from desktop app with minimal risk to the security/threat model of SimpleX protocols.
-
-## Problem
-
-Synchronizing profiles that use double ratchet for e2e encryption is effectively impossible in a way that tolerates partitioning between devices without reducing security of double ratchet.
-
-We are not considering replacing (or weakening) double ratchet to allow profile synchronization, as some other messengers did (e.g., Session). We are also not considering Signal model, when profile is known to the server and adding devices results in changing security code and no visibility of conversation history, as it would be substantially different from the current model, and also effectively weakens the security, as in practives most users don't revalidate security codes when they change.
-
-## Solution
-
-The proposed solution is a new remote access/control protocol, when the application on host device (usually mobile) acts as a server, and application on another device (usually desktop) acts as a controller usually running in the same local network.
-
-Existing service discovery and remote control protocols known to us are vulnerable to spoofing, spamming and MITM attacks. This design aims to solve these problems.
-
-## Requirements
-
-- Strong, cryptographically verified identity of the controller device, with the initial connection requiring out-of-band communication of public keys (QR code or link).
-- Identity verification of the host device during session handshake.
-- Protection against malicious "controllers" trying to make host connect to them instead of valid controller on the same network.
-- Protection against replay attacks, both during discovery and during control session.
-- Additional encryption layer inside TLS, with post-quantum algorithm in key agreement.
-- Protect host device from unauthorized access in case of controller compromise.
-- Post-compromised security - that is, even if long term secrets were copied from the controller, and host device was made to connect to malicious controller device, prevent malicious controller from accessing the host device data.
-- Allow general high-level interactions common for many applications:
-  - RPC pattern for commands executed by the host application.
-  - Events sent by host to update controller UI.
-  - Uploading and downloading files between host and controller, either to be processed by the host or to be presented in the controller UI.
-
-This design will allow application-level protocol that is quite close to how SimpleX Chat UI interacts with SimpleX Chat core - there is a similar RPC + events protocol and support for files. The application-level protocol is out of scope of this specification.
-
-## Protocol phases
-
-Protocol consists of four phases:
-- controller session invitation
-- establishing session TLS connection
-- session verification and protocol negotiation
-- session operation
-
-### Session invitation
-
-The invitation to the first session between host and controller pair MUST be shared out-of-band, to establish a long term identity keys/certificates of the controller to host device.
-
-The subsequent sessions can be announced via an application-defined site-local multicast group, e.g. `224.0.0.251` (also used in mDNS/bonjour) and an application-defined port (SimpleX Chat uses 5227).
-
-The session invitation contains this data:
-- supported version range for remote control protocol
-- application-specific information, e.g. device name, application name and supported version range, settings, etc.
-- session start time in seconds since epoch
-- if multicast is used, counter of announce packets sent by controller
-- network address (ipv4 address and port) of the controller
-- CA TLS certificate fingerprint of the controller - this is part of long term identity of the controller established during the first session, and repeated in the subsequent session announcements.
-- Session Ed25519 public key used to verify the announcement and commands - this mitigates the compromise of the long term signature key, as the controller will have to sign each command with this key first.
-- Long-term Ed25519 public key used to verify the announcement and commands - this is part of the long term controller identity.
-- Session X25519 DH key and sntrup761 KEM encapsulation key to agree session encryption (both for multicast announcement and for commands and responses in TLS), as described in https://datatracker.ietf.org/doc/draft-josefsson-ntruprime-hybrid/. The new keys are used for each session, and if client key is already available (from the previous session), the computed shared secret will be used to encrypt the announcement multicast packet. The out-of-band invitation is unencrypted. These DH public key and KEM encapsulation key are always sent unencrypted. NaCL Cryptobox is used for encryption.
-
-Host device decrypts (except the first session) and validates the invitation:
-- Session signature is valid.
-- Timestamp is within some window from the current time.
-- Long-term key signature is valid.
-- Long-term CA and signature key are the same as in the first session.
-- Some version in the offered range is supported.
-
-OOB session invitation is a URI with this syntax:
-
-```abnf
-sessionAddressUri = "xrcp://" encodedCAFingerprint "@" host ":" port "#/?" qsParams
-encodedCAFingerprint = base64url
-qsParams = param *("&" param)
-param = versionRangeParam / appInfoParam / sessionTsParam /
-        sessPubKeyParam / idPubKeyParam / kemEncKeyParam / dhPubKeyParam /
-        sessSignatureParam / idSignatureParam
-versionRangeParam = "v=" (versionParam / (versionParam "-" versionParam))
-versionParam = 1*DIGIT
-appInfoParam = "app=" escapedJSON ; optional
-sessionTsParam = "ts=" 1*DIGIT
-sessPubKeyParam = "skey=" base64url ; required
-idPubKeyParam = "idkey=" base64url ; required
-dhPubKeyParam = "dh=" base64url ; required
-sessSignatureParam = "ssig=" base64url ; required, signs the URI with this and idSignatureParam param removed
-idSignatureParam = "idsig=" base64url ; required, signs the URI with this param removed
-base64url = <base64url encoded binary> ; RFC4648, section 5
-```
-
-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
-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.
-```
-
-### Establishing session TLS connection
-
-Host connects to controller via TCP session and validates CA credentials during TLS handshake. Controller acts as a TCP server in this connection, to avoid host device listening on a port, which might create an attack vector. During TLS handshake the controller's TCP server MUST present a self-signed two-certificate chain where the fingerprint of the first certificate MUST be the same as in the announcement.
-
-Host device presents its own client certificate chain with CA representing a long-term identity of the host device.
-
-### Session verification and protocol negotiation
-
-Once TLS session is established, both the host and controller device present a "session security code" to the user who must match them (e.g., visually or via QR code scan) and confirm on the host device. The session security code must be a digest of tlsunique channel binding. As it is computed as a digest of the TLS handshake for both the controller and the host, it will validate that the same TLS certificates are used on both sides, and that the same TLS session is established, mitigating the possibility of MITM attack in the connection.
-
-Once the session is confirmed by the user, the host device sends "hello" block to the controller. ALPN TLS extension is not used to obtain tlsunique prior to sending any packets.
-
-Block size should be 16384 bytes.
-
-Host HELLO must contain:
-- new session DH key - used to compute new shared secret with the controller keys from the announcement.
-- encrypted part of hello block (JSON object), containing:
-  - chosen protocol version.
-  - host CA TLS certificate fingerprint - part of host long term identity - must match the one presented in TLS handshake and the previous sessions, otherwise the connection is terminated.
-  - KEM encapsulation key - used to compute new shared secret for the session.
-  - additional application specific parameters, e.g host device name, application version, host settings or JSON encoding format.
-
-Hello block syntax:
-
-```abnf
-hostHello = unpaddedSize %s"HELLO " dhPubKey nonce encrypted(unpaddedSize hostHelloJSON helloPad) pad
-unpaddedSize = largeLength
-dhPubKey = length x509encoded
-pad = <pad block size to 16384 bytes>
-helloPad = <pad hello size to 12888 bytes>
-largeLength = 2*2 OCTET
-```
-
-Controller decrypts (including the first session) and validates the received hello block:
-- Chosen versions are supported (must be within offered ranges).
-- CA fingerprint matches the one presented in TLS handshake and the previous sessions - in subsequent sessions TLS connection should be rejected if the fingerprint is different.
-
-JTD schema for the encrypted part of host HELLO block `hostHelloJSON`: 
-
-```json
-{
-  "definitions": {
-    "version": {
-      "type": "string",
-      "metadata": {
-        "format": "[0-9]+"
-      }
-    },
-    "base64url": {
-      "type": "string",
-      "metadata": {
-        "format": "base64url"
-      }
-    }
-  },
-  "properties": {
-    "v": {"ref": "version"},
-    "ca": {"ref": "base64url"},
-    "kem": {"ref": "base64url"}
-  },
-  "optionalProperties": {
-    "app": {"properties": {}, "additionalProperties": true}
-  },
-  "additionalProperties": true
-}
-```
-
-Controller should reply with with `hello` or `error` response:
-
-```abnf
-ctrlHello = unpaddedSize %s"HELLO " kemCyphertext nonce encrypted(unpaddedSize ctrlHelloJSON helloPad) pad
-; ctrlHelloJSON is encrypted with the hybrid secret,
-; including both previously agreed DH secret and KEM secret from kemCyphertext
-unpaddedSize = largeLength
-kemCyphertext = largeLength *OCTET
-pad = <pad block size to 16384 bytes>
-helloPad = <pad hello size to 12888 bytes>
-largeLength = 2*2 OCTET
-
-ctrlError = unpaddedSize %s"ERROR " nonce encrypted(unpaddedSize ctrlErrorJSON helloPad) pad
-; ctrlErrorJSON is encrypted using previously agreed DH secret.
-```
-
-JTD schema for the encrypted part of controller HELLO block `ctrlHelloJSON`:
-
-```json
-{
-  "properties": {},
-  "additionalProperties": true
-}
-```
-
-JTD schema for the encrypted part of controller ERROR block `ctrlErrorJSON`:
-
-```json
-{
-  "properties": {
-    "message": {"type": "string"}
-  },
-  "additionalProperties": true
-}
-```
-
-Once controller replies HELLO to the valid host HELLO block, it should stop accepting new TCP connections.
-
-
-### Сontroller/host session operation
-
-The protocol for communication during the session is out of scope of this protocol.
-
-SimpleX Chat will use HTTP2 encoding, where host device acts as a server and controller acts as a client (these roles are reversed compared with TLS connection).
-
-Payloads in the protocol must be encrypted using NaCL cryptobox using the hybrid shared secret agreed during session establishment.
-
-Commands of the controller must be signed after the encryption using the controller's session and long term Ed25519 keys.
-
-tlsunique channel binding from TLS session MUST be included in commands (included in the signed body).
-
-The syntax for encrypted command and response body encoding:
-
-```
-commandBody = encBody sessSignature idSignature (attachment / noAttachment)
-responseBody = encBody attachment; should match counter in the command
-encBody = nonce encLength32 encrypted(tlsunique counter body)
-attachment = %x01 nonce encLength32 encrypted(attachment)
-noAttachment = %x00
-tlsunique = length 1*OCTET
-counter = 8*8 OCTET ; int64
-encLength32 = 4*4 OCTET ; uint32, includes authTag
-```
-
-If the command or response includes attachment, it's hash must be included in command/response and validated.
-
-## Key agreement for announcement packet and for session
-
-Initial announcement is shared out-of-band (URI with xrcp scheme), and it is not encrypted.
-
-This announcement contains only DH keys, as KEM key is too large to include in QR code, which are used to agree encryption key for host HELLO block. The host HELLO block will containt DH key in plaintext part and KEM encapsulation (public) key in encrypted part, that will be used to determine the shared secret (using SHA256 over concatenated DH shared secret and KEM encapsulated secret) both for controller HELLO response (that contains KEM cyphertext in plaintext part) and subsequent session commands and responses.
-
-During the next session the announcement is sent via encrypted multicast block. The shared key for this announcement and for host HELLO block is determined using the KEM shared secred from the previous session and DH shared secret computed using the host DH key from the previous session and the new controller DH key from the announcement.
-
-For the session, the shared secred is computed again using the KEM shared secret encapsulated by the controller using the new KEM key from the HOST hello block and DH shared secret computed using the host DH key from HELLO block and the new controller DH key from the announcement.
-
-To describe it in pseudocode:
-
-```
-// session 1
-hostHelloSecret(1) = dhSecret(1)
-sessionSecret(1) = sha256(dhSecret(1) || kemSecret(1)) // to encrypt session 1 data, incl. controller hello
-dhSecret(1) = dh(hostHelloDhKey(1), controllerInvitationDhKey(1))
-kemCiphertext(1) = enc(kemSecret(1), kemEncKey(1))
-// kemEncKey is included in host HELLO, kemCiphertext - in controller HELLO
-kemSecret(1) = dec(kemCiphertext(1), kemDecKey(1))
-
-// multicast announcement for session n
-announcementSecret(n) = sha256(dhSecret(n'))
-dhSecret(n') = dh(hostHelloDhKey(n - 1), controllerDhKey(n))
-
-// session n
-hostHelloSecret(n) = dhSecret(n)
-sessionSecret(n) = sha256(dhSecret(n) || kemSecret(n)) // to encrypt session n data, incl. controller hello
-dhSecret(n) = dh(hostHelloDhKey(n), controllerDhKey(n))
-// controllerDhKey(n) is either from invitation or from multicast announcement
-kemCiphertext(n) = enc(kemSecret(n), kemEncKey(n))
-kemSecret(n) = dec(kemCiphertext(n), kemDecKey(n))
-```
-
-If controller fails to store the new host DH key after receiving HELLO block, the encryption will become out of sync and the host won't be able to decrypt the next announcement. To mitigate it, the host should keep the last session DH key and also previous session DH key to try to decrypt the next announcement computing shared secret using both keys (first the new one, and in case it fails - the previous).
-
-To decrypt multicast announcement, the host should try to decrypt it using the keys of all known (paired) remote controllers.
-
-## Other options
-
-The proposed design has these pros/cons:
-
-Pros:
-- mobile host that has sensitive data doesn't act as TLS server.
-- multicast is optional - all sessions can happen via QR code only.
-
-Cons:
-- reversing of client/server roles between TLS and HTTP2.
-- in the first session mobile host TLS client credentials are verified after TLS connection is accepted.
-- cannot be used with host that runs in VM.
-
-The alternative design will use mobile host device as TLS server. The session negotiation process:
-
-- desktop shares its initial credentials via QR code, only for the first session
-- mobile sends encrypted multicast with session address, TLS CA fingerprint, DH key in clear text
-- desktop connects to mobile
-- session tlsunique presented to users on both devices - either user would have to confirm session on both devices or the mobile would have to send an additional "ready" block.
-
-Pros:
-- no reversing server role between TLS and HTTP2
-- TLS credentials are exchanged before TLS, so invalid credentials can be rejected during the handshake of the first session.
-- if some other way to pass data from host to controller is added, then it can be used with host running in VM.
-
-Cons:
-- multicast is mandatory, as there is no efficient way to communicate from mobile to desktop.
-- still needs hello or confirmation on both devices
-- mobile is now acting as TLS server creating additional attack vector
-
-In both proposed and alternative design mobile host has chat data, acts as HTTP2 server, commands are signed with desktop key presented out-of–band, and both commands and responses are encrypted inside TLS session.
-
-Other considered options:
-- SSH - more work integrating it.
-- use SMP connection to negotiate TLS session - it seems wrong to require Internet connection to negotiate a local network connection between desktop and mobile.
-- other multicast service discovery protocols - quite insecure.
-
-## Threat model
-
-#### A passive network adversary able to monitor the site-local traffic:
-
-*can:*
-- observe session times, duration and volume of the transmitted data between host and controller.
-
-*cannot:*
-- observe the content of the transmitted data.
-- substitute the transmitted commands or responses.
-- replay transmitted commands or events from the hosts.
-
-#### An active network adversary able to intercept and substitute the site-local traffic:
-
-*can:*
-- prevent host and controller devices from establishing the session
-
-*cannot:*
-- same as passive adversary, provided that user visually verified session code out-of-band.
-
-#### An active adversary with the access to the network:
-
-*can:*
-- spam controller device.
-
-*cannot:*
-- compromise host or controller devices.
-
-#### An active adversary with the access to the network who also observed OOB announcement:
-
-*can:*
-- connect to controller instead of the host.
-- present incorrect data to the controller.
-
-*cannot:*
-- connect to the host or make host connect to itself.
-
-#### Compromised controller device:
-
-*can:*
-- observe the content of the transmitted data.
-- access any data of the controlled host application, within the capabilities of the provided API.
-
-*cannot:*
-- access other data on the host device.
-- compromise host device.
-
-#### Compromised host device:
-
-*can:*
-- present incorrect data to the controller.
-- incorrectly interpret controller commands.
-
-*cannot:*
-- access controller data, even related to this host device.

rfcs/2023-12-29-pqdr.md

@@ -1,36 +0,0 @@
-# Post-quantum double ratchet implementation
-
-See [the previous doc](https://github.com/simplex-chat/simplex-chat/blob/stable/docs/rfcs/2023-09-30-pq-double-ratchet.md).
-
-The main implementation consideration is that it should be both backwards and forwards compatible, to allow changing the connection DR to/from using PQ primitives (although client version downgrade may be impossible in this case), and also to decide whether to use PQ primitive on per-connection basis:
-- use without links (in SMP confirmation or in SMP invitation via address or via member), don't use with links (as they would be too large).
-- use in small groups, don't use in large groups.
-
-Also note that for DR to work we need to have 2 KEMs running in parallel.
-
-Possible combinations (assuming both clients support PQ):
-
-| Stage        | No PQ kem | PQ key sent | PQ key + PQ ct sent |
-|:------------:|:---------:|:-----------:|:-------------------:|
-| inv   | + | + | - |
-| conf, in reply to:   <br>no-pq inv <br>pq inv        | &nbsp;<br>+<br>+ | &nbsp;<br>+<br>- | &nbsp;<br>-<br>+ |
-| 1st msg, in reply to:<br>no-pq conf<br>pq/pq+ct conf | &nbsp;<br>+<br>+ | &nbsp;<br>+<br>- | &nbsp;<br>-<br>+ |
-| Nth msg, in reply to:<br>no-pq msg <br>pq/pq+ct msg  | &nbsp;<br>+<br>+ | &nbsp;<br>+<br>- | &nbsp;<br>-<br>+ |
-
-These rules can be reduced to:
-1. initial invitation optionally has PQ key, but must not have ciphertext.
-2. all subsequent messages should be allowed without PQ key/ciphertext, but:
-  - if the previous message had PQ key or PQ key with ciphertext, they must either have no PQ key, or have PQ key with ciphertext (PQ key without ciphertext is an error).
-  - if the previous message had no PQ key, they must either have no PQ key, or have PQ key without ciphertext (PQ key with ciphertext is an error).
-
-The rules for calculating the shared secret for received/sent messages are (assuming received message is valid according to the above rules):
-
-|   sent msg ><br>V received msg | no-pq       | pq      | pq+ct           |
-|:------------------------------:|:-----------:|:-------:|:---------------:|
-| no-pq                          | DH / DH     | DH / DH | err             |
-| pq (sent msg was NOT pq)       | DH / DH     | err     | DH / DH+KEM     |
-| pq+ct (sent msg was NOT no-pq) | DH+KEM / DH | err     | DH+KEM / DH+KEM |
-
-To summarize, the upgrade to DH+KEM secret happens in a sent message that has PQ key with ciphertext sent in reply to message with PQ key only (without ciphertext), and the downgrade to DH secret happens in the message that has no PQ key.
-
-The type for sending PQ key with optional ciphertext is `Maybe E2ERachetKEM` where `data E2ERachetKEM = E2ERachetKEM KEMPublicKey (Maybe KEMCiphertext)`, and for SMP invitation it will be simply `Maybe KEMPublicKey`. Possibly, there is a way to encode the rules above in the types, these types don't constrain possible transitions to valid ones.

rfcs/2024-01-26-file-links.md

@@ -1,73 +0,0 @@
-# Sending large file descriptions
-
-It is desirable to provide a QR code/URI from which a file can be downloaded. This way files may be addressed outside a chat client.
-Currently the `xftp` CLI tool can generate YAML file descriptions that can be used to receive a file.
-It is possible to pass such a description as an URI, but descriptions for files larger than ~8 MBs (two 4 MB chunks) would give QR codes that are difficult to process.
-A user can manually upload description and get a shorter one. Typically descriptions for files that are up to ~20 GBs would still be small enough to not require another pass, and that is way beyond any current (or, reasonable, fwiw) limitations.
-
-It is possible to streamline this process, so any application using simplexmq agent can easily send file descriptions and follow redirects.
-A file description with a redirect contains an extra field with final file size and digest so it can be followed automatically.
-
-The flow would be like this:
-
-- Sending:
-  1. Upload file as usual with `xftpSendFile`, get recipient file descriptions in `SFDONE` message.
-  2. Upload one of the file descriptions with `xftpSendDescription`, get its redirect-description in its `SFDONE` message.
-  3. Wrap in `FileDescriptionURI` and use `strEncode` to get a QR-sized URI.
-  4. Show QR code / copy link.
-- Receiving:
-  1. Scan QR code / paste link.
-  2. Use `strDecode` and unwrap `FileDescriptionURI` to get `ValidFileDescription 'FRecipient`.
-  3. Download it as usual with `xftpReceiveFile`, getting `RFDONE` message when the file is fully received.
-
-It is not necesary to use redirect description if original description can be encoded to fit in 1002 characters. Beyond this size there is a significant jump in QR code complexity.
-It is possible to call `encodeFileDescriptionURI` right after upload to test if the URI fits and skip step 2.
-When `xftpReceiveFile` receives a decoded description that lacks `redirect` field, the procedure for downloading a file is the same as usual - download chunks and reassemble local file.
-
-## Agent changes
-
-### Sending
-
-Sending and receiving files in agent is a multi-step process mediated by DB entries in `snd_files` and `rcv_files` tables.
-
-`xftpSendDescription` is tasked with storing original description in a temporary locally-encrypted file, then creating upload task for it.
-
-It is necessary to preserve redirect metadata so it can be attached to descriptions in the `SFDONE` message sent by a worker:
-
-```sql
-ALTER TABLE snd_files ADD COLUMN redirect_size INTEGER;
-ALTER TABLE snd_files ADD COLUMN redirect_digest BLOB;
-```
-
-### Receiving
-
-`xftpReceiveFile` gets a file description as an argument and knows if it should follow redirect procedure or run an ordinary download.
-For redirects it will prepare a `RcvFile` for redirect and then a placeholder, for the final file.
-Agent messages would be sent using the entity ID of the final file, which is stored along with redirect metadata in `RcvFile` for the redirect.
-
-```sql
-ALTER TABLE rcv_files ADD COLUMN redirect_id INTEGER REFERENCES rcv_files ON DELETE CASCADE; -- for later updates
-ALTER TABLE rcv_files ADD COLUMN redirect_entity_id BLOB; -- for notifications
-ALTER TABLE rcv_files ADD COLUMN redirect_size INTEGER;
-ALTER TABLE rcv_files ADD COLUMN redirect_digest BLOB;
-```
-
-These additional fields will exist on the file that is a short description to receive an actual description of the final file.
-
-While a description YAML is being downloaded, the application will get `RFPROG` messages tagged for final entity, containing bytes downloaded so far and the total size from the original file.
-When the description is fully downloaded, the worker would decode description and check if the stated size and digest match the declared in redirect.
-Then it will replace placeholder description in `rcv_files` for destination file with the actual data from downloaded description.
-Finally, instead of sending `RFDONE` for redirect, it hands over work to chunk download worker, which will run exactly as if the user requested its download directly.
-An application will then receive `RFPROG` and `RFDONE` messages as usual.
-
-## URI encoding
-
-File description URIs use the same service schema `simplex:` or its `https://simplex.chat` (or any custom host) equivalent as do contact links and can be extracted from text and processed the same way.
-The path section is `/file` (with an optional trailing `/`).
-The payload is encoded in the "fragment" part of the link, using `#/?`, followed by a query string.
-File description is encoded first in a YAML document, then URL-encoded in under the key `d`.
-An application may want to pass extra parameters not necessary to download a file. Those go in the `_` key, encoded as a JSON dictionary.
-
-An example link:
-
-`simplex:/file#/?d=chunkSize%3A%2064kb%0Adigest%3A%20OtpnXkECTW4a18Eots2m3O22maeOCMqPUX4ulugIjgMEJfCpTYc_-T257Uw7s9bW_F0G5WBg5BioBWd4Z_OoCw%3D%3D%0Akey%3A%20rNR8_2SJuH7Qve43gV3zszL0R6oY5HSdRZT_paB-wfE%3D%0Anonce%3A%202oKwfK-w75nwyWp8_1Lv6QnQonIRtJmG%0Aparty%3A%20recipient%0Areplicas%3A%0A-%20chunks%3A%0A%20%20-%201%3ATdvaxMnG2Ph1e3QCx3-rpA%3D%3D%3AMC4CAQAwBQYDK2VwBCIEILdErEICvgrBCajDLTX2h3LXyMB7z5vrtLa3XVigJuf-%3ANS46KuYdgOWs6dUeMp7p2oF8rBQ9wQ2Ez6TW6Y6gHg0%3D%0A%20%20-%202%3AH5SRbtKYrXWVXTthrkeWzw%3D%3D%3AMC4CAQAwBQYDK2VwBCIEIGeEPNLt7lUGPfplwsoJLCDFnbIc5Hm31kz5X6rWXmgu%3A7QNRI-gvFx9UM-baXp3YVDli9pcfh3HGFKDhsA9JQHY%3D%0A%20%20-%203%3A_xjukkIl9WZFryUXT0h_TQ%3D%3D%3AMC4CAQAwBQYDK2VwBCIEIIRFBaL1HvUfePvKLuggwUrC_q_ZHd7v08IL9jhM7teC%3Aid2lgLMMjTGsR8SUogJuRdLoEHAc5SDQKFDqlZRSuEY%3D%0A%20%20server%3A%20xftp%3A%2F%2FLcJUMfVhwD8yxjAiSaDzzGF3-kLG4Uh0Fl_ZIjrRwjI%3D%40localhost%3A7002%0Asize%3A%20192kb%0A&_=%7B%22k%22:%22test%22%7D`

rfcs/2024-02-03-deniability.md

@@ -1,51 +0,0 @@
-# Repudiation for message senders
-
-## Problem
-
-We use double ratchet protocol to send messages. One of its important qualities is the use of symmetric encryption with forward secrecy, when the new key to encrypt the message is rotated after each message. This provides senders ability to plausibly deny having sent some messages, without denying having sent others. While the recipients can prove to themselves that the message was indeed sent by the sender, because it was encrypted using authenticated encryption with associated data, the recipients cannot prove it to any third party - as the message could have been encrypted by themselves, as they also have the same symmetric keys.
-
-To receive the messages, the recipients agree a message queue with the senders, and the commands sent to this queue are signed by the senders using the cryptographic key (Edwards curve key) of which the public counterpart was shared with the recipient in the confirmation message of SMP protocol (this confirmation message itself is not signed).
-
-While it was never claimed that the messaging protocol provides deniability, the deniability is often mentioned as one of the important qualities of double ratchet algorithm used in the innermost layer of e2e encryption, so without explicit disclaimer of deniability limitations, it may be assumed by the users that the system as a whole provides the same level of deniability as the double ratchet algorithm, which currently is not the case.
-
-While societal understanding and legal acceptance of repudiation is arguable, there was less than a decade since this quality became widely available in Signal - legal systems take longer to evolve.  While the argument that the message was forged is unlikely to be accepted in the usual court cases with the ordinary people, it is likely to be considered in cases with high profile defendants, who can reasonably claim that they are the target of smear campaign and are being attributed something that they never sent - the statement that the message is forged is reasonable in such cases, and it provides plausible deniability, and the cryptographic experts invited to the hearing would attest to that.
-
-It’s important to both continue providing repudiation quality in communication systems, when it is appropriate, and also to educate the users about when it can be used as a reasonable defence strategy, thus improving privacy of communication and making digital off-the-record communications possible and understood both by the society and by legal systems.
-
-## Solution
-
-The proposed solution is to avoid the use of signature algorithm for server command authorization, and instead use authenticated encryption to authorize the commands sent to the server queues. If this protocol change is adopted, it could be used both for senders and recipients commands, both for consistency, and also to provide the deniability to recipients about executing any commands on the servers, in a similar way.
-
-The proposed approach is to use NaCl crypto_box that proves authentication and third party unforgeability and, unlike signature, repudiation guarantee. See [crypto_box docs](https://nacl.cr.yp.to/box.html):
-
-> The crypto_box function is designed to meet the standard notions of privacy and third-party unforgeability for a public-key authenticated-encryption scheme using nonces. The crypto_box function is not meant to provide non-repudiation. On the contrary: the crypto_box function guarantees repudiability. A receiver can freely modify a boxed message, and therefore cannot convince third parties that this particular message came from the sender. The sender and receiver are nevertheless protected against forgeries by other parties. In the terminology of https://groups.google.com/group/sci.crypt/msg/ec5c18b23b11d82c, crypto_box uses "public-key authenticators" rather than "public-key signatures.”
-
-DJB further writes in the link above:
-
-> If you were already planning to encrypt the message, using another key derived from g^xy, then you don't have to do any extra public-key work. A secret-key authenticator is easier to implement than a public-key signature, and it takes less CPU time to compute.
-
-So the proposed solution appears to have desired security qualities, without non-repudiation, that is undesirable in the context of private messaging.
-
-When queue is created or secured, the recipient would provide a DH key (X25519) to the server (either their own or received from the sender), and the server would provide its own random X25519 key per session. Then, either the authenticator will be computed in this way:
-
-```abnf
-transmission = authenticator authorized
-authenticator = crypto_box(sha512(authorized), secret = dh(client long term queue key, server session key), nonce = correlation ID)
-authorized = tlsunique correlationId queueId protocol_command ; same as the currently signed part of the transmission
-```
-
-The authenticator is smaller in size than currently used signature size, freeing ~34 bytes from the transmission.
-
-This allows to retain the protocol logic and make authentication scheme configurable, both by the clients and servers, e.g. some servers might be configured to use signature for non-repudiation, and clients may be configured to either agree or disagree to that, per conversation.
-
-There is no required change in SMP command syntax other than allowing X25519 key instead of Ed signature keys passed to the server in NEW and KEY commands. We could add support for migration of the existing queues to the new authorization scheme, but it is not strictly required, as the clients provide a mechanism to rotate the receiving addresses (currently manually, and once automated all queues will be rotated). On another hand, per queue key and identifiers rotation is cheaper than negotiating the new queue (it can be done between client and server, without the involvement of another party), and could be considered as an independent improvement.
-
-## Migration plan
-
-As this new scheme breaks backward compatibility, as the new scheme requires additional keys in protocol handshake, and current implementation does not support forward compatible header extension, we have to migrate in multiple steps, to minimize any disruption to the users.
-
-1. Upgrade clients for forward compatibility of the protocol handshake (ignore extra bytes) - 5.5.3.
-2. Add support for handshake and version negotiation to XFTP - 5.5.4 or 5.6.
-3. Upgrade clients to drop support of SMP earlier than v4 (batching) and also drop support of old double ratchet protocol and old handshake - 5.6.
-4. Upgrade servers to offer SMP v7 with support for new authorization - by the time 5.6 is released.
-5. Upgrade clients to require server support for SMP v7 / new authorization scheme and start using it - 5.7 or 5.8. At this point the old version of the servers will not be supported, as maintaining this backward compatibility would substantially increase the complexity and logic of the client - at the point of generating the key we do not even know which server version will be used.

rfcs/2024-02-12-encryption.md

@@ -1,33 +0,0 @@
-# Transmission encryption
-
-## Problems
-
-### Protection of meta-data from sending proxy
-
-The SEND commands and message queue IDs need to be encrypted so that sending proxy cannot see how many queues exist on each server.
-
-Correlation IDs need to be random and can be re-used as nonces so that the destination relay cannot use the increasing correlation IDs that are sent in v6 of the protocol to track the sender.
-
-###  Protection of the traffic from the attacker who compromised TLS
-
-Currently, even though different sending and receiving queue IDs are used, the attacker who compromised TLS could do statistical analysis and in this way correlate queue IDs of senders and recipients, and therefore correlate the senders and recipients.
-
-## Possible solutions
-
-1. Encrypt sent messages, other commands and their responses in the additional envelope, irrespective of whether proxy is used or not. In this case the requestion transmission could have this syntax:
-
-```abnf
-encReqTransmission = pubKey nonce encrypted(reqTransmission)
-reqTransmission = respNonce entityId command
-
-encRespTransmission = replyNonce encrypted(respTransmission)
-respTransmission = entityId command
-```
-
-The keys to encrypt and decrypt both the command and responses would be computed as curve25519 from the key sent together with command and server session key. For the requests, the nonce has to be random and sent outside of the encrypted envelopt, but for the response respNonce would be taken from inside of the encrypted envelope and it would also be used for correlating commands and responses. This way the attacker who could compromise TLS would not be able to correlate the commands and responses, and also observe entity IDs.
-
-2. The remaining question is to how encrypt and decrypt messages delivered not in response to the commands.
-
-The possible options are:
-- restore client session key only for that purpose, but do not forward this key to the destination proxy for sent messages. Then the messages can be sent with a random replyNonce and the key would be computed from session keys. The advantage here is that we won't need to parameterize handles as both client and server would have session keys. The downside that we would have to either somehow differentiate messages and responses, either by some flag that would allow some correlation or just by the absense of replyNonce in the lookup map - that is if the client can find replyNonce, it would use the associated key to decrypt, and if not it would use session key.
-- use the same key that was sent with SUB or ACK command. This is much more complex, and would only have some upside if we were to introduce receiving proxies (to conceal transport sessions from the receiving relays for the recipients).

rfcs/2024-03-03-pqdr-version.md

@@ -1,92 +0,0 @@
-# Migrating existing connections to post-quantum double ratchet algorithm
-
-## Problem
-
-Post-quantum variant of double ratchet algorithm represents an almost full-stack change affecting all parts of the protocol stack except client-server protocol (SMP):
-- double-ratchet end-to-end encryption: different encoding (additional large keys require byte-strings larger than 255 bytes with 2-byte length prefixes) and larger message headers (increased by ~2200 bytes).
-- agent-agent protocol: a smaller maximum message size to accomodate larger headers and to fit in 16kb blocks, reduced by ~2200 bytes for the messages and by almost ~4000 bytes for connection information.
-- chat protocol: also a smaller message size compensated by zstd comression of JSON messages.
-
-We want the versioning that achieves these objectives:
-- all changes in all protocol layers happen at the same time, when both clients support it.
-- ability to downgrade the clients to the previous version without losing connection.
-- ability to opt-in into this functionality via "experimental" feature toggle, that enables post-quantum encryption in connections when both contacts enable this toggle.
-
-To have ability to downgrade the clients we have two options:
-- roll-out this functionality in two stages: 1) roll-out clients support but do not enable the new version, and then 2) upgrade client version. The problem here is that the clients won't be able to opt-in into this experiment.
-- make offered range dependent on experimental feature being enabled. Currently we have an option to enable PQ encryption in agent API, and this option can be used as a proxy to maxium supported protocol version - if the option is passed, it can be seen as an indication that higher version range (or version) should offered (or accepted).
-
-## Solution
-
-Currently ratchet state stores version range. It's unclear what was the intended semantics of that version range - it simply stores the offered/supported version range at the time ratchet was initialised, but only a high bound is used to send in message headers, and it is never upgraded. In JSON this range is encoded as tuple (an array of two elements in JSON).
-
-We could continue using this range with the meaning of the lower bound to be "currently used ratchet version" and the meaning of higher boundary to be "maximum supported ratchet version". We could also use the version communicated in message headers to upgrade ratchet version, with the condition that upgrade should only happen if both sides want it. Currently it's defined by pqEnableKEM property in ratchet state. We could also make it more explicit by defining maximum version to which ratchet should upgrade. Given that irreversible upgrades are not very common, it is probably ok to keep it implicit.
-
-We can define a better type than VersionRange to reflect semantics of the range in ratchet (current/max supported range), but for backward compatibility it needs to be encoded in the same way as now.
-
-To summarize, the proposed solution for ratchet versioning is:
-- define ratchet versions as new type to include current and maximum allowed versions, where maximum allowed will be either the same or lower than maximum supported based on PQ option (in 5.6), and in 5.7 it will be changed to maximum supported, so version starts upgrading independently from PQ being enabled.
-- make encodings in ratchet depend on current version (in curent code it depends on max version).
-- include max allowed in message header.
-- upgrade current if in range on each new message if less than max and higher than current (same as we do for connections).
-- increase max allowed once PQ is enabled (only in 5.6). Make max allowed the same as max supported (global constant).
-
-```haskell
-data RatchetVR = RatchetVR
-  { currentVersion :: Version,
-    maxAllowedVersion :: Version
-  }
-
-instance ToJSON RatchetVR where
-  toEncoding (RatchetVR v1 v2) = toEncoding (v1, v2)
-  toJSON (RatchetVR v1 v2) = toJSON (v1, v2)
-
-instance FromJSON RatchetVR where
-  parseJSON v = do
-    -- this also verifies that v2 > v1 (although we could remove JSON instances for VersionRange)
-    VersionRange v1 v2 <- parseJSON v
-    pure $ RatchetVR v1 v2
-```
-
-For connections, we could also make version used for the purposes of encoding dependent on the PQ being enabled, and version for decoding taken from message header, but then we'd have to not only upgrade ratchets but the connection as well every time PQ mode changes.
-
-Another suggestion to ensure that correct version range is used in correct contexts could be:
-- using different newtypes for different version ranges.
-- define generic type class for version aware encoding that would also accept only specific type class for the version to use the correct range. This may be justified as there will be several version-aware encodings, and not just the protocol as now.
-
-```haskell
-class Ord v => EncodingV v a where
-  {-# MINIMAL smpEncodeV, (smpDecodeV | smpVP) #-}
-  smpEncodeV :: v -> a -> ByteString
-  -- default decode uses parser
-  smpDecodeV :: v -> ByteString -> Either String a
-  smpDecodeV = parseAll . smpVP
-  -- default parser decodes from length-specified bytestring
-  smpVP :: v -> Parser a
-  smpVP v = smpDecodeV v <$?> smpP
-```
-
-The version will be passed from currently agreed version, it may only change when message is received, not when message is sent. The version will not be extracted from the encoding itself as it happens now in ratchet encodings.
-
-## Various options how the problem can be simplified
-
-1. Do not support connection downgrade once both devices upgraded. If applied to all existing connections then it is a bad option, as it would disrupt some important conversations.
-
-2. Do not provide ability to opt-in into PQ encryption until v5.7 where it will be rolled out automatically. That is also suboptimal, as it won't allow announcing technology design and have testing outside of the team devices.
-
-3. The logic explained above where connection upgrade and downgrade is possible and applied to all existing connections if both parties consent to it. There are these important downsides:
-  - complexity of this logic
-  - regression risks when this logic is removed.
-  - some non-coordinated upgrades of existing, potentially important conversations, simply because two users opt-in into the experiment without any expectation that another side also opts-in.
-
-4. Apply upgrade/downgrade logic and enable PQ encryption as opt-in, based on the toggle in the UX, only for the new connections. This seems the least risky, and also simpler than option 3, as it would only apply to the new connections, and both users will have to enable experimental toggle prior to connecting.
-
-Option 4 seems the best trade-off, and has these sub-options regarding where it is controlled:
-a) in chat based on connection flag. Chat will pass PQ options only to connections that were created when experimental option was enabled.
-b) in agent - there will be additional logic to ignore PQ option for existing connections.
-c) both in chat and in agent.
-
-Option 4a seems better, as it would:
-- simplify agent code
-- minimise required changes when releasing v5.7 (as we do want that all direct and small groups connections migrate to PQ encryption at the time, without any toggles)
-- allow tests for connection upgrade in the currect code.

rfcs/2024-03-20-server-metadata.md

@@ -1,130 +0,0 @@
-# Relay metadata and SimpleX network decentralization
-
-## Problem
-
-Currently, the clients configure/choose which servers to use, but they cannot see who operates them, in which geography and hosting provider, what is the server source code (in case it was modified from the reference implementation we provide) and also any administrative and feedback contacts.
-
-Further, we currently use simplex.chat domain to host group links, and as diversity of the groups grows it is beginning to require managing feedback from the users about groups. It is important that this feedback is directed to relay owners and not to us, in case they are not our relays, as we are simply providing software here.
-
-We also need to make it much easier to access administrative actions - e.g., if the relay owner wants to block some address based on the feedback, they should be able to do so effectively. While freedom of speech of users is important the autonomy and sovereignty of relay operators allowing them to decide what they want or don't want to host, irrespective of the reasons, is as important - public relays constitute a public space rather than a service, and while there is no authentication or authorization required to use them, the relay owners should be able to decide their conditions and limitations of use, as is the case for any public space.
-
-## Why it is important
-
-1. We are building network and not a service, so contrary to the traditional approach when service collects users metadata and conceals its own, it appears important to do the opposite - expose all relay metadata that may have any effect on users privacy and security and provide access to this metadata with the minimal friction, via the app UI.
-2. We need to remove the only remaining bit of centralization - using simplex.chat website to show the QR code and help new users onboarding - this role can be delegated to the relays.
-3. We need to make it easy for the users to submit feedback and to the relay operators to manage that feedback. That includes ourselves, as relay operators, and also any other person or organization that operates public relays.
-4. It is important to stress the requirement of AGPLv3 license to provide access to the source code to the relay users, as any code modifications might undermine user privacy and security and must be made transparent to the relay users.
-
-While this document is not the end of the journey to decentralize the network, it's an important first step.
-
-## Proposed solution
-
-The proposed solution consists of two parts:
-
-- communicate server metadata via protocol, so it can be observed by the clients.
-- create home page for the relays, with all the same metadata.
-- create invitation and address links in the same domain name as the relay.
-
-The latter point is important so it is clear to the users who operates and owns the relay and where the access point to the content or group is hosted. Even though simplex.chat domain is never accessed by the app, and the meaningful part of the address is never sent to the page hosting server, it creates an impression of centralization, and some dependency on simplex.chat domain for anything other that showing the link QR code.
-
-Moving invitation links to the domain of the relay (primary relay, in case the link has redundancy) will both clarify relay ownership, solve the incorrect mis-perception of centralization, remove the dependency on simplex-chat domain without any user effort, and provides the means to submit content complaints to the relay operators (should they wish to receive them, which seems reasonable for large public relays, but may be unnecessary for private relays where unidentified parties cannot create links).
-
-## Solution details
-
-Extend server INI file with information section:
-
-```
-[INFORMATION]
-# Please note that under AGPLv3 license conditions you MUST make
-# any source code modifications available to the end users of the server.
-# LICENSE: https://github.com/simplex-chat/simplexmq/blob/stable/LICENSE
-# Not doing so would constitute a license violation.
-# Declaring an incorrect information here amounts to a fraud.
-# The license holders reserve the right to prosecute missing or incorrect
-# information about the server source code to the fullest extent permitted by the law.
-# The server will show warning on start if this field is absent
-# and will not launch from v6.0 until this field is added.
-# If any other information field is present, source code property also MUST be present.
-source_code: https://github.com/simplex-chat/simplexmq
-
-# Declaring all below information is optional, any of these fields can be omitted.
-# Declaring an incorrect information here would amount to a fraud.
-
-# We should split this document to the model one, where specific parameters will be external to the document,
-# and specific to us, so that relay operators can adopt our recommended policy and publish any amendments separately.
-usage_conditions: https://github.com/simplex-chat/simplex-chat/blob/_archived-ep/ios-file-provider/PRIVACY.md
-# condition_amendments: link
-
-server_country: SE
-operator: SimpleX Chat Ltd.
-operator_country: GB # operator country
-website: https://simplex.chat
-admin_simplex: administrative SimpleX address
-admin_email: chat@simplex.chat
-admin_pgp: PGP key
-complaints_simplex: SimpleX address for feedback, comments and complaints
-complaints_email: complaints@simplex.chat
-complaints_pgp: PGP key
-hosting: Linode / Akamai Inc.
-hosting_country: US
-```
-
-Server home page would show whether queue creation is allowed and/or password protected, server retention policy (e.g., preserve messages on restart or not, and persist connections or not).
-
-Server queue address/contact pages will optionally, provide the UI to submit feedback, comments and complaints directly from the web page (not an MVP, initially we would simply show addresses for feedback, and, probably, create link that opens in the app with pre-populated message, and we could also use this addresses defined in server meta-data to submit feedback from inside of the app - it's also out of MVP scope).
-
-If server is available on .onion address, the web pages would show "open via .onion" in Tor browser.
-
-Extend server handshake header with these information fields:
-
-```haskell
-data ServerHandshake = ServerHandshake
-  { smpVersionRange :: VersionRangeSMP,
-    sessionId :: SessionId,
-    -- pub key to agree shared secrets for command authorization and entity ID encryption.
-    authPubKey :: Maybe (X.CertificateChain, X.SignedExact X.PubKey),
-    -- ^^ existing fields
-    -- vv new field that will be sent as length-prefixed JSON in the handshake
-    information :: Maybe ServerInformation
-  }
-
-data ServerInformation = ServerInformation
-  { config :: ServerPublicConfig,
-    info :: ServerPublicInfo
-  }
-
--- based on server configuration
-data ServerPublicConfig = ServerPublicConfig
-  { persistence :: SMPServerPersistenceMode,
-    messageExpiration :: Int,
-    statsEnabled :: Bool,
-    newQueuesAllowed :: Bool,
-    basicAuthEnabled :: Bool -- server is private if enabled
-  }
-
--- based on INFORMATION section of INI file
-data ServerPublicInfo = ServerPublicInfo
-  { sourceCode :: Text, -- note that this property is not optional, in line with AGPLv3 license
-    conditions :: Maybe ServerConditions,
-    operator :: Maybe Entity,
-    website :: Maybe Text,
-    adminContacts :: Maybe ServerContactAddress,
-    complaintsContacts :: Maybe ServerContactAddress,
-    hosting :: Maybe Entity,
-    serverCountry :: Maybe Text
-  }
-
-data ServerPersistenceMode = SMPMemoryOnly | SPMQueues | SPMQueuesMessages
-
-data ServerConditions = ServerConditions {conditions :: Text, amendments :: Maybe Text}
-
-data Entity = Entity {name :: Text, country :: Maybe Text}
-
-data ServerContactAddress = ServerContactAddress
-  { simplex :: Maybe Text,
-    email :: Maybe Text, -- it is recommended that it matches DNS email address, if either is present
-    pgp :: Maybe Text
-  }
-```
-
-This extended server information will be stored in the chat database every time it changes and shown in the UI of the server configuration.

rfcs/2024-03-28-xftp-version.md

@@ -1,120 +0,0 @@
-# XFTP version agreement
-
-## Problem
-
-XFTP is using HTTP2 protocol for encoding requests and responses.
-Unlike SMP which has a connection handshake initiated by a server and signals available versions XFTP/HTTP2 is almost entirely client-driven.
-So, a client can only try to guess which protocol versions are supported by a server by sending a probe/hello request first.
-Determining the endpoint for such a request is an implicit version agreement by itself.
-Sending such a request to an old server would error out and requiring it from old clients would break them.
-
-## Solution
-
-The TLS layer used by the XFTP server has an optional [ALPN](https://datatracker.ietf.org/doc/html/rfc7301) extension which allows the client and server to negotiate protocols and store the decision in TLS session context.
-Unless a client and a server run ALPN-aware versions, they would default to the old "unversioned" protocol.
-
-TLS extension content is a 65kb chunk, but ALPN standard breaks it into 254b-sized chunks making it unusable for things like key exchange.
-The exchange is still client-driven: the client proposes a list, and then a server callback picks one.
-In effect, this makes it usable only to signal that some application-level handshake is desired and supported.
-
-## Implementation
-
-ALPN can be used to negotiate for any TLS-based protocol, but the description will focus on XFTP.
-
-TransportClientConfig gets a new `alpn :: Maybe [ALPN]` field so a TLS transport can use it during TLS client creation.
-XFTP client sets it to `Just ["xftp/1"]`.
-The exact value is not important as long it is in agreement with the server side, but ALPN RFC insists on it being an IANA-registered identifier.
-
-XFTP server sets `onALPNClientSuggest` TLS hook to pick the protocol when it is provided.
-The `tls` library treats SHOULD from the RFC as MUST and does a client-side check that the server responded with one of the client-proposed protocols.
-
-Upon connection, transport implementation invokes `getNegotiatedProtocol` and stores it in `tlsALPN :: Maybe ALPN` field of transport context.
-HTTP2 transport implementation using `withHTTP2` passes negotiated "protocol" to client and server setup callbacks where they store it in their respective wrappers along with TLS session ID.
-A server request handler then knows by looking at the `sessionALPN` if it should require a "handshake" request first.
-A client code that got HTTP2Client with `sessionALPN` set knows if it has to proceed with handshake request.
-A handshake request still has to be initiated by a client, so it should be kept minimal, just enough data to pass the initiative to a server.
-A reply to that initial request should contain a server version range for the client to pick.
-A client then commits to a version, sending its part of a handshake.
-
-In the future ALPN negotiation can be dropped in favor of mandatory handshakes or used to signal further handshake schemes.
-
-The XFTP handshake data types and validation code are cloned from SMP.
-Currently they carry version information and session authentication parameters.
-Authentication parameters made mandatory as this exchange is guarded by the handshake version.
-
-### Server side
-
-`runHTTP2Server` callback used by `xftpServer` should get access to the session state to track handshakes.
-A local `TMap SessionId Handshake` is enough to switch request handlers.
-The HTTP2 server framework is extended with a way to signal client disconnection to remove sessions from this map.
-
-The `Handshake` type mimics implicit state in stream based handshakes of SMP and NTF.
-
-```haskell
-data Handshake
-  = HandshakeSent C.PrivateKeyX25519 -- server private key that will be merged with client public in `THandleAuth`
-  | HandshakeAccepted THandleAuth VersionXFTP -- session steady state after handshakes
-```
-
-An HTTP2 request without ALPN is treated as legacy and requires no session entry.
-Its `Request`s are marked with `THandleParams {thVersion = VersionXFTP 1, ..}`.
-
-An HTTP2 request with ALPN requires a session lookup.
-- A lack of entry indicates that a client must send an empty request, to which the server replies with its "server handshake" block and stores its private state in `HandshakeSent`.
-- If the session entry contains `HandshakeSent`, then the only valid request content is the "client handshake" block.
-  The server validates client handshake (in the same way as SMP) and stores authentication and version in `HandshakeAccepted`
-- If the session entry contains `HandshakeAccepted`, then the server just passes it to `THandleParams`.
-
-### Client side
-
-`getXFTPClient` tweaks its transport config to include the ALPN marker and then checks if the client got its `sessionALPN` value.
-If there's a value set, it then sends an initial block and checks out the server handshake in response.
-After validation, it sends "client handshake" request to finish version negotiation.
-
-```haskell
-let tcConfig = (transportClientConfig xftpNetworkConfig) {alpn = Just ["xftp/1"]}
--- ...
-http2Client <- liftEitherError xftpClientError $ getVerifiedHTTP2Client -- ...
-thVersion <- case sessionALPN http2Client of
-  Nothing -> pure $ VersionXFTP 1
-  Just proto -> negotiate http2Client proto
-```
-
-The resulting `XFTPClient` then contains a negotiated version and can be used to send transmissions with a more recent encoding.
-
-## Block encoding
-
-### Client Hello (request)
-
-A request with an empty body and no padding.
-
-### Server handshake (response)
-
-SMP-encoded and padded to `xftpBlockSize` (~16kb).
-
-```haskell
-data XFTPServerHandshake = XFTPServerHandshake
-  { xftpVersionRange :: VersionRangeXFTP,
-    sessionId :: SessionId, -- validated by client against TLS unique
-    authPubKey ::
-      ( X.CertificateChain, -- fingerprint validated by client against pre-shared hash
-        X.SignedExact X.PubKey -- signature validated by client against server key from TLS
-      )
-  }
-```
-
-### Client handshake (request)
-
-SMP-encoded and padded to `xftpBlockSize` (~16kb).
-
-```haskell
-data XFTPClientHandshake = XFTPClientHandshake
-  { xftpVersion :: VersionXFTP,
-    keyHash :: C.KeyHash, -- validated by server against its own cert fingerprint
-    authPubKey :: C.PublicKeyX25519
-  }
-```
-
-### Server confirmation (response)
-
-A response with an empty body and no padding.

rfcs/done/2022-03-22-nofication-server.md

@@ -1,91 +0,0 @@
-# Notification server
-
-## Background and motivation
-
-SimpleX Chat clients should receive message notifications when not being online and/or subscribed to SMP servers.
-
-To avoid revealing identities of clients directly to SMP servers via any kind of push notification tokens, a new party called SimpleX Notification Server is introduced to act as a service for subscribing to SMP server queue notifications on behalf of clients and sending push notifications to them.
-
-## Proposal
-
-TCP service using the same TLS transport as SMP server, with the fixed size blocks (256 bytes?) and the following set of commands:
-
-### Protocol
-
-#### Create subscription
-
-Command:
-
-`%s"CREATE " ntfSmpQueueURI ntfPrivateKey token subPublicKey`
-
-Response:
-
-`s%"OK"`
-
-#### Check subscription status
-
-Command:
-
-`%s"CHECK " ntfSmpQueueURI`
-
-Response:
-
-```abnf
-statusResp = %s"STAT " status
-status = %s"ERR AUTH" / "ERR SMP AUTH" / %s"ERR SMP TIMEOUT" / %s"ACTIVE" / %s"PENDING"
-```
-
-#### Update subscription device token
-
-Command:
-
-`%s"TOKEN " ntfSmpQueueURI token`
-
-Response:
-
-`s%"OK" / %s"ERR"`
-
-#### Delete subscription (e.g. when deleting the queue or moving to another notification server)
-
-Command:
-
-`%s"DELETE " SP ntfSmpQueueURI`
-
-Response:
-
-`s%"OK" / %s"ERR"`
-
-### Agent schema changes
-
-See [migration](../src/Simplex/Messaging/Agent/Store/SQLite/Migrations/M20220322_notifications.hs)
-
-### Agent code
-
-```haskell
-data NtfOptions = NtfOptions
-  { ntfServer :: Server, -- same type as for SMP servers, probably will be renamed
-    ntfToken :: ByteString,
-    ntfInitialCheckDelay :: Int, -- initial check delay after subscription is created, seconds
-    ntfPeriodicCheckInterval :: Int -- subscription check interval, seconds
-  }
-
-data AgentConfig = AgentConfig {
-  -- ...
-  initialNtfOpts :: Maybe NtfOptions
-  -- ...
-  }
-
-data AgentClient = AgentClient {
-  -- ...
-  ntfOpts :: TVar (Maybe NtfOptions)
-  -- ...
-  }
-```
-
-A configuration parameter `initialNtfOpts :: Maybe NtfOptions` - if it is set or changes the agent would automatically manage subscriptions as SMP queues are subscribed/created/deleted and as the token or server changes.
-
-There will be a method to update notifications configuration in case token or server changes.
-
-All subscriptions will be managed in a separate subscription management loop, that would always take the earliest un-updated subscription that requires some action (ntf_sub_action column) and perform this action - the table of subscription would serve both as the table of existing subscriptions and required actions.
-
-E.g. if the queue is subscribed and there is no notification subscription, it will be created in the table with "create" action, and the loop would create it and schedule "check" action on it.

rfcs/done/2022-06-05-smp-notifications.md

@@ -1,34 +0,0 @@
-# SMP protocol changes to support push notifications on iOS
-
-## Problem
-
-There are already commands/responses to allow subscriptions to message notifications - NKEY/NID, NSUB/NMSG. These commands will be used by SMP agent (NKEY/NID) and by notification server (NSUB/NMSG) to have message notifications delivered to notification server, so it can forward them to APNS server using device token.
-
-There are two remaining problems that these commands do not solve.
-
-1. Receiving the message when notification arrives.
-
-iOS requires creating a bundled notification service extension (NSE) that runs in isolated container and, if we were to use the existing commands, would have SMP subscription to the same SMP servers as the main app, triggering resubscriptions every time the message reception switches between the app and NSE. That would cause a substantial increase in traffic and battery consumption to the users.
-
-2. Showing notifications for service messages.
-
-Users do not expect to see notifications for every single SMP messages - e.g., we currently do not show notifications when messages are edited and deleted, and users do not expect them. NSE requires that for every received push notification there should be some notification shown to the users. So only we would have to show a notification for message deletes and updates, we would have to show it for all service messages - e.g. user accepted file invitation, or file transmission has started, contact profile updates and so on.
-
-We considered differentiating whether notifications are sent per queue, from the recipient side, so we do not send notifications for file queues. But it seems insufficient, particularly if we add such features as message receipts, status updates, etc.
-
-## Proposal
-
-1. To retrieve messages when push notifications arrive, we will add 2 SMP commands:
-
-- GET: retrieve one message from the connection. Resonse could be either MSG (the same as when MSG is delivered, but with the correlation id) or GMSG (to simplify processing) – TBC during implementation. If message is not available, the response could be ERR NO_MSG
-- ACK or GACK: acknowledge that the message was processed by the client and can be removed - TBC which one is better. The response is OK or ERR NO_MSG if there was nothing to acknowledge (same as with ACK now)
-
-This would allow receiving a single message from the queue without subscription, this way avoiding that the main app is unsubscribed from the queue.
-
-2. The only way to avoid showing unnecessary notifications (status updates, service messages, etc.) is to avoid sending them. That requires instructing SMP server whether notification should be sent both per queue, from the recipient side, and per message - from the sender side. So the notification would only be sent if the queue has them enabled (via NKEY command) and the sender includes an additional flag in SEND command. The same flag should be included into MSG, so when the message is retrieved with GET command, the client knows, on the agent or chat level (or both), whether this message should have notification shown to the user, and if not - retrieve the next one(s) as well.
-
-This is a substantial change to SMP protocol, that would require client and server upgrade for notifications to be supported.
-
-We should consider whether to increase the SMP protocol version number to 2, so that the new clients can connect to the old clients but without notifications, or we could keep the old commands in the protocol and instead of adding flags to the existing commands, create new commands.
-
-We can also consider making commands extensible so that the new flags can be added (and ignored by parsers if not supported) to at least some existing commands.

rfcs/done/2022-06-13-db-sync.md

@@ -1,75 +0,0 @@
-# DB access and processing messages for iOS notification service extension
-
-## Problem
-
-The only way to receive/process notificaitons is via a separate NSE process that requires a concurrent DB and network access.
-
-SQLite concurenncy does not work, so we need to sync database access.
-
-The problem is complex, as we do not directly control db access from the app, it can be triggered by the message arriving and it may fail to complete in case the app is suspended in the background.
-
-So we need to prevent db access from starting when we know the app is about to be suspended.
-
-The last problem is how to receive and process messages in NSE - should it use recently added GET command or should it subscribe to the connections that receive messages and process messages normally.
-
-To summarize, 2 problems need to be solved:
-
-1. sync db access between 2 (or more, if we add share extension) processes
-
-2. prevent access from starting when the process is due to suspend, only complete operations.
-
-3. Receiveing and processing agent messages in NSE
-
-## Proposed solution
-
-For problem 1, we can use Posix semaphores from our core code, in the same bracket that manages database connection - it would wait for semaphore to be free and unlock it once the db operation is complete.
-
-For problem 2, we need to communicate from the app when it goes to the background to prevent database access starting and completing before the suspension. This would set some `aboutToSuspend` STM flag (or the opposite) that would prevent operations from progressing (using STM retry, that would block until the flag has the value allowing operation to progress).
-
-Several possibilities can be considered:
-
-- use this flag in the bracket that provides DB connections. While simple, it may lock some operations in the middle and may also lead to the situation when network operation succeeds but database access was blocked, and the database is not updated.
-- use this flag to stop network operations that would require database updates - like sending messages, subscriptions and ACK - all these operations would require database access once they succeed.
-- use two flags, for both cases above, but set them at different times since going to background - block new network operations as soon as the app goes to the background and block database access once the app is about to be suspended.
-
-The last option seems more robust. To do it, there will be an api allowing the app to communicat its phase:
-
-- app going to the background would trigger blocking new network operations and start a new background task - `background` phase.
-- background task receiving completion warning, or, maybe, some time after it is started - probably 20 seconds - or whatever happens earlier - would trigger call blocking db access - `suspended` phase.
-- app becoming active would trigger unblocking both flags - `active` phase.
-
-`/_app phase <phase>` where `phase` can be one of the above values.
-
-NSE would also use the same phases:
-
-- sending `active` when it is started (the process starts as active, but it is possible that the new notification arrives to the same process, after the previous one sent background/suspension)
-- sending `background + suspended` (or `suspended` should set both flags) once it is finished processing the notification, provided no new notification arrived and started processing - this should be tracked in NSE.
-
-For problem 3, NSE can do one of the following:
-
-- use SUB and process messages normally - the downside is that the app will have to resubscribe and it has to be tracked.
-- use GET and process messages by pushing them through the processing function - the downside it that a rewiring of message processing is needed.
-- use GET but deliver messages through the same queue as when they arrive normally (in which case getMessage agent function should not return the message, but will return a flag showing whether the message was received, or, possibly, or, possibly will return a message but the message would also be sent to the queue?).
-- process messages in agent manually and in chat via the queue.
-
-One of the downside of GET is that it requires calling GET again after ACK. We could have two variants of ACK (or additional ACK parameter) - one that never delivers a new message, and another one that does. In this case, if get needs to process the next message (when the current one has no notification flag), it can call ACK that delivers the next message. But, it is probably a premature optimization, and having general support of batched commands would add more value.
-
-Additional problem is concurrency in NSE - if the new notification from the same queue arrives before the current one finishes processing in the same process one of the following can happen:
-
-- the 2nd notification naively call GET and receives the same message.
-- the 2nd notification waits until the first finished processing, in which case it can run out of time.
-
-The problem is that the app won't know it's the same queue, as nId is encrypted, so the agent should handle this scenario when the new call to getMessage is made before the previous one finished processing, and differentiate between calls made for additional messages (possibly, getMessage should include previous message ID, if it is available) and the first call.
-
-EDIT: GETs have to be sent from UI to chat and from chat to agent as function calls, but the agent will have to queue get calls to make sure they return different messages. GET call would return message flags (incl. notification flag), so that the UI can send the next GET if needed without waiting.
-
-Considered alternative: include notification content in the message and have NSE only perform decryption, without any network IO. In this case notification content would be in SEND and in NMSG, e2e encrypted.
-
-While promising, as it solves network coordination issues and makes GET unnecessary, it creates mutliple other problems, so it was rejected:
-
-- message content is exposed to centralized ntf and apns servers, creating additional attack vector.
-- it adds complexity in security critical parts of the stack - double ratchet encryption, as it requires either storing message keys and using different IVs for notifications, or initializing completely separate ratchet for notifications content.
-- it reduces the size of the message.
-- it makes user experience worse, as:
-  - it would not accelerate handshake for new contacts and for file delivery - this approach only works for content messages.
-  - it would open the app without the new messages - the users would have to wait until the messages are received. It is also bad for "security optics" - the users might think that the message content was exposed to notifications.

rfcs/done/2022-06-13-db-sync.mmd

@@ -1,61 +0,0 @@
-sequenceDiagram
-  participant M as iOS message<br>notification
-  participant S as iOS system
-  participant N as iOS NSE
-  participant U as iOS UI
-  participant C as Core chat
-  participant A as Core agent
-
-  M ->> N: notification
-  S ->> N: get app pref
-  note over N: ignore,<br>app is active
-
-  note over M, A: app going to background
-  S ->> U: phase: background<br>(possibly, "will" method)
-  U ->> S: set app pref "pausing"
-  U ->> C: /_app phase paused, result CRCmdOk
-  C ->> A: pauseAgent<br>(no new network IO)
-  M ->> N: notification
-  S ->> N: get app pref
-  note over N: wait/poll for<br>"paused"/"suspending"/"suspended"<br>event/pref
-  A ->> C: event "IO paused"<br>(after in-flight op completed)<br>PHASE PAUSED
-  C ->> U: event "IO paused" (CRAppPaused)
-  U ->> S: set shared pref "paused"
-
-  note over M, A: process notification
-  M ->> N: notification
-  S ->> N: get app pref<br>continue if<br>"paused"/"suspending"/"suspended"
-  N ->> S: set NSE pref "active"
-  N ->> C: /_get message
-  C ->> A: getMessage
-  A ->> C: msg flags
-  C ->> N: msg flags
-  note over N: get messages<br>until notification flag set
-  A ->> C: MSG/CONF/INFO
-  C ->> N: some event
-  N ->> S: set NSE pref "completed"
-  N ->> S: show notification
-
-  note over M, A: app about to be suspended<br>(or 15-20 sec after background)
-  S ->> U: background task notice
-  U ->> S: set app pref "suspending"
-  U ->> C: /_app phase suspended, response ok
-  C ->> A: suspendAgent<br>(no new DB)
-  A ->> C: event "DB paused"<br>(after in-flight op completed)<br>PHASE SUSPENDED
-  C ->> U: event "DB paused" (CRAppSuspended)
-  U ->> S: set app pref "suspended"
-
-  note over M, A: app about to be activated
-  S ->> U: phase: active<br>(or inactive?)<br><br>(possibly, "will" method)
-  S ->> U: get NSE pref
-  U ->> S: set app pref "activating"
-  alt nse active?
-    U ->> C: /_app phase inactive
-    note over U: poll/wait till NSE pref is "completed"
-  end
-
-  U ->> C: /_app phase active (response result)
-  C ->> A: activateAgent<br>(allow IO/DB)
-  A ->> C: result ()
-  C ->> U: CRCmdOk
-  U ->> S: set app pref "active"

rfcs/done/2022-07-22-access-via-tor.md

@@ -1,26 +0,0 @@
-# Accessing SMP servers via Tor
-
-## Problem
-
-While SMP protocol is focussed on minimizing application-level meta-data by using pair-wise identifiers instead of user profile identifiers, it is important for many users to protect their IP addresses.
-
-Further, even if IP addresses are hidden by onion routing, clients should be able to choose to use a separate TCP connection to subscribe to each queue, even though it increases traffic and battery consumption, as otherwise the servers can observe multiple queues accessed by the same client.
-
-## Solution and requirements
-
-While some users may want to access SMP servers via tor, some other users (even their contacts) may want the opposite - e.g., if they use the network when accessing Tor would be suspicious (or blocked).
-
-Therefore we need to support the connections when one of the user accesses the same server via Tor (and, possibly, via onion address), while another user accesses this server without Tor.
-
-At the same time the user accessing the server via Tor may not want that their contacts access this server without Tor, and it also may be possible that the server is not available under a normal (not .onion) address.
-
-The proposed options for connecting via Tor are:
-
-1. Access servers via Socks proxy: no/yes (specify port?)
-2. Use .onion addresses: no/when available/warn/always
-3. Require senders to use .onion addresses: yes/no
-4. Use separate TCP connection for each queue
-
-While it should be possible for SMP servers to have two addresses (with and without Tor), the queues should only use one server address - if the queue started being accessed via .onion address it should not be possible to access it via a normal address. Queue addresses in connection invitations should support dual server addresses (when senders are not required ot use .onion address).
-
-At the same time, the queue with the normal addresses can be accessed with and without Tor, depending on the current device settings.

rfcs/done/2022-08-14-queue-rotation.md

@@ -1,53 +0,0 @@
-# SMP queue rotation and redundancy
-
-## Problem
-
-1. Long term usage of the queue allows the servers to analyze long term traffic patterns.
-
-2. If the user changes the configured SMP server(s), the previously created contacts do not migrate to the new server(s).
-
-3. Server can lose messages.
-
-## Solution
-
-Additional messages exchanged by SMP agents to negotiate addition and removal of queues to the connection.
-
-This approach allows for both rotation and redundancy, as changing queue will be done be adding a queue and then removing the existing queue.
-
-The reason for this approach is that otherwise it's non-trivial to switch from one queue to another without losing messages or delivering them out of order, it's easier to have messages delivered via both queues during the switch, however short or long time it is.
-
-### Messages
-
-Additional agent messages required for the protocol:
-
-    QADD_ -> "QA"
-    QKEY_ -> "QK"
-    QUSE_ -> "QU"
-    QTEST_ -> "QT"
-
-`QADD`: add the new queue address(es), the same format as `REPLY` message, encoded as `QA`.
-
-`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), encoded as `QK`.
-
-`QUSE`: instruct the sender to use the new queue with sender's queue ID as parameter, encoded as `QU`.
-
-`QTEST`: send test message to the new connection, encoded as `QT`. Any other message can be sent if available to continue rotation, the absence of this message is not an error. Once this message is successfully sent the sender will stop using the old queue. Once this message (or any other message in the new queue) is received, the recipient will stop using the old queue and delete it.
-
-### Protocol
-
-```
-participant A as Alice
-participant B as Bob
-participant R as Server that has A's receive queue
-participant S as Server that has A's send queue (B's receive queue)
-participant R' as Server that hosts the new A's receive queue
-
-A ->> R': create new queue
-A ->> S ->> B: QADD (R'): snd address of the new queue(s)
-B ->> S(R) ->> A: QKEY (R'): sender's key for the new queue(s) (to avoid the race of SMP confirmation for the initial exchange)
-A ->> S(R'): secure new queue
-A ->> S ->> B: QUSE (R'): instruction to use new queue(s)
-B ->> S(R') ->> A: QTEST
-A ->> S(R): DEL: delete the old queue
-B ->> S(R') ->> A: send all new messages to the new queue
-```

rfcs/done/2022-11-11-smp-basic-auth.md

@@ -1,27 +0,0 @@
-# SMP Basic Auth
-
-## Problem
-
-Users who host their own servers do not want unknown people to be able to create messaging queues on their servers after discovering server address in groups or after making a connection. As the number of self-hosted servers is growing it became more important than it was when we excluded it from the original design.
-
-## Solution
-
-Single access password that can be optionally included in server address that is passed to app configuration. It will not be allowed in the existing contexts (and parsing will fail), to avoid accidentally leaking it. Server address with password will look this way: `smp://fingerprint:password@hosts`
-
-## Implementation plan
-
-1. A separate type to include server and password, so it can only be used where allowed.
-
-2. Server password to create queues will be configured in TRANSPORT section of INI file, as `create_password` parameter.
-
-3. The password will only be required in server configuration/address to create queues only, it won't be required for other receiving queue operations on already existing queues.
-
-4. If new command is attempted in the session that does not allow creating queues, the server will send `ERR AUTH` response
-
-5. Passing password to the server can be done in one of the several ways, we need to decide:
-
-  - as a parameter of NEW command. Pros: a local change, that only needs checking when queue is created. Cons: protocol version change.
-  - as a separate command AUTH. Pros: allows to include additional parameters and potentially be extended beyond basic auth. Cons: more complex to manage server state, can be more difficult syntax in the future, if extended.
-  - as part of handshake (we currently ignore the unparsed part of handshake block, so it can be extended). Pros: probably, the simplest, and independent of the commands protocol – establishes create permission for the current session. Cons: the client won't know about whether it is able to create the queue until it tries (same as in case 1).
-
-  My preference is the last option. As a variant of the last option, we can add a server response/message that includes permission to create queues - it will only be sent to the clients who pass credential in handshake - that might simplify testing server connection (we currently do not do it). It might be unnecessary, as we could simply create and delete queue in case credential is passed as part of testing connection (and even sending a message to it).

scripts/docker/entrypoint-smp-server

@@ -1,48 +0,0 @@
-#!/usr/bin/env sh
-confd='/etc/opt/simplex'
-logd='/var/opt/simplex/'
-
-# Check if server has been initialized
-if [ ! -f "${confd}/smp-server.ini" ]; then
-  # If not, determine ip or domain
-  case "${ADDR}" in
-    '') printf 'Please specify $ADDR environment variable.\n'; exit 1 ;;
-    *[a-zA-Z]*)
-      case "${ADDR}" in
-        *:*) set -- --ip "${ADDR}" ;;
-        *) set -- -n "${ADDR}" ;;
-      esac
-      ;;
-    *) set -- --ip "${ADDR}" ;;
-  esac
-
-  # Optionally, set password
-  case "${PASS}" in
-    '') set -- "$@" --no-password ;;
-    *) set -- "$@" --password "${PASS}" ;;
-  esac
-
-  # And init certificates and configs
-  smp-server init -y -l "$@"
-fi
-
-# Backup store log just in case
-#
-# Uses the UTC (universal) time zone and this
-# format: YYYY-mm-dd'T'HH:MM:SS
-# year, month, day, letter T, hour, minute, second
-#
-# This is the ISO 8601 format without the time zone at the end.
-#
-_file="${logd}/smp-server-store.log"
-if [ -f "${_file}" ]; then
-  _backup_extension="$(date -u '+%Y-%m-%dT%H:%M:%S')"
-  cp -v -p "${_file}" "${_file}.${_backup_extension:-date-failed}"
-  unset -v _backup_extension
-fi
-unset -v _file
-
-# Finally, run smp-sever. Notice that "exec" here is important:
-# smp-server replaces our helper script, so that it can catch INT signal
-exec smp-server start +RTS -N -RTS
-

scripts/docker/entrypoint-xftp-server

@@ -1,50 +0,0 @@
-#!/usr/bin/env sh
-confd='/etc/opt/simplex-xftp'
-logd='/var/opt/simplex-xftp'
-
-# Check if server has been initialized
-if [ ! -f "${confd}/file-server.ini" ]; then
-  # If not, determine ip or domain
-  case "${ADDR}" in
-    '') printf 'Please specify $ADDR environment variable.\n'; exit 1 ;;
-    *[a-zA-Z]*)
-      case "${ADDR}" in
-        *:*) set -- --ip "${ADDR}" ;;
-        *) set -- -n "${ADDR}" ;;
-      esac
-      ;;
-    *) set -- --ip "${ADDR}" ;;
-  esac
-
-  # Set quota
-  case "${QUOTA}" in
-    '') printf 'Please specify $QUOTA environment variable.\n'; exit 1 ;;
-    *GB) QUOTA="$(printf ${QUOTA} | tr '[:upper:]' '[:lower:]')"; set -- "$@" --quota "${QUOTA}" ;;
-    *gb) set -- "$@" --quota "${QUOTA}" ;;
-    *) printf 'Wrong format. Format should be: 1gb, 10gb, 100gb.\n'; exit 1 ;;
-  esac
-
-  # Init the certificates and configs
-  xftp-server init -l -p /srv/xftp "$@"
-fi
-
-# Backup store log just in case
-#
-# Uses the UTC (universal) time zone and this
-# format: YYYY-mm-dd'T'HH:MM:SS
-# year, month, day, letter T, hour, minute, second
-#
-# This is the ISO 8601 format without the time zone at the end.
-#
-_file="${logd}/file-server-store.log"
-if [ -f "${_file}" ]; then
-  _backup_extension="$(date -u '+%Y-%m-%dT%H:%M:%S')"
-  cp -v -p "${_file}" "${_file}.${_backup_extension:-date-failed}"
-  unset -v _backup_extension
-fi
-unset -v _file
-
-# Finally, run xftp-sever. Notice that "exec" here is important:
-# smp-server replaces our helper script, so that it can catch INT signal
-exec xftp-server start +RTS -N -RTS
-

scripts/main/simplex-servers-stopscript

@@ -1,30 +0,0 @@
-#!/usr/bin/env sh
-set -eu
-
-path_conf_var="/var/opt"
-path_conf_smp="$path_conf_var/simplex"
-path_conf_xftp="$path_conf_var/simplex-xftp"
-path_conf_storelog_smp="$path_conf_smp/smp-server-store.log"
-path_conf_storelog_xftp="$path_conf_xftp/file-server-store.log"
-date="$(date -u '+%Y-%m-%dT%H:%M:%S')"
-
-backup_smp() {
- if [ -e "$path_conf_storelog_smp" ]; then
-  cp "$path_conf_storelog_smp" "${path_conf_storelog_smp}.${date:-date-failed}"
- fi
-}
-
-backup_xftp() {
- if [ -e "$path_conf_storelog_xftp" ]; then
-  cp "$path_conf_storelog_xftp" "${path_conf_storelog_xftp}.${date:-date-failed}"
- fi
-}
-
-if [ "$1" = 'smp-server' ]; then
- backup_smp
-elif [ "$1" = 'xftp-server' ]; then
- backup_xftp
-else
- backup_smp
- backup_xftp
-fi

scripts/main/simplex-servers-uninstall

@@ -1,23 +0,0 @@
-#!/usr/bin/env sh
-set -eu
-
-GRN='\033[0;32m'
-RED='\033[0;31m'
-NC='\033[0m'
-
-if [ "$(id -u)" -ne 0 ]; then
-  printf "This script is intended to be run with root privileges. Please re-run script using sudo."
-  exit 1
-fi
-
-printf "${RED}This action will permanently remove all configs, directories, binaries from Installation Script. Please backup any relevant configs if they are needed.${NC}\n\nPress ${GRN}ENTER${NC} to continue or ${RED}Ctrl+C${NC} to cancel installation"
-read ans
-
-systemctl stop smp-server
-systemctl stop xftp-server
-
-rm -rf /var/opt/simplex /etc/opt/simplex /var/opt/simplex-xftp /etc/opt/simplex-xftp /srv/xftp /etc/systemd/system/smp-server.service /etc/systemd/system/xftp-server.service /usr/local/bin/smp-server /usr/local/bin/xftp-server /usr/local/bin/simplex-servers-update /usr/local/bin/simplex-servers-uninstall
-
-userdel smp && userdel xftp
-
-printf "Uninstallation is complete! Thanks for trying out SimpleX!\n"

scripts/main/simplex-servers-update

@@ -1,174 +0,0 @@
-#!/usr/bin/env sh
-set -eu
-
-# Links to scripts/configs
-bin="https://github.com/simplex-chat/simplexmq/releases/latest/download"
-bin_smp="$bin/smp-server-ubuntu-20_04-x86-64"
-bin_xftp="$bin/xftp-server-ubuntu-20_04-x86-64"
-
-scripts="https://raw.githubusercontent.com/simplex-chat/simplexmq/stable/scripts/main"
-scripts_systemd_smp="$scripts/smp-server.service"
-scripts_systemd_xftp="$scripts/xftp-server.service"
-scripts_update="$scripts/simplex-servers-update"
-scripts_uninstall="$scripts/simplex-servers-uninstall"
-scripts_stopscript="$scripts/simplex-servers-stopscript"
-
-# Default installation paths
-path_bin="/usr/local/bin"
-path_bin_smp="$path_bin/smp-server"
-path_bin_xftp="$path_bin/xftp-server"
-path_bin_update="$path_bin/simplex-servers-update"
-path_bin_uninstall="$path_bin/simplex-servers-uninstall"
-path_bin_stopscript="$path_bin/simplex-servers-stopscript"
-
-path_systemd="/etc/systemd/system"
-path_systemd_smp="$path_systemd/smp-server.service"
-path_systemd_xftp="$path_systemd/xftp-server.service"
-
-# Temporary paths
-path_tmp_bin="$(mktemp -d)"
-path_tmp_bin_update="$path_tmp_bin/simplex-servers-update"
-path_tmp_bin_uninstall="$path_tmp_bin/simplex-servers-uninstall"
-path_tmp_bin_stopscript="$path_tmp_bin/simplex-servers-stopscript"
-path_tmp_systemd_smp="$path_tmp_bin/smp-server.service"
-path_tmp_systemd_xftp="$path_tmp_bin/xftp-server.service"
-
-GRN='\033[0;32m'
-BLU='\033[1;36m'
-YLW='\033[1;33m'
-RED='\033[0;31m'
-NC='\033[0m'
-
-# Currently, XFTP default to v0.1.0, so it doesn't make sense to check its version
-local_version="$($path_bin_smp -v | awk '{print $3}')"
-remote_version="$(curl --proto '=https' --tlsv1.2 -sSf -L https://api.github.com/repos/simplex-chat/simplexmq/releases/latest | grep -i "tag_name" | awk -F \" '{print $4}')"
-
-update_scripts() {
-  curl --proto '=https' --tlsv1.2 -sSf -L "$scripts_update" -o "$path_tmp_bin_update" && chmod +x "$path_tmp_bin_update"
-  curl --proto '=https' --tlsv1.2 -sSf -L "$scripts_uninstall" -o "$path_tmp_bin_uninstall" && chmod +x "$path_tmp_bin_uninstall"
-  curl --proto '=https' --tlsv1.2 -sSf -L "$scripts_stopscript" -o "$path_tmp_bin_stopscript" && chmod +x "$path_tmp_bin_stopscript"
-
-  if diff -q "$path_bin_uninstall" "$path_tmp_bin_uninstall" > /dev/null 2>&1; then
-    printf -- "- ${YLW}Uninstall script is up-to-date${NC}.\n"
-    rm "$path_tmp_bin_uninstall"
-  else
-    printf -- "- Updating uninstall script..."
-    mv "$path_tmp_bin_uninstall" "$path_bin_uninstall"
-    printf "${GRN}Done!${NC}\n"
-  fi
-  if diff -q "$path_bin_stopscript" "$path_tmp_bin_stopscript" > /dev/null 2>&1; then
-    printf -- "- ${YLW}Stopscript script is up-to-date${NC}.\n"
-    rm "$path_tmp_bin_stopscript"
-  else
-    printf -- "- Updating stopscript script..."
-    mv "$path_tmp_bin_stopscript" "$path_bin_stopscript"
-    printf "${GRN}Done!${NC}\n"
-  fi
-  if diff -q "$path_bin_update" "$path_tmp_bin_update" > /dev/null 2>&1; then
-    printf -- "- ${YLW}Update script is up-to-date${NC}.\n"
-    rm "$path_tmp_bin_update"
-  else
-    printf -- "- Updating update script..."
-    mv "$path_tmp_bin_update" "$path_bin_update"
-    printf "${GRN}Done!${NC}\n"
-    printf "Re-executing Update script with latest updates..."
-    exec sh "$path_bin_update" "continue"
-  fi
-}
-
-update_systemd() {
-  curl --proto '=https' --tlsv1.2 -sSf -L "$scripts_systemd_smp" -o "$path_tmp_systemd_smp"
-  curl --proto '=https' --tlsv1.2 -sSf -L "$scripts_systemd_xftp" -o "$path_tmp_systemd_xftp"
-
-  if diff -q "$path_systemd_smp" "$path_tmp_systemd_smp" > /dev/null 2>&1; then
-    printf -- "- ${YLW}smp-server service is up-to-date${NC}.\n"
-    rm "$path_tmp_systemd_smp"
-  else
-    printf -- "- Updating smp-server service..."
-    mv "$path_tmp_systemd_smp" "$path_systemd_smp"
-    systemctl daemon-reload
-    printf "${GRN}Done!${NC}\n"
-  fi
-  if diff -q "$path_systemd_xftp" "$path_tmp_systemd_xftp" > /dev/null 2>&1; then
-    printf -- "- ${YLW}xftp-server service is up-to-date${NC}.\n"
-    rm "$path_tmp_systemd_xftp"
-  else
-    printf -- "- Updating xftp-server service..."
-    mv "$path_tmp_systemd_xftp" "$path_systemd_xftp"
-    systemctl daemon-reload
-    printf "${GRN}Done!${NC}\n"
-  fi
-}
-
-update_bins() {
-  if [ "$local_version" != "$remote_version" ]; then
-    if systemctl is-active --quiet smp-server; then
-      printf -- "- Stopping smp-server service..."
-      systemctl stop smp-server
-      printf "${GRN}Done!${NC}\n"
-
-      printf -- "- Updating smp-server bin to %s..." "$remote_version"
-      curl --proto '=https' --tlsv1.2 -sSf -L "$bin_smp" -o "$path_bin_smp" && chmod +x "$path_bin_smp"
-      printf "${GRN}Done!${NC}\n"
-      
-      printf -- "- Starting smp-server service..."
-      systemctl start smp-server
-      printf "${GRN}Done!${NC}\n"
-    else
-      printf -- "- Updating smp-server bin..."
-      curl --proto '=https' --tlsv1.2 -sSf -L "$bin_smp" -o "$path_bin_smp" && chmod +x "$path_bin_smp"
-      printf "${GRN}Done!${NC}\n"
-    fi
-
-    if systemctl is-active --quiet xftp-server; then
-      printf -- "- Stopping xftp-server service..."
-      systemctl stop xftp-server
-      printf "${GRN}Done!${NC}\n"
-
-      printf -- "- Updating xftp-server bin to %s..." "$remote_version"
-      curl --proto '=https' --tlsv1.2 -sSf -L "$bin_xftp" -o "$path_bin_xftp" && chmod +x "$path_bin_xftp"
-      printf "${GRN}Done!${NC}\n"
-      
-      printf -- "- Starting xftp-server service..."
-      systemctl start xftp-server
-      printf "${GRN}Done!${NC}\n"
-    else
-      printf -- "- Updating xftp-server bin..."
-      curl --proto '=https' --tlsv1.2 -sSf -L "$bin_smp" -o "$path_bin_xftp" && chmod +x "$path_bin_xftp"
-      printf "${GRN}Done!${NC}\n"
-    fi
-  else
-    printf -- "- ${YLW}smp-server and xftp-server binaries is up-to-date${NC}.\n"
-  fi
-}
-
-checks() {
-  if [ "$(id -u)" -ne 0 ]; then
-    printf "This script is intended to be run with root privileges. Please re-run script using sudo.\n"
-    exit 1
-  fi
-}
-
-main() {
-  checks
-
-  set +u
-  if [ "$1" != "continue" ]; then
-    set -u
-    printf "Updating scripts...\n"
-    update_scripts
-  else
-    set -u
-    printf "${GRN}Done!${NC}\n"
-  fi
-
-  printf "Updating systemd services...\n"
-  update_systemd
-  
-  printf "Updating simplex server binaries...\n"
-  update_bins
-
-  rm -rf "$path_tmp_bin"
-}
-
-main "$@"

scripts/main/smp-server.service

@@ -1,15 +0,0 @@
-[Unit]
-Description=SMP server
-
-[Service]
-User=smp
-Group=smp
-Type=simple
-ExecStart=/usr/local/bin/smp-server start +RTS -N -RTS 
-ExecStopPost=/usr/local/bin/simplex-servers-stopscript smp-server
-LimitNOFILE=65535
-KillSignal=SIGINT
-TimeoutStopSec=infinity
-
-[Install]
-WantedBy=multi-user.target

scripts/main/xftp-server.service

@@ -1,16 +0,0 @@
-[Unit]
-Description=XFTP server
-
-[Service]
-User=xftp
-Group=xftp
-Type=simple
-ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS
-ExecStopPost=/usr/local/bin/simplex-servers-stopscript xftp-server
-LimitNOFILE=65535
-KillSignal=SIGINT
-TimeoutStopSec=infinity
-AmbientCapabilities=CAP_NET_BIND_SERVICE
-   
-[Install]
-WantedBy=multi-user.target

scripts/ntf-server-linode.sh

@@ -1,178 +0,0 @@
-#!/bin/bash
-
-# <UDF name="enable_store_log" label="Store log - persist notification subscriptions to append only log and restore them upon server restart." default="on" oneof="on, off" />
-# <UDF name="api_token" label="Linode API token - enable Linode to create tags with server address, fingerprint and version. Note: minimal permissions token should have are read/write access to `linodes` (to create tags) and `domains` (to add A record for the third level domain if FQDN is provided)." default="" />
-# <UDF name="fqdn" label="FQDN (Fully Qualified Domain Name) - provide third level domain name (e.g. ntf.example.com). If provided use `ntf://fingerprint@FQDN` as server address in the client. If FQDN is not provided use `ntf://fingerprint@IP` instead." default="" />
-# <UDF name="apns_key_id" label="APNS key ID." default="" />
-
-# Log all stdout output to stackscript.log
-exec &> >(tee -i /var/log/stackscript.log)
-
-# Uncomment next line to enable debugging features
-# set -xeo pipefail
-
-cd $HOME
-
-# https://superuser.com/questions/1638779/automatic-yess-to-linux-update-upgrade
-# https://superuser.com/questions/1412054/non-interactive-apt-upgrade
-sudo DEBIAN_FRONTEND=noninteractive \
-  apt-get \
-  -o Dpkg::Options::=--force-confold \
-  -o Dpkg::Options::=--force-confdef \
-  -y --allow-downgrades --allow-remove-essential --allow-change-held-packages \
-  update
-
-sudo DEBIAN_FRONTEND=noninteractive \
-  apt-get \
-  -o Dpkg::Options::=--force-confold \
-  -o Dpkg::Options::=--force-confdef \
-  -y --allow-downgrades --allow-remove-essential --allow-change-held-packages \
-  dist-upgrade
-
-# TODO install unattended-upgrades
-sudo DEBIAN_FRONTEND=noninteractive \
-  apt-get \
-  -o Dpkg::Options::=--force-confold \
-  -o Dpkg::Options::=--force-confdef \
-  -y --allow-downgrades --allow-remove-essential --allow-change-held-packages \
-  install jq
-
-# Add firewall
-echo "y" | ufw enable
-
-# Open ports
-ufw allow ssh
-ufw allow https
-ufw allow 5223
-
-# Increase file descriptors limit
-echo 'fs.file-max = 1000000' >> /etc/sysctl.conf
-echo 'fs.inode-max = 1000000' >> /etc/sysctl.conf
-echo 'root soft nofile unlimited' >> /etc/security/limits.conf
-echo 'root hard nofile unlimited' >> /etc/security/limits.conf
-
-# Download latest release
-bin_dir="/opt/simplex-notifications/bin"
-binary="$bin_dir/ntf-server"
-mkdir -p $bin_dir
-curl -L -o $binary https://github.com/simplex-chat/simplexmq/releases/latest/download/ntf-server-ubuntu-20_04-x86-64
-chmod +x $binary
-
-# / Add to PATH
-cat > /etc/profile.d/simplex.sh << EOF
-#!/bin/bash
-
-export PATH="$PATH:$bin_dir"
-
-EOF
-# Add to PATH /
-
-# Source and test PATH
-source /etc/profile.d/simplex.sh
-ntf-server --version
-
-# Initialize server
-init_opts=()
-
-[[ $ENABLE_STORE_LOG == "on" ]] && init_opts+=(-l)
-
-ip_address=$(curl ifconfig.me)
-init_opts+=(--ip $ip_address)
-
-[[ -n "$FQDN" ]] && init_opts+=(-n $FQDN)
-
-ntf-server init "${init_opts[@]}"
-
-# Server fingerprint
-fingerprint=$(cat /etc/opt/simplex-notifications/fingerprint)
-
-# Determine server address to specify in welcome script and Linode tag
-if [[ -n "$FQDN" ]]; then
-  server_address=$FQDN
-else
-  server_address=$ip_address
-fi
-
-# Set up welcome script
-on_login_script="/opt/simplex-notifications/on_login.sh"
-
-# / Welcome script
-cat > $on_login_script << EOF
-#!/bin/bash
-
-fingerprint=\$1
-server_address=\$2
-
-cat << EOF2
-********************************************************************************
-
-SimpleX notifications server address: ntf://\$fingerprint@\$server_address
-Check server status with: systemctl status ntf-server
-
-To keep this server secure, the UFW firewall is enabled.
-All ports are BLOCKED except 22 (SSH), 443 (HTTPS), 5223 (notifications server).
-
-********************************************************************************
-To stop seeing this message delete line - bash /opt/simplex-notifications/on_login.sh - from /root/.bashrc
-EOF2
-
-EOF
-# Welcome script /
-
-chmod +x $on_login_script
-echo "bash $on_login_script $fingerprint $server_address" >> /root/.bashrc
-
-# Create A record and update Linode's tags
-if [[ -n "$API_TOKEN" ]]; then
-  if [[ -n "$FQDN" ]]; then
-    domain_address=$(echo $FQDN | rev | cut -d "." -f 1,2 | rev)
-    domain_id=$(curl -H "Authorization: Bearer $API_TOKEN" https://api.linode.com/v4/domains \
-    | jq --arg da "$domain_address" '.data[] | select( .domain == $da ) | .id')
-    if [[ -n $domain_id ]]; then
-      curl \
-        -s -H "Content-Type: application/json" \
-        -H "Authorization: Bearer $API_TOKEN" \
-        -X POST -d "{\"type\":\"A\",\"name\":\"$FQDN\",\"target\":\"$ip_address\"}" \
-        https://api.linode.com/v4/domains/${domain_id}/records
-    fi
-  fi
-
-  version=$(ntf-server --version | cut -d ' ' -f 3-)
-
-  curl \
-    -s -H "Content-Type: application/json" \
-    -H "Authorization: Bearer $API_TOKEN" \
-    -X PUT -d "{\"tags\":[\"$server_address\",\"$fingerprint\",\"$version\"]}" \
-    https://api.linode.com/v4/linode/instances/$LINODE_ID
-fi
-
-# / Create systemd service
-cat > /etc/systemd/system/ntf-server.service << EOF
-[Unit]
-Description=SimpleX notifications server
-
-[Service]
-Environment="APNS_KEY_FILE=/etc/opt/simplex-notifications/AuthKey.p8"
-Environment="APNS_KEY_ID=$APNS_KEY_ID"
-Type=simple
-ExecStart=/bin/sh -c "exec $binary start >> /var/opt/simplex-notifications/ntf-server.log 2>&1"
-KillSignal=SIGINT
-Restart=always
-RestartSec=10
-LimitNOFILE=1000000
-LimitNOFILESoft=1000000
-
-[Install]
-WantedBy=multi-user.target
-
-EOF
-# Create systemd service /
-
-# Start systemd service
-chmod 644 /etc/systemd/system/ntf-server.service
-sudo systemctl enable ntf-server
-# ! APNS key file and certificate have to be copied manually
-# sudo systemctl start ntf-server
-
-# Reboot Linode to apply upgrades
-# sudo reboot

scripts/smp-server-linode.sh

@@ -86,6 +86,10 @@ smp-server init "${init_opts[@]}"
 fingerprint=$(cat /etc/opt/simplex/fingerprint)
 
 # Determine server address to specify in welcome script and Linode tag
+# ! If FQDN was provided and used as part of server initialization, server's certificate will not pass validation at client
+# ! if client tries to connect by server's IP address, so we have to specify FQDN as server address in Linode tag and
+# ! in welcome script regardless of creation of A record in Linode
+# ! https://hackage.haskell.org/package/x509-validation-1.6.10/docs/src/Data-X509-Validation.html#validateCertificateName
 if [[ -n "$FQDN" ]]; then
   server_address=$FQDN
 else
@@ -153,8 +157,6 @@ Description=SMP server
 [Service]
 Type=simple
 ExecStart=/bin/sh -c "exec $binary start >> /var/opt/simplex/smp-server.log 2>&1"
-KillSignal=SIGINT
-TimeoutStopSec=infinity
 Restart=always
 RestartSec=10
 LimitNOFILE=1000000

scripts/tor/README.md

@@ -1,37 +0,0 @@
-1. Install `tor` following [official guide](https://community.torproject.org/onion-services/setup/install/).
-
-2. Modify `/etc/tor/torrc` configuration file:
-
-```sh
-...
-# Disable anonymous mode for better connectivity
-## Needed for HiddenServiceNonAnonymousMode
-SOCKSPort 0
-## Needed for HiddenServiceSingleHopMode
-HiddenServiceNonAnonymousMode 1
-## Flag to disable anonymous mode
-## This option reduces the latency of server connection, but it makes server itself not anonymous,
-## it only protects the anonymity of the users connecting to the server.
-## In case your server address has both public and onion hostnames it is not anonymous anyway,
-## so this is what you want.
-HiddenServiceSingleHopMode 1
-
-# Specify folder for smp-tor
-## Folder for keys, address, etc.
-HiddenServiceDir /var/lib/tor/simplex-smp/
-## Map smp port (5223) to tor
-HiddenServicePort 5223 localhost:5223
-...
-```
-
-3. Restart `tor` system service:
-
-```
-sudo systemctl restart tor
-```
-
-4. Onion address can be obtained from following file:
-
-```sh
-sudo cat /var/lib/tor/simplex-smp/hostname
-```

scripts/update-smp-server.sh

@@ -1,12 +0,0 @@
-#!/bin/bash
-
-# systemd has to be configured to use SIGINT to save and restore undelivered messages after restart.
-# Add this to [Service] section:
-# KillSignal=SIGINT
-curl -L -o /opt/simplex/bin/smp-server-new https://github.com/simplex-chat/simplexmq/releases/latest/download/smp-server-ubuntu-20_04-x86-64
-systemctl stop smp-server
-cp /var/opt/simplex/smp-server-store.log /var/opt/simplex/smp-server-store.log.bak
-mv /opt/simplex/bin/smp-server /opt/simplex/bin/smp-server-old
-mv /opt/simplex/bin/smp-server-new /opt/simplex/bin/smp-server
-chmod +x /opt/simplex/bin/smp-server
-systemctl start smp-server