rednexa

Building Nexa: Bridging the Digital Divide with Decentralized, Offline-First Communication

As a CS3 Capstone Project undertaken by a team of three students, Nexa was born from a critical observation: while digital communication is widespread, many communities remain underserved due to unreliable internet access. This project aimed to tackle that challenge, creating a mobile application that redefines social networking for rural and township communities.

The Inspiration: A World Disconnected

Mainstream social platforms assume constant online access, systematically excluding millions in areas with poor or intermittent internet. Imagine a community where sharing a simple message or organizing an event is a constant struggle due to network limitations. This was Nexa's core inspiration – to empower these communities with a robust, reliable, and secure communication tool, regardless of internet availability. Our team worked closely with a supervisor, guiding us through the process of delivering a working prototype.

Our Development Journey: A Structured Approach

The capstone project followed a rigorous software engineering methodology, structured into four distinct stages:

1. Project Start-up: Defining scope, objectives, and team roles.
2. Planning and Modelling: Developing use-case scenarios, analysis models, and a comprehensive project plan.
3. Prototype: Creating a functional prototype for core feature demonstration and early feedback.
4. Implementation and Testing: Bringing all use cases to fruition, thoroughly testing the product, and documenting the process.

This structured approach, coupled with a dedicated effort of approximately 10 hours per week per team member, ensured systematic progression from concept to a demonstrable product.

What We Built: A Resilient Communication Ecosystem

Our capstone project delivered a functional Android application with features designed for resilience and user empowerment:

• User Onboarding & Local Identity: Users create local identities without phone numbers or email addresses, ensuring accessibility and privacy.
• Peer Discovery: Automatic discovery of nearby peers via proximity-based scanning (Bluetooth, Wi-Fi Direct) and manual connections using QR codes.
• One-to-One Messaging: Secure, end-to-end encrypted direct messages.
• Group Channels: "Community channels" for group discussions and collaboration.
• Multimedia Sharing: Support for text, image, and voice messages.
• Delay-Tolerant Networking (DTN): The core innovation enabling message delivery even without a continuous connection.
• Robust Security: All communication is secured with end-to-end encryption; data is stored locally.
• Optional Cloud Sync: Data can be synced to the cloud when internet access is available.
• Accessibility: Intuitive navigation and voice messaging support.

The Core Innovation: Delay-Tolerant Networking (DTN)

Nexa's true differentiator is its implementation of Delay-Tolerant Networking (DTN). In environments with intermittent connections, traditional networking protocols fail. DTN, however, thrives in such conditions.

Here's how Nexa's DTN works:

1. Message Hopping: When a message cannot be delivered directly, it's stored on the sender's device. It then "hops" through any nearby Nexa-enabled devices it encounters. Each device acts as a temporary relay, carrying the message closer to its destination with every new connection.
2. Time-to-Live (TTL): Each DTN message has an expiration timestamp. This prevents messages from circulating indefinitely and ensures only relevant information is delivered. Users can configure this setting.
3. Hop Count: A "hop count" limits how many times a message can be relayed, optimizing network traffic and resource usage.
4. Local Storage & Pruning: Messages are stored locally until delivery or expiration. A pruning mechanism regularly cleans up expired messages.
5. Intelligent Routing: Nexa prioritizes direct delivery when possible. If not, it intelligently broadcasts messages to connected peers to maximize delivery chances through intermediate hops. This includes peers requesting missing messages from each other during discovery handshakes for data synchronization.
6. Message Types: The DTN layer handles various message types, including direct messages, group messages, friend requests, channel invites, and discovery handshakes, each processed specifically.

The Nexa Protocol: How Messages Traverse the Network

Nexa's communication isn't just about sending messages; it's about ensuring they arrive, even when the network is unreliable. This is achieved through a custom protocol built on DTN principles, primarily managed by the ConnectionService.

The DtnMessage: The fundamental unit of communication. It's a self-contained packet containing:

• id: Unique identifier for deduplication.
• source, destination: Stable IDs of sender/intended recipient.
• payload: The actual content (encrypted or unencrypted).
• ttl, hopCount: For message longevity and forwarding limits.
• timestamp: When the message was created.
• messageType: Defines the content (e.g., DIRECT_MESSAGE, FRIEND_REQUEST, DISCOVERY_HANDSHAKE).

The Three Pillars of the Protocol:

1. send(destinationId, content, recipientPublicKeyString):

   • Purpose: Initiates message transmission.
   • Process:
     • Determines the DtnMessageType based on the content.
     • End-to-End (E2E) Encryption: If a recipientPublicKeyString is provided (for direct messages, friend requests, channel invites), the content is E2E encrypted using Google Tink and the recipient's public key. This ensures only the intended recipient can read the message.
     • A DtnMessage is created with appropriate ttl and hopCount (from user-configurable DTN settings).
     • The DtnMessage is stored in the local DtnStore.
     • The route() function is immediately called to attempt delivery or forwarding.

