Per their FAQ on their site:
Why are they using Arbitrum
The Session Token is launching on Arbitrum One, a leading Ethereum Layer 2 scaling solution, for its proven performance, reliability, and security. Creating the cryptographic-ally secure Session Node registration and reward system directly on the Ethereum network would be prohibitively expensive. Arbitrum’s drastically reduced gas fees allow the implementation of the Session Network’s staking logic on an Ethereum-backed blockchain with much lower costs. Supported by a grant from the Arbitrum Foundation, Session should contribute significantly to Arbirum’s success in the future as one of the largest decentralised applications on its network.
How they explain their network
The Session Network is a decentralized physical infrastructure network (DePIN) made up of community-operated nodes, called Session Nodes). This DePIN infrastructure enables application functionality and scalability through the routing and storage of data (like messages). Currently, there are approximately 2,000 nodes providing services to Session via the Oxen Network. These nodes will undergo a migration from the Oxen Network to the new Session Network.
Session Protocol Details
Peer-to-Peer (from their white paper)
This description covers the functions of the Session Protocol required for one-on-one chats. The function of the protocol for groups and communities is covered in sections 5.4.1 and 5.4.2 respectively.
To construct and send a valid message in a one-on-one chat using the Session Protocol, the sender first creates a message M containing a number of data fields, including the plaintext message, and the senders Ed25519 public key. M is then serialised and padded to the next 160 byte multiple to prevent extraction of the exact message size. M can now be signed given the sender’s Ed25519 private key using the Ed25519 signature scheme. Once signed, the sender’s Ed25519 public key and the signature are then appended to M.
After signing the message M, the sender generates an ephemeral X25519 key pair. This key pair, alongside the recipient’s X25519 key pair, is used to generate a shared symmetric encryption key. The message M is then encrypted with this shared symmetric key using the XSalsa20-Poly1305 algorithm. This encrypted blob can now be packed into a message, which contains necessary metadata specifying the recipients X25519 public key and the ephemeral X25519 public key. Though both Ed25519 and X25519 keys are used, only one private key is required; the X25519 keys are derived from the recipient’s Ed25519 keys.
The usage of both Ed25519 and X25519 keys in this process may create some confusion. The public X25519 key is derived from the sender’s Ed25519 key pair; this public X25519 key represents the user’s Account ID. Historically this was done to maintain compatibility with the Signal Protocol which also uses X25519 keys in this way.
Once a message has been generated and packed it will be sent to the recipient’s swarm via an onion request specifying the expiry time and timestamp of the message. The recipient will authenticate retrieval of the message and reverse the process, decrypting, determining, and authenticating the sender of the message as it does so.
Groups & Communities
One way to improve scalability in group chats is to adopt a shared encryption key for all group members. This key would be shared in a pairwise message to members joining the group. When a
member leaves or is expelled, the administrator creates a new shared encryption key, re-encrypts it, and sends it to the remaining N − 1 members, effectively rotating the key to prevent former members from accessing new messages. In this system, messages only need to be encrypted once
for the group in most scenarios.
This scheme is effective in small to medium-sized group chats where the membership set changes infrequently. However, it can be impractical in larger groups where users frequently leave (or are otherwise removed from) the chat.
With the above considerations in mind, the Session Protocol defines two different designs for the encryption and scaling of group chats. Which design is appropriate depends on the intended size and use of the group and is chosen when the group is created. ‘Groups’ support communication among 3 to 100 participants. Participant sizes beyond 100 require the use of ‘communities’. However, it should be noted that ‘communities’ can also accommodate participant sizes fewer than 100.
Groups (3-100)
Users encrypt and decrypt messages for the group using the established group encryption symmetric key, messages are encrypted using the XChaCha20-Poly1305 algorithm.
Community
Authentication to the Session Community Server is similar to authentication in one-on-one conversations, with one main difference. Instead of each user using their long-term Session private key pair to sign messages, they use a deterministic derived key. This ensures users do not leak their real Account ID to large communities, as this could be a vector for spammers to collect users’ Account IDs.
Not sure about their investors, just read a rant about people not liking the switch to Arb (yet another migration from one network to the next) the other day.