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
    • Role management
    • Token-gating
    • Members reevaluation
    • Encryption key management
    • Archive protocol
    • Discord import tool
    • Peersyncing
  • Backup
  • Waku pairing and sync
  • Local Transfer and Pairing

Wallet features

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