Merge branch 'master' into v5

CHANGELOG.md

@@ -1,3 +1,13 @@
+# 0.5.0
+
+- No changes in SMP server implementation - it is backwards compatible with v0.4.1
+- SMP agent changes:
+  - URI syntax for SMP queues and connection requests.
+  - long-term connections links ("contacts") in SMP agent protocol.
+  - agent command changes:
+    - `REQ` notification and `ACPT` command are used only with long-term connection links.
+    - `CONF` notification and `LET` commands are used for normal duplex connections.
+
 # 0.4.1
 
 - Include migrations in the package

package.yaml

@@ -1,5 +1,5 @@
 name: simplexmq
-version: 0.4.1
+version: 0.5.0
 synopsis: SimpleXMQ message broker
 description:  |
   This package includes <./docs/Simplex-Messaging-Server.html server>,

protocol/overview.md

@@ -0,0 +1,259 @@
+# SimpleX: messaging and application network
+
+## Table of contents
+
+- [SimpleX objectives](#simplex-objectives)
+- [SimpleX network](#simplex-network)
+- [Threat model](#threat-model)
+
+## SimpleX objectives
+
+1. Provide messaging infrastructure for distributed applications. This infrastructure needs to have the following qualities:
+
+   - Security against passive and active (man-in-the-middle) attacks: the parties should have reliable end-to-end encryption and be able to identify and to some extent compensate for the presence of the active attacker who may modify, delete or add messages.
+  
+   - Privacy: network server operators should have no ability to read or modify messages without detection, and it should be impossible or hard to infer the contacts the users communicate with. Non-malicious network operators should retain no record of participants communications.
+  
+   - Reliability: the messages should be delivered even if some participating network servers or receiving clients fail, with “at least once” delivery guarantee.
+  
+   - Integrity: the messages should be delivered without alteration, in the same order, and any unauthorized message change should be detected by the recipient.
+  
+   - Asynchronous delivery: it should not be required that both communicating parties (client devices, services or applications) are online for reliable message delivery.
+  
+   - Low latency: the delay introduced by the network should not be higher than 100ms-1s in addition to the underlying TCP network latency.
+  
+2. Provide better communication privacy, in particular meta-data privacy (who talks to whom and when), and security, in particular security against active attacks, than the alternative instant messaging solutions.
+
+3. Balance user experience with privacy requirements, prioritizing experience of mobile device users.
+
+## SimpleX network
+
+### Overview
+
+SimpleX network provides asynchronous messaging infrastructure that aims to deliver on the above objectives and to avoid the disadvantages of the alternative solutions.
+
+The key differences of SimpleX network are:
+
+- participants do not need to have globally unique addresses to communicate, instead they use redundant unidirectional (simplex) messaging queues, with a separate set of queues for each contact.
+
+- connection requests are passed out-of-band, non-optionally protecting key exchange against man-in-the-middle attack.
+
+- message queues provided by network servers are used by the clients to create more complex communication scenarios, such as duplex one-to-one communication, transmitting files, group communication without central servers and content/communication channels (requiring a separate type of server to host them, which is out of scope of this document).
+
+- servers do not store any user information (no user profiles, contacts or messages, once they are delivered), and can use in-memory persistence only.
+
+- users can change server provider(s) without losing their communication contacts, simply by changing the configuration on which servers the new queues are created.
+
+SimpleX network has design similar to P2P networks, but unlike most P2P networks it consists of clients and servers, without dependency on any centralized component. Servers provide anonymous unidirectional message queues in order to:
+
+- continuously accept messages for the recipients, even when they are offline.
+
+- provide recipient anonymity, as the messaging queues do not identify the users, and different addresses of the same queue are used for senders and recipients to provide additional protection against server traffic correlation, in case transport connections are compromised.
+
+Coincidentally, SimpleX network reminds [Pond messenger](https://github.com/agl/pond) design, the main differences are:
+
+- Clients can receive messages via multiple servers (in Pond users use one home server and it serves as a user permanent address),
+
+- Clients do not need to poll servers to receive messages, the messages from subscribed queues are delivered via an open transport connection as they are received by the servers, resulting in low latency of message delivery.
+
+### SimpleX servers
+
+Clients communicate with servers (but not with other clients) using SimpleX Messaging Protocol (SMP) running over some transport protocol that provides server authentication, confidentiality with forward secrecy, integrity and transport channel binding (to prevent SMP commands replay).
+
+Users can use multiple servers. They choose the servers they use to receive the messages through, and they communicate with the servers chosen by the recipients to send messages.
+
+It is assumed that users have some degree of trust to the servers, for one of the following reasons:
+
+- They deploy and control the servers themselves from the available open-source code. The advantage of self-deployed servers is that users have full control of server information and activity, but the downside is that it is easier to correlate incoming and outgoing messages by observing server traffic, assuming small number of messages sent via user-hosted servers and irregular communication time. It can be mitigated by:
+
+  - sending noise traffic.
+
+  - future protocol versions can add configurable per queue message delivery delays (compromising on one of the design objectives of low latency).
+
+  - using SMP servers via an onion routing or mix network.
+
+- They use servers from the trusted commercial providers. The more clients the provider has, the less meta-data about the communication times is leaked to the network observers, and even if transport confidentiality is compromised it is not possible to correlate sent and received traffic without compromising the server, because the clients use different queue IDs to send and receive messages, and the message delivered to the recipient is additionally encrypted by the server.
+
+- To some extent, users trust their contacts and the servers they chose that the users send messages to. The client applications could further improve user trust to the servers chosen by their contacts by supporting either the list of servers that are “allowed to send to” or “prohibited to send to” (e.g., known trusted or compromised servers, certain IP ranges, server geographical locations etc.).
+
+If users use the free servers deployed by the volunteers, there is a risk that the server code can maliciously record all queues and messages (even though encrypted) sent via the same transport connection and to gain a partial knowledge of the user’s communications graph and other meta-data. User clients can mitigate it by using some overlay network that protects the privacy of TCP connections, e.g., Tor, and by sending noise traffic between the end users.
+
+The servers authorize users to access (send/receive/etc.) their message queues via a digital signature of transmissions using a unique key pair different for each queue sender and recipient, so no information that is required for the server to authorize users allows to aggregate user communications across multiple queues.
+
+### Transport
+
+SimpleX network does not rely on transport or overlay network for server or client authentication. SMP protocol itself must provide integrity, forward secure confidentiality of communicating parties and mutual authentication even if transport protocol (but not the server) is compromised by the active attacker.
+
+To protect against MITM attack on the transport, the clients should verify server self-signed certificate during TLS handshake by validating its pre-shared hash of the certificate in the server address (either as part of client configuration or passed in SMP connection request).
+
+Clients use TLS1.3 protocol to connect to the server, restricting supported cryptographic protocols as defined in SimpleX Messaging Protocol.
+
+After TCP transport connection is established, and the server is authenticated, the client sends blocks of a fixed size 16Kb, and the server replies with the blocks of the same size. When the actual message is smaller, it should be padded before encryption, and if it is larger, it can be split to chunks by the client application. The first blocks from the client and the server should include protocol version so that the party with the higher version can confirm compatibility and the transport channel identifier as described in SMP protocol.
+
+Client can terminate the server transport connection without losing any messages – removal of the message from the server and the delivery of the next message happens when the client acknowledges the message reception (normally, after it is persisted in the client’s database).
+
+Depending on the privacy requirements of the clients, the client can use a separate transport connection per queue, or receive messages from multiple queues via a single transport connection, for efficiency. In our implementations this configuration will be available to the end users.
+
+### Server implementation
+
+- does not store user access logs.
+
+- does not store messages after the client has received them.
+
+- permanently removes queues after they are deleted by the users
+
+- only stores messages in transit in server operating memory; as clients are expected to use multiple servers to deliver each message, the message loss in one of the servers is acceptable.
+
+### SimpleX clients and agents
+
+Clients are assumed to be running on the trusted devices and can use the locally encrypted storage for messages, contacts, groups and other resources.
+
+SimpleX clients implementing application-level protocols communicate with SimpleX servers via agents. SimpleX agents can be accessed in one of the following ways:
+
+- via TCP network using trusted network connection or an overlay transport network.
+
+- via local port (when the agent runs on the same device as a separate process).
+
+- via agent library, when the agent logic is included directly into the client application.
+
+The last option is the most secure, as it reduces the number of attack vectors in comparison with other options. The current implementation of SimpleX Chat uses this approach.
+
+SimpleX agents provide the following operations:
+
+- Creating and managing bi-directional (duplex) client connections and delivering messages via redundant groups of SimpleX queues.
+
+- Exchanging keys and providing end-to-end encryption. The current prototype uses RSA cryptography with ad-hoc hybrid encryption scheme, we are currently switching it to X3DH for key exchange and double ratchet protocol for E2E encryption.
+
+Communication between the client and the agent and the communication between the agents (via end-to-end encrypted messages delivered via SMP protocol) is described by SimpleX Agent Protocol.
+
+Bi-directional client connections consist of multiple “send” and multiple “receive” queues (for redundancy) that agents use to send and receive messages; each queue should be used for limited amount of time, the rotation of queues is negotiated using SimpleX Agent Protocol.
+
+There are two ways that SimpleX network users can establish the connection:
+
+- Users communicate the initial connection invitation out-of-band, via link or via QR code. This out-of-band communication is assumed secure against active attacks and insecure against passive attacks. Once the connection is established that users are assumed to have confirmed out-of-band, the connection can no longer be compromised even if out-of-band invitation was obtained by the attacker. This out-of-band invitation does not contain any personal information, only the address of the queue and public key for the key exchange for end-to-end encryption.
+
+- Users can create a “contact queue(s)” on SMP servers that would be used to receive connection requests. The important distinction with commonly used addressing systems is that this queue is only used to pass the connection request and not for subsequent messages. So, while it is possible to spam users who created such contact queues with connection requests, they can be removed without disrupting the communication with the existing contacts.
+
+The reply queue addresses and the key exchange for the reply queues is negotiated via the direct queue.
+
+### Message encryption
+
+Messages are encrypted end-to-end using double ratchet protocol. Once the sending client deletes messages it won’t be able to decrypt them again. While messages are numbered within the queue, this only reveals to the servers how messages have been exchanged in a given queue that has a limited lifetime, so the total number of messages exchanged between contacts is not revealed.
+
+The next queue to use is negotiated between agents in encrypted messages, and in most cases, it will be on another server (unless the client is configured to use one server, which is not recommended).
+
+### Client storage
+
+It is assumed that the client device and the storage is trusted, but clients can implement storage encryption using a user-provided passphrase.
+
+## Threat model
+
+### Assumptions
+
+User protects their information and keys.
+
+SimpleX Chat software is authentic.
+
+User device is not compromised, excluding the scenarios below where it is explicitly stated it is compromised.
+
+Used cryptographic primitives are not compromised.
+
+### SimpleX Messaging Protocol server
+
+**can:**
+
+- learn when a queue recipient or sender is online via transmission times.
+
+- correlate multiple queues to a single user in case they are accessed via the same transport connection or from the same IP address.
+
+- correlate multiple queues to a single user based on the time they are accessed. Clients that use message notification servers can mitigate it by only subscribing to the queues after they receive the notifications and disconnecting after some time of inactivity.
+
+- know how many messages is sent via the queue, clients can mitigate it with noise traffic.
+
+- add, drop, duplicate or corrupt messages, but it will be detected by the client on SimpleX Agent Protocol level. Using multiple servers to deliver each message mitigates the loss of messages.
+
+**cannot:**
+
+- decrypt messages
+
+- compromise e2e encryption with MITM attack (as server is only used to pass one of two keys in DH exchange, the first key is passed out-of-band)
+
+### A global passive adversary monitoring all Internet traffic
+
+**can:**
+
+- learn who is using SimpleX Chat.
+
+- learn when messages are sent and received.
+
+- learn which SimpleX Messaging Protocol servers are used.
+
+- in case of low traffic on the servers, correlate senders and recipients by the time messages sent and received.
+
+- observe the approximate size of the files transmitted – to O(log log M) of file size precision.
+
+**cannot, even in case of compromised transport protocol:**
+
+- correlate senders and recipients by the content of messages (as different queue IDs are used for senders and recipients, with additional encryption layer in the delivered messages).
+
+### A local network attacker
+
+**can:**
+
+- observe when a user is using SimpleX Chat.
+
+- block SimpleX Chat traffic.
+
+- determine which servers the user communicates with.
+
+- observe the approximate size of files transmissions and receptions.
+
+**cannot:**
+
+- see who sends messages to the user and who the user sends the messages to
+
+### An attacker who obtained user’s decrypted chat database
+
+**can:**
+
+- see the history of all messages
+
+- see shared profiles of contacts and groups
+
+- receive new user messages, but the user will detect it as the number and the hash of the previous message won’t match. Also, they will be instantly alerted that an unknown device is connected to their message queues, as long as they are online at the same time, as message queues only allow one active subscription.
+
+- delete user’s message queues, so the contacts won’t be able to send messages.
+
+- send messages from the user to their contacts, but the recipients will detect it as soon as the user sends the next message, because the previous message hash won’t match (and potentially won’t be able to decrypt them in case they don’t keep the previous ratchet keys).
+
+**cannot:**
+
+- impersonate a sender and send messages to the user whose database was stolen without also compromising the server (to place the message in the queue) or the user's device at a subsequent time (to place the message in the database).
+
+### A user’s contact
+
+**can:**
+
+- spam the user with messages.
+
+- forever retain messages from the user.
+
+**cannot:**
+
+- prove to a third-party that a message came from a user (assuming a user’s device is not seized)
+
+- prove that two contacts they have is the same user.
+
+- two contacts cannot confirm if they are communicating with the same user.
+
+### An attacker with Internet access
+
+**can:**
+
+- DoS SimpleX messaging servers.
+
+- spam the user who created a “contact queue” (queue for accepting connection requests) by sending multiple connection requests.
+
+**cannot:**
+
+- send messages to the user who they are not connected with.

simplexmq.cabal

@@ -4,10 +4,10 @@ cabal-version: 1.12
 --
 -- see: https://github.com/sol/hpack
 --
--- hash: 1e44584019db4d35d25a97c553870b0960fe7a18b5296f0e49b8084c343276ab
+-- hash: 3bdb491a0318dc4b53cba4131f192e4c4e17b42e88043495666d1688a1f95443
 
 name:           simplexmq
-version:        0.4.1
+version:        0.5.0
 synopsis:       SimpleXMQ message broker
 description:    This package includes <./docs/Simplex-Messaging-Server.html server>,
                 <./docs/Simplex-Messaging-Client.html client> and

src/Simplex/Messaging/Agent.hs

@@ -47,6 +47,7 @@ module Simplex.Messaging.Agent
     joinConnection,
     allowConnection,
     acceptContact,
+    rejectContact,
     subscribeConnection,
     sendMessage,
     ackMessage,
@@ -84,7 +85,7 @@ import Simplex.Messaging.Client (SMPServerTransmission)
 import qualified Simplex.Messaging.Crypto as C
 import Simplex.Messaging.Protocol (MsgBody, SenderPublicKey)
 import qualified Simplex.Messaging.Protocol as SMP
-import Simplex.Messaging.Transport (ATransport (..), TProxy, Transport (..), runTransportServer)
+import Simplex.Messaging.Transport (ATransport (..), TProxy, Transport (..), currentSMPVersionStr, runTransportServer)
 import Simplex.Messaging.Util (bshow, tryError, unlessM)
 import System.Random (randomR)
 import UnliftIO.Async (async, race_)
@@ -108,7 +109,7 @@ runSMPAgentBlocking (ATransport t) started cfg@AgentConfig {tcpPort} = runReader
   where
     smpAgent :: forall c m'. (Transport c, MonadUnliftIO m', MonadReader Env m') => TProxy c -> m' ()
     smpAgent _ = runTransportServer started tcpPort $ \(h :: c) -> do
-      liftIO $ putLn h "Welcome to SMP v0.4.1 agent"
+      liftIO . putLn h $ "Welcome to SMP agent v" <> currentSMPVersionStr
       c <- getAgentClient
       logConnection c True
       race_ (connectClient h c) (runAgentClient c)
@@ -137,14 +138,18 @@ createConnection c cMode = withAgentEnv c $ newConn c "" cMode
 joinConnection :: AgentErrorMonad m => AgentClient -> ConnectionRequest c -> ConnInfo -> m ConnId
 joinConnection c = withAgentEnv c .: joinConn c ""
 
--- | Approve confirmation (ACPT INV command)
+-- | Allow connection to continue after CONF notification (LET command)
 allowConnection :: AgentErrorMonad m => AgentClient -> ConnId -> ConfirmationId -> ConnInfo -> m ()
 allowConnection c = withAgentEnv c .:. allowConnection' c
 
--- | Approve contact (ACPT CON command)
+-- | Accept contact after REQ notification (ACPT command)
 acceptContact :: AgentErrorMonad m => AgentClient -> ConfirmationId -> ConnInfo -> m ConnId
 acceptContact c = withAgentEnv c .: acceptContact' c ""
 
+-- | Reject contact (RJCT command)
+rejectContact :: AgentErrorMonad m => AgentClient -> ConnId -> ConfirmationId -> m ()
+rejectContact c = withAgentEnv c .: rejectContact' c
+
 -- | Subscribe to receive connection messages (SUB command)
 subscribeConnection :: AgentErrorMonad m => AgentClient -> ConnId -> m ()
 subscribeConnection c = withAgentEnv c . subscribeConnection' c
@@ -236,6 +241,7 @@ withStore action = do
       SEConnDuplicate -> CONN DUPLICATE
       SEBadConnType CRcv -> CONN SIMPLEX
       SEBadConnType CSnd -> CONN SIMPLEX
+      SEInvitationNotFound -> CMD PROHIBITED
       e -> INTERNAL $ show e
 
 -- | execute any SMP agent command
@@ -245,6 +251,7 @@ processCommand c (connId, cmd) = case cmd of
   JOIN (ACR _ cReq) connInfo -> (,OK) <$> joinConn c connId cReq connInfo
   LET confId ownCInfo -> allowConnection' c connId confId ownCInfo $> (connId, OK)
   ACPT invId ownCInfo -> (,OK) <$> acceptContact' c connId invId ownCInfo
+  RJCT invId -> rejectContact' c connId invId $> (connId, OK)
   SUB -> subscribeConnection' c connId $> (connId, OK)
   SEND msgBody -> (connId,) . MID <$> sendMessage' c connId msgBody
   ACK msgId -> ackMessage' c connId msgId $> (connId, OK)
@@ -291,7 +298,7 @@ activateQueueJoining c connId sq verifyKey retryInterval =
       withStore $ \st -> upgradeSndConnToDuplex st connId rq
       sendControlMessage c sq . REPLY $ CRInvitation $ ConnReqData CRSSimplex [qUri'] encryptKey
 
--- | Approve confirmation (ACPT INV command) in Reader monad
+-- | Approve confirmation (LET command) in Reader monad
 allowConnection' :: AgentMonad m => AgentClient -> ConnId -> ConfirmationId -> ConnInfo -> m ()
 allowConnection' c connId confId ownConnInfo = do
   withStore (`getConn` connId) >>= \case
@@ -300,7 +307,7 @@ allowConnection' c connId confId ownConnInfo = do
       processConfirmation c rq senderKey
     _ -> throwError $ CMD PROHIBITED
 
--- | Accept contact (ACPT CON command) in Reader monad
+-- | Accept contact (ACPT command) in Reader monad
 acceptContact' :: AgentMonad m => AgentClient -> ConnId -> InvitationId -> ConnInfo -> m ConnId
 acceptContact' c connId invId ownConnInfo = do
   Invitation {contactConnId, connReq} <- withStore (`getInvitation` invId)
@@ -310,6 +317,11 @@ acceptContact' c connId invId ownConnInfo = do
       joinConn c connId connReq ownConnInfo
     _ -> throwError $ CMD PROHIBITED
 
+-- | Reject contact (RJCT command) in Reader monad
+rejectContact' :: AgentMonad m => AgentClient -> ConnId -> InvitationId -> m ()
+rejectContact' _ contactConnId invId =
+  withStore $ \st -> deleteInvitation st contactConnId invId
+
 processConfirmation :: AgentMonad m => AgentClient -> RcvQueue -> SenderPublicKey -> m ()
 processConfirmation c rq sndKey = do
   withStore $ \st -> setRcvQueueStatus st rq Confirmed
@@ -469,7 +481,8 @@ deleteConnection' c connId =
   withStore (`getConn` connId) >>= \case
     SomeConn _ (DuplexConnection _ rq _) -> delete rq
     SomeConn _ (RcvConnection _ rq) -> delete rq
-    _ -> withStore (`deleteConn` connId)
+    SomeConn _ (ContactConnection _ rq) -> delete rq
+    SomeConn _ (SndConnection _ _) -> withStore (`deleteConn` connId)
   where
     delete :: RcvQueue -> m ()
     delete rq = do

src/Simplex/Messaging/Agent/Protocol.hs

@@ -186,6 +186,7 @@ data ACommand (p :: AParty) where
   LET :: ConfirmationId -> ConnInfo -> ACommand Client -- ConnInfo is from client
   REQ :: InvitationId -> ConnInfo -> ACommand Agent -- ConnInfo is from sender
   ACPT :: InvitationId -> ConnInfo -> ACommand Client -- ConnInfo is from client
+  RJCT :: InvitationId -> ACommand Client
   INFO :: ConnInfo -> ACommand Agent
   CON :: ACommand Agent -- notification that connection is established
   SUB :: ACommand Client
@@ -645,6 +646,7 @@ commandP =
     <|> "LET " *> letCmd
     <|> "REQ " *> reqMsg
     <|> "ACPT " *> acptCmd
+    <|> "RJCT " *> rjctCmd
     <|> "INFO " *> infoCmd
     <|> "SUB" $> ACmd SClient SUB
     <|> "END" $> ACmd SAgent END
@@ -669,6 +671,7 @@ commandP =
     letCmd = ACmd SClient <$> (LET <$> A.takeTill (== ' ') <* A.space <*> A.takeByteString)
     reqMsg = ACmd SAgent <$> (REQ <$> A.takeTill (== ' ') <* A.space <*> A.takeByteString)
     acptCmd = ACmd SClient <$> (ACPT <$> A.takeTill (== ' ') <* A.space <*> A.takeByteString)
+    rjctCmd = ACmd SClient . RJCT <$> A.takeByteString
     infoCmd = ACmd SAgent . INFO <$> A.takeByteString
     sendCmd = ACmd SClient . SEND <$> A.takeByteString
     msgIdResp = ACmd SAgent . MID <$> A.decimal
@@ -708,6 +711,7 @@ serializeCommand = \case
   LET confId cInfo -> B.unwords ["LET", confId, serializeBinary cInfo]
   REQ invId cInfo -> B.unwords ["REQ", invId, serializeBinary cInfo]
   ACPT invId cInfo -> B.unwords ["ACPT", invId, serializeBinary cInfo]
+  RJCT invId -> "RJCT " <> invId
   INFO cInfo -> "INFO " <> serializeBinary cInfo
   SUB -> "SUB"
   END -> "END"

src/Simplex/Messaging/Agent/Store.hs

@@ -55,6 +55,7 @@ class Monad m => MonadAgentStore s m where
   createInvitation :: s -> TVar ChaChaDRG -> NewInvitation -> m InvitationId
   getInvitation :: s -> InvitationId -> m Invitation
   acceptInvitation :: s -> InvitationId -> ConnInfo -> m ()
+  deleteInvitation :: s -> ConnId -> InvitationId -> m ()
 
   -- Msg management
   updateRcvIds :: s -> ConnId -> m (InternalId, InternalRcvId, PrevExternalSndId, PrevRcvMsgHash)

src/Simplex/Messaging/Agent/Store/SQLite.hs

@@ -394,6 +394,15 @@ instance (MonadUnliftIO m, MonadError StoreError m) => MonadAgentStore SQLiteSto
           ":invitation_id" := invitationId
         ]
 
+  deleteInvitation :: SQLiteStore -> ConnId -> InvitationId -> m ()
+  deleteInvitation st contactConnId invId =
+    liftIOEither . withTransaction st $ \db ->
+      runExceptT $
+        ExceptT (getConn_ db contactConnId) >>= \case
+          SomeConn SCContact _ ->
+            liftIO $ DB.execute db "DELETE FROM conn_invitations WHERE contact_conn_id = ? AND invitation_id = ?" (contactConnId, invId)
+          _ -> throwError SEConnNotFound
+
   updateRcvIds :: SQLiteStore -> ConnId -> m (InternalId, InternalRcvId, PrevExternalSndId, PrevRcvMsgHash)
   updateRcvIds st connId =
     liftIO . withTransaction st $ \db -> do

src/Simplex/Messaging/Transport.hs

@@ -46,6 +46,7 @@ module Simplex.Messaging.Transport
     tGetEncrypted,
     serializeTransportError,
     transportErrorP,
+    currentSMPVersionStr,
 
     -- * Trim trailing CR
     trimCR,
@@ -222,7 +223,10 @@ major :: SMPVersion -> (Int, Int)
 major (SMPVersion a b _ _) = (a, b)
 
 currentSMPVersion :: SMPVersion
-currentSMPVersion = "0.4.1.0"
+currentSMPVersion = "0.5.0.0"
+
+currentSMPVersionStr :: ByteString
+currentSMPVersionStr = serializeSMPVersion currentSMPVersion
 
 serializeSMPVersion :: SMPVersion -> ByteString
 serializeSMPVersion (SMPVersion a b c d) = B.intercalate "." [bshow a, bshow b, bshow c, bshow d]
@@ -373,7 +377,7 @@ serverHandshake c srvBlockSize (k, pk) = do
       liftError (const $ TEHandshake DECRYPT) (C.decryptOAEP pk encKeys)
         >>= liftEither . parseClientHandshake
     sendWelcome_6 :: THandle c -> ExceptT TransportError IO ()
-    sendWelcome_6 th = ExceptT . tPutEncrypted th $ serializeSMPVersion currentSMPVersion <> " "
+    sendWelcome_6 th = ExceptT . tPutEncrypted th $ currentSMPVersionStr <> " "
 
 -- | Client SMP encrypted transport handshake.
 --

tests/AgentTests.hs

@@ -20,6 +20,7 @@ import Network.HTTP.Types (urlEncode)
 import SMPAgentClient
 import SMPClient (testPort, testPort2, testStoreLogFile, withSmpServer, withSmpServerStoreLogOn)
 import Simplex.Messaging.Agent.Protocol
+import qualified Simplex.Messaging.Agent.Protocol as A
 import Simplex.Messaging.Protocol (ErrorType (..), MsgBody)
 import Simplex.Messaging.Transport (ATransport (..), TProxy (..), Transport (..))
 import System.Directory (removeFile)
@@ -45,11 +46,13 @@ agentTests (ATransport t) = do
       smpAgentTest2_2_2 $ testDuplexConnection t
     it "should connect via 2 servers and 2 agents (random IDs)" $
       smpAgentTest2_2_2 $ testDuplexConnRandomIds t
-  describe "Establishing two connections via `contact connection" do
-    it "should connect via contact contact with one server and 3 agents" $
+  describe "Establishing connections via `contact connection`" do
+    it "should connect via contact connection with one server and 3 agents" $
       smpAgentTest3 $ testContactConnection t
-    it "should connect via contact contact with one server and 2 agents (random IDs)" $
+    it "should connect via contact connection with one server and 2 agents (random IDs)" $
       smpAgentTest2_2_1 $ testContactConnRandomIds t
+    it "should support rejecting contact request" $
+      smpAgentTest2_2_1 $ testRejectContactRequest t
   describe "Connection subscriptions" do
     it "should connect via one server and one agent" $
       smpAgentTest3_1_1 $ testSubscription t
@@ -175,8 +178,8 @@ testContactConnection _ alice bob tom = do
   let cReq' = serializeConnReq cReq
 
   bob #: ("11", "alice", "JOIN " <> cReq' <> " 14\nbob's connInfo") #> ("11", "alice", OK)
-  ("", "alice_contact", Right (REQ aConfId "bob's connInfo")) <- (alice <#:)
-  alice #: ("2", "bob", "ACPT " <> aConfId <> " 16\nalice's connInfo") #> ("2", "bob", OK)
+  ("", "alice_contact", Right (REQ aInvId "bob's connInfo")) <- (alice <#:)
+  alice #: ("2", "bob", "ACPT " <> aInvId <> " 16\nalice's connInfo") #> ("2", "bob", OK)
   ("", "alice", Right (CONF bConfId "alice's connInfo")) <- (bob <#:)
   bob #: ("12", "alice", "LET " <> bConfId <> " 16\nbob's connInfo 2") #> ("12", "alice", OK)
   alice <# ("", "bob", INFO "bob's connInfo 2")
@@ -188,8 +191,8 @@ testContactConnection _ alice bob tom = do
   bob #: ("13", "alice", "ACK 1") #> ("13", "alice", OK)
 
   tom #: ("21", "alice", "JOIN " <> cReq' <> " 14\ntom's connInfo") #> ("21", "alice", OK)
-  ("", "alice_contact", Right (REQ aConfId' "tom's connInfo")) <- (alice <#:)
-  alice #: ("4", "tom", "ACPT " <> aConfId' <> " 16\nalice's connInfo") #> ("4", "tom", OK)
+  ("", "alice_contact", Right (REQ aInvId' "tom's connInfo")) <- (alice <#:)
+  alice #: ("4", "tom", "ACPT " <> aInvId' <> " 16\nalice's connInfo") #> ("4", "tom", OK)
   ("", "alice", Right (CONF tConfId "alice's connInfo")) <- (tom <#:)
   tom #: ("22", "alice", "LET " <> tConfId <> " 16\ntom's connInfo 2") #> ("22", "alice", OK)
   alice <# ("", "tom", INFO "tom's connInfo 2")
@@ -206,10 +209,10 @@ testContactConnRandomIds _ alice bob = do
   let cReq' = serializeConnReq cReq
 
   ("11", aliceConn, Right OK) <- bob #: ("11", "", "JOIN " <> cReq' <> " 14\nbob's connInfo")
-  ("", aliceContact', Right (REQ aConfId "bob's connInfo")) <- (alice <#:)
+  ("", aliceContact', Right (REQ aInvId "bob's connInfo")) <- (alice <#:)
   aliceContact' `shouldBe` aliceContact
 
-  ("2", bobConn, Right OK) <- alice #: ("2", "", "ACPT " <> aConfId <> " 16\nalice's connInfo")
+  ("2", bobConn, Right OK) <- alice #: ("2", "", "ACPT " <> aInvId <> " 16\nalice's connInfo")
   ("", aliceConn', Right (CONF bConfId "alice's connInfo")) <- (bob <#:)
   aliceConn' `shouldBe` aliceConn
 
@@ -223,6 +226,18 @@ testContactConnRandomIds _ alice bob = do
   bob <#= \case ("", c, Msg "hi") -> c == aliceConn; _ -> False
   bob #: ("13", aliceConn, "ACK 1") #> ("13", aliceConn, OK)
 
+testRejectContactRequest :: Transport c => TProxy c -> c -> c -> IO ()
+testRejectContactRequest _ alice bob = do
+  ("1", "a_contact", Right (INV cReq)) <- alice #: ("1", "a_contact", "NEW CON")
+  let cReq' = serializeConnReq cReq
+  bob #: ("11", "alice", "JOIN " <> cReq' <> " 10\nbob's info") #> ("11", "alice", OK)
+  ("", "a_contact", Right (REQ aInvId "bob's info")) <- (alice <#:)
+  -- RJCT must use correct contact connection
+  alice #: ("2a", "bob", "RJCT " <> aInvId) #> ("2a", "bob", ERR $ CONN NOT_FOUND)
+  alice #: ("2b", "a_contact", "RJCT " <> aInvId) #> ("2b", "a_contact", OK)
+  alice #: ("3", "bob", "ACPT " <> aInvId <> " 12\nalice's info") #> ("3", "bob", ERR $ A.CMD PROHIBITED)
+  bob #:# "nothing should be delivered to bob"
+
 testSubscription :: Transport c => TProxy c -> c -> c -> c -> IO ()
 testSubscription _ alice1 alice2 bob = do
   (alice1, "alice") `connect` (bob, "bob")

tests/SMPAgentClient.hs

@@ -189,7 +189,7 @@ testSMPAgentClientOn :: (Transport c, MonadUnliftIO m) => ServiceName -> (c -> m
 testSMPAgentClientOn port' client = do
   runTransportClient agentTestHost port' $ \h -> do
     line <- liftIO $ getLn h
-    if line == "Welcome to SMP v0.4.1 agent"
+    if line == "Welcome to SMP agent v" <> currentSMPVersionStr
       then client h
       else error $ "wrong welcome message: " <> B.unpack line