2. onReceive(dtnMessage, senderPeer):

   • Purpose: Handles an incoming DtnMessage from a connected peer.
   • Process:
     • Deduplication: Checks the DtnStore to prevent processing duplicate messages.
     • Storage: The DtnMessage is stored locally in the DtnStore.
     • Destination Check: Determines if the message is for the current user (matching userId, NEXA_BROADCAST_ALL, or if the user is a member of a GROUP_ channel).
     • Payload Processing: If the message is for the current user, processPayload() is called to decrypt (if E2E encrypted) and act on the message (e.g., save to chat, store friend request, join channel).
     • Forwarding: Regardless of whether the message was for the current user, route() is always called to ensure the message continues its journey.

3. route(dtnMessage, senderPeer):

   • Purpose: The core forwarding logic, deciding the next hop for a DtnMessage.
   • Process:
     • TTL/Hop Count Check: Messages with hopCount <= 0 are discarded.
     • Decrement Hop Count: A copy of the message is created with a decremented hopCount.
     • Direct Delivery Optimization: If the dtnMessage.destination is a currently connectedPeer, direct delivery is attempted via sendToPeer().
     • Broadcast Forwarding: If not directly deliverable, the message is broadcast to all other currently connectedPeers (excluding the senderPeer to prevent immediate loops).
     • Hop-by-Hop Encryption: When sending a DtnMessage to a connected peer via sendToPeer(), the entire DtnMessage (including its metadata) is hop-by-hop encrypted using Google Tink and the next hop's public key. This ensures that while the message is in transit between devices, its contents are protected from intermediate nodes. Only the E2E payload remains encrypted from source to final destination.

Why this approach?

• Resilience: Guarantees message delivery in intermittent networks, a critical need for our target communities.
• Efficiency: TTL and hopCount prevent network flooding. Direct delivery optimization reduces unnecessary hops.
• Security: Layered encryption (E2E for content, hop-by-hop for DTN metadata) ensures privacy at every stage.
• Scalability: The decentralized nature allows the network to grow organically with more users.

What We Learned from the Protocol: Implementing a robust DTN protocol presented unique challenges. We learned the importance of careful state management for the local message store and unique message IDs for deduplication. Balancing message propagation with device resource consumption (CPU, battery, storage) through configurable TTL and hopCount settings was a key design consideration. Furthermore, understanding the interplay between end-to-end encryption for message content and hop-by-hop encryption for DTN metadata was crucial for achieving comprehensive security without compromising the forwarding mechanism. Testing complex asynchronous message flows across multiple simulated devices proved challenging but essential for validating the protocol's reliability.

The Technology Stack: Modern Android Development

To bring Nexa to life, we leveraged a modern and robust technology stack:

• Kotlin for Android: The entire application is built using Kotlin, taking advantage of its conciseness, safety, and excellent support for asynchronous programming.
• Jetpack Compose: The user interface is entirely developed with Jetpack Compose, Android's modern toolkit for building native UI. This allowed for a declarative, efficient, and visually appealing user experience.
• Google Nearby Connections API: This API was crucial for enabling low-level, device-to-device communication via Bluetooth and Wi-Fi Direct, forming the backbone of Nexa's peer-to-peer capabilities.
• Google Tink Cryptography Library: For end-to-end encryption and secure key management, we integrated Google Tink. This powerful cryptographic library provided robust, industry-standard security primitives, ensuring user privacy and data integrity.
• Hilt for Dependency Injection: Hilt, built on Dagger, streamlined dependency management, making the codebase more modular, testable, and maintainable.
• Room Persistence Library: For local data storage, including messages, contacts, and DTN messages, we utilized Room, an SQLite object mapping library that provides an abstraction layer over SQLite.
• Kotlinx Serialization: This library was used for efficient and safe serialization and deserialization of data models, particularly for transmitting complex objects like DtnMessage and TransmissionPayload across the network.

Lessons Learned & Future Directions

This capstone project was an incredible journey, offering invaluable insights into building resilient, decentralized systems. Key lessons included:

• Complexity of P2P Networking: Managing dynamic peer connections, disconnections, and data synchronization in an offline-first environment presented unique challenges.
• Importance of Robust Cryptography: Implementing secure communication from the ground up required a deep understanding of cryptographic principles and careful integration of libraries like Google Tink.
• State Management in Compose: Effectively managing UI state in a reactive Compose application, especially with real-time data streams from the network, was a continuous learning process.
• DTN Optimization: Balancing message persistence (TTL, hop count) with device resource usage (storage limits) is a delicate act that requires careful tuning.

Looking ahead, Nexa has immense potential for further development. Future enhancements could include:

• Advanced DTN Routing Algorithms: Exploring more sophisticated routing strategies (e.g., epidemic routing, history-based routing) to improve delivery rates and efficiency.
• Group Key Management: Implementing secure group key exchange for truly end-to-end encrypted group channels.
• Content Addressing: Utilizing content addressing (e.g., IPFS-like mechanisms) for more efficient and resilient multimedia sharing.
• Cross-Platform Support: Expanding Nexa to other mobile platforms or even desktop environments.
• Community Moderation Tools: Developing features for community leaders to manage channels and members effectively.

Conclusion

Nexa represents more than just a mobile application; it's a testament to the power of technology to address fundamental societal challenges. By providing a decentralized, offline-first communication platform, we aimed to empower communities that have historically been left behind by the digital revolution. This CS3 Capstone Project not only honed our technical skills in modern Android development, networking, and cryptography but also deepened our understanding of the critical role software engineering can play in fostering inclusion and connectivity.