Brief

status-go serves as the backbone of Status, handling core backend functionalities that ensure consistency across platforms. Its primary goal is to keep clients lightweight by delegating most processing and state management tasks to status-go, which acts as a single source of truth for all clients. The scope of status-go is very broad.

At its core, status-go implements the Status protocol. This includes features such as waku integration, account generation, secure transport (e.g., end-to-end encryption using extended Diffie-Hellman and double ratchet), as well as chat functionalities like 1:1 chats, group chats, communities, syncing, pairing, and more.

In addition to protocol-related functionalities, status-go supports client-oriented features such as a media server for serving images, an activity center for notifications, and push notifications. It also provides utilities for client consumption, such as public key serialization across different formats.

Furthermore, status-go implements the complete wallet backend. It handles wallet account generation and derivation, provides a router for multi-chain transactions, and integrates with providers such as Infura (currently accessed through a proxy). These are just a few examples of the wallet features managed by status-go.

Another crucial role of status-go is data persistence, managed through various SQLite databases. It securely stores essential data, including accounts, chats, messages, notifications, transactions, and more — effectively handling all non-client-specific data.

Overview

Status protocol implementation

• Transport layer - Waku integration
  • Configuration: relay, light-push, fleets, message size, etc.
  • Message sending/receiving
    • Pubsub and content topic subscriptions
    • Relay or light-push pushes
    • Basic symmetric encryption (key derived from a chat name string)
    • Store node interactions
• Segmentation layer
  • Segments app-layer messages larger than N bytes to make them compatible with the transport layer
• Encryption layer
  • X3DH & Double-Ratchet: Used for private messaging, including 1:1 and group chats
  • Hash-Ratchet: Used for communities
• End-to-end reliability layer
  • MVDS for 1:1 and group chats
• App layer
  • Accounts
    • Key generation/derivation
      • Waku key
      • Wallet keys
    • Private key conversion from/to seed phrase
    • Public key serialization
    • Color hash and emoji hash generation
  • Profile
    • Display name
    • ENS integration
    • Status: online, inactive, automatic
    • Avatar
    • Showcase (social URLs, communities, collectibles)
      • Visibility levels (e.g., show to contacts only)
  • Contacts
    • Requests
    • Management (ban, mark as trustworthy/untrustworthy)
  • Retrieve messages loop
    • Process messages from filters
    • Cast messages to proper Protobuf based on type
    • Notify clients about changes through signals
  • Messaging
    • Chat types
      • 1:1 Chats
        • Ensured PFS and post-compromise security with X3DH & Double-Ratchet
      • Group Chats
        • Up to 20 members
        • Effectively 1:1 chats with every member, inheriting 1:1 chat properties
      • Community Channels
        • Unlimited members in theory; ~10k in practice due to network shard constraints
        • Token-gated communities and channels are encrypted with Hash-Ratchet
    • Chat functionalities:
      • First unread, mute, mentions, pins, search, member list.
    • Messages
      • State (sending, sent)
      • Replies
      • Discord bridge
      • Images and albums
  • Group chats
    • Eventual consistency via complete history of all events ever propagated
    • Roles: admin and members
    • Events
      • Create group
      • Change: name, color, image
      • Member actions: add, join, remove
      • Admin actions: add, remove
  • Communities
    • Eventual consistency via CommunityDescription propagated by control node, combined with a list of events applied by privileged members (wiped after control node application)
    • Roles: owner, token-master, admin, member
      • Control node: One device of the owner; ensures simplicity and avoids issues related to missynchronization between owner devices
    • Events
      • Edit community (name, description, banner, etc.)
      • Token permission: change(aka create, edit), delete
      • Channel: create, edit, delete, reorder
      • Category: create, delete, edit, reorder
      • Member actions: kick, ban, unban
      • Join requests: accept, reject
      • Delete banned member messages
      • Community token (admin token): add
    • Ownership
      • Communities without an owner-token: private key holder
      • Communities with an owner-token: owner-token holder
        • Ownership transfer flow implementation: interaction with contracts and wallet
    • Role management
      • Token minting: owner, token-master, admin tokens
      • Airdropping
      • Remote destruction
    • Token-gating
      • Token permissions per community or channel
      • Ad-hoc permission checks for clients
    • Members reevaluation
      • Reevaluates token permissions and removes members who no longer meet criteria, globally and per channel
    • Encryption key management
      • Distributes/rotates encryption keys based on member list changes, globally and per channel
    • Archive protocol
      • Historical message archives via control node
      • BitTorrent integration with magnet link distribution
      • No support for ownership transfer
    • Discord import tool
    • Peersyncing
      • E2E reliability for communities (not enabled, never dogfooded)
  • Backup
    • Retrieves data from store-nodes on account restoration
    • Data includes profile, contacts, chats, communities, keypairs, watch-only accounts, settings, etc.
  • Pairing
    • Pairs multiple devices to keep them in sync
    • Mostly same data as for backup + notifications

Wallet features

• Assets (ETH/ERC20)
• Collectibles (ERC721/ERC1155)
• Activity
• Route suggestion
• Route execution
• Onramp/Offramp