Problem

The status-go codebase lacks architectural modularity, making it difficult to isolate and reuse individual features. This is particularly evident in the messaging part, which is hard to extend or maintain. Although Go enforces package boundaries and acyclic dependencies, the absence of clear layering results in interdependencies between components at different levels of abstraction, creating tight coupling across the system.

graph TD
	app --> message_sender
	message_sender --> reliability
	message_sender --> encryption
	message_sender --> segmentation
	message_sender --> transport
	message_sender --> waku

	reliability --> mvds
	encryption --> double_ratchet

	segmentation --> waku
	transport --> waku

	app --> encryption
	app --> double_ratchet
	app --> mvds
	app --> waku

For example, the waku appears throughout the codebase, across both high- and low-level modules. This makes the system difficult to reason about, limits flexibility, and increases the risk of misuse.

Strategy

The refactoring strategy consists of three phases:

Phase 1: Introduce a Messaging Facade

Description: The first step is to encapsulate messaging complexity behind a unified interface (messaging). This facade will manage reliability, encryption, segmentation, and transport concerns internally, exposing a high-level API to the application layer.

graph TD
	app --> messaging

	messaging --> message_sender
	message_sender --> reliability
	message_sender --> encryption
	message_sender --> segmentation
	message_sender --> transport
	message_sender --> waku

	reliability --> mvds
	encryption --> double_ratchet

	segmentation --> waku
	transport --> waku

	messaging --> encryption
	messaging --> double_ratchet
	messaging --> mvds
	messaging --> waku

	style messaging stroke:#ff0,stroke-width:2px

What it enables:

• Clear API boundary between application and messaging
• Serves as a concrete reference point for aligning with Waku’s ChatSDK; differences between the APIs can surface mismatches, drive requirement discussions, and close design gaps
• Provides ownership and iteration independence
• (optional) Enables messaging module extraction into a standalone repository with its own lifecycle

Cons:

• The facade must include many adapters to interface with existing tangled logic, increasing short-term complexity

Phase 2: Decouple Messaging Internals

Description: Refactor internal dependencies inside the messaging module to remove cross-layer leaks and tightly bound components (e.g., remove direct use of Waku types outside transport).

graph TD
	app --> messaging

	messaging ==> reliability
	messaging ==> encryption
	messaging ==> segmentation
	messaging ==> transport

	reliability ==> mvds
	encryption ==> double_ratchet
	transport ==> waku

What it enables: