P2P Chat and Data Storage for Affordable Mobile Devices¶

Reference Material for mpowerup (Big Nerd Idea)¶

Date: May 24, 2026
Topic: Decentralized messaging, P2P storage, and offline-first architecture for resource-constrained mobile devices

Table of Contents¶

Helia/IPFS Overview
Mobile Constraints
Open Source Alternatives
Technology Comparison Matrix
Recommended Stack
Architecture Examples
Security Considerations
Implementation Resources

Helia/IPFS Overview¶

What is Helia?¶

Helia is a modern JavaScript/TypeScript IPFS (InterPlanetary File System) client designed for lightweight P2P applications.

Key Characteristics: - Content-addressed storage (files identified by cryptographic hash) - Distributed storage across peer nodes - Works in browsers, Node.js, and other JavaScript environments - Built on libp2p for P2P networking - Full open source (Apache 2.0 license)

How Helia Works¶

Content-Addressed Storage¶

// Store a message - identified by its hash
const encoded = new TextEncoder().encode("Hello, P2P world!");
const cid = await helia.blockstore.put(encoded);
// Same content always = same hash (immutable)
// Retrieve from any peer: helia.blockstore.get(cid)

P2P Network & Peer Discovery¶

Uses DHT (Distributed Hash Table) for peer discovery
Nodes announce content availability
Others discover and download from multiple peers simultaneously
No central server required
Works across NATs and firewalls (with relay nodes)

IPLD (InterPlanetary Linked Data)¶

Enables structured, cryptographically-linked data:

// Create linked folder structure
const folder = {
  files: [
    { name: "photo.jpg", hash: CID1 },
    { name: "notes.txt", hash: CID2 }
  ],
  metadata: { owner: alicePublicKey, created: timestamp }
};

const folderCid = await helia.dag.put(folder);
// Modifying any file changes the folder's CID

IPNS (Mutable Pointers)¶

// Publish mutable reference to latest data
const key = await helia.libp2p.keychain.createKey("my-data", "Ed25519");
const ipnsName = await helia.ipns.publish(key, latestCid);

// Discover latest version
const resolved = await helia.ipns.resolve(ipnsName);

Helia for Secure Chat¶

Message Structure¶

{
  id: "hash-of-message",
  from: "peer-public-key",
  to: "recipient-public-key",
  timestamp: 1234567890,
  content: "encrypted-payload",
  signature: "sender-signature"
}

Implementation Flow¶

Alice encrypts message with Bob's public key
Sign message with Alice's private key
Store as DAG in Helia: await helia.dag.put(signed)
Bob discovers via DHT: await helia.dht.findProviders(cid)
Bob retrieves: await helia.dag.get(cid)
Bob verifies signature with Alice's public key
Bob decrypts with shared secret

Helia Strengths¶

✅ No single point of failure
✅ Cryptographic proof of integrity (hashes)
✅ Cryptographic proof of authorship (signatures)
✅ User-controlled encryption
✅ Censorship-resistant (distributed replication)
✅ Full file storage + messaging in one system

Helia Weaknesses for Mobile¶

❌ High RAM usage: 100-200 MB just to start
❌ High CPU overhead: Constant DHT queries
❌ Battery drain: Aggressive networking
❌ Large storage footprint: IPFS overhead
❌ NOT optimized for intermittent connectivity
❌ Not designed for offline-first scenarios

Mobile Constraints¶

Affordable Used Mobile Devices (2015-2018 era)¶

Specification	Capability
RAM	512 MB - 2 GB
CPU	Snapdragon 410-600 class (very weak by 2026 standards)
Storage	8-16 GB (often heavily full)
Battery	2000-3000 mAh (ages poorly)
Network	3G/4G, intermittent WiFi, metered data

Critical Constraints for P2P Apps¶

Memory: Apps competing for <500 MB available after OS
CPU: Heavy cryptography/DHT operations cause lag and battery drain
Storage: Limited space for local caching/pinning
Battery: Background P2P networking kills battery in hours
Network: Unreliable connections, data costs matter in developing regions
Offline operation: Crucial for areas with poor connectivity

Why Helia Fails on Low-End Mobile¶

Minimum 100 MB RAM requirement exceeds typical headroom
DHT queries run continuously = battery drain
No offline-mesh capability = useless without connectivity
Storage overhead = impossible on 8 GB phones already full
CPU-intensive crypto = phone becomes unusable

Open Source Alternatives¶

1. Briar¶

Perfect for low-end mobile offline-first P2P chat

Repository: github.com/guardianproject/briar
License: GPLv3 (Open Source)
Language: Android/Java

What It Does¶

End-to-end encrypted P2P messaging
Works offline via Bluetooth mesh between nearby devices
When online, syncs via Tor (no internet provider visibility)
Contact verification via QR codes
Group chat support
No server required ever

Resource Usage¶

RAM: 20-50 MB (extremely light)
CPU: Minimal (efficient encryption)
Battery: Excellent (uses Bluetooth efficiently)
Storage: ~50 MB for app + database

Architecture¶

No Internet Scenario:
├─ Alice's phone (offline)
├─ Bob's phone (offline)
└─ Carol's phone (offline)
    ↓ Bluetooth mesh syncs messages between all three
    ↓ When any device goes online, syncs via Tor
    └─ Others' messages propagate back via mesh

Ideal For¶

✅ Communities with poor connectivity
✅ Activists/censorship-prone regions
✅ Emergency communication mesh networks
✅ Offline-first applications
✅ Group organizing

Limitations¶

❌ Chat only (no file storage)
❌ Limited Tor bandwidth (video won't work)
❌ Slower peer discovery than centralized
❌ Bluetooth range ~50-100 meters

Getting Started¶

# Install on Android
# Download APK from guardian-project.info or F-Droid

# Self-hosting relay (optional, for bridging to distant peers):
# Requires Tor bridge + relay server setup

2. Jami (formerly GNU Ring)¶

Full-featured P2P for calling, messaging, file sharing

Repository: github.com/savoirfairelinux/jami
License: GPLv3 (Open Source)
Platforms: iOS, Android, Linux, Windows, macOS

What It Does¶

P2P encrypted chat
Voice and video calls (low-bandwidth modes)
File transfer P2P
No phone number or email required
Works offline (caches messages locally)
DHT-based peer discovery

Resource Usage¶

RAM: 50-80 MB (light-medium)
CPU: Moderate (video encoding optional)
Battery: Good (efficient codecs)
Storage: ~100 MB app + media cache

Strengths¶

✅ All-in-one (chat, calls, files)
✅ Works on phones with <1 GB RAM
✅ Offline capability
✅ No server required
✅ Simple account setup (no email verification needed)

Limitations¶

❌ Slower peer discovery (DHT)
❌ Video quality suffers on poor connections
❌ Larger app than lightweight alternatives

Use Case¶

Best for: Communities needing voice + messaging + file sharing, with occasional internet access.

3. XMPP + Omemo¶

Lightweight, federated chat with strong encryption

Repositories:
  - Server: github.com/processone/ejabberd (or Prosody)
  - Client: github.com/iNPUTmice/Conversations (Android)
License: GPLv3 (Open Source)
Platforms: Works with any XMPP server

What It Does¶

Real-time encrypted chat (Omemo E2E encryption)
Federated (can use public servers or self-host)
Group chat support
Message archiving (on server, encrypted)
Very lightweight

Resource Usage¶

RAM: 10-30 MB (minimal!)
CPU: Very light
Battery: Excellent
Storage: ~5 MB for app

Architecture Options¶

Option A: Public Server (Easy)

User's Phone → Public XMPP Server → Other Users
(similar to email, but encrypted)
Can use: conversations.im, disroot.org, etc.

Option B: Self-Hosted (Private)

User's Phone → Your XMPP Server → Other Users
(complete control, no dependence on third parties)

Strengths¶

✅ Tiny footprint (works on 512 MB RAM phones!)
✅ Battle-tested (20+ year protocol)
✅ Strong encryption (Omemo)
✅ Can be fully P2P (self-hosted) or federated
✅ Minimal battery drain
✅ Hybrid: can work offline-first with local caching

Limitations¶

❌ Requires internet (no offline mesh)
❌ If using public server, metadata visible to server
❌ Chat-only (no built-in file sharing)

Recommended Setup for mpowerup¶

1. Lightweight XMPP Server: Prosody (10 MB footprint)
   - Self-hosted option for communities
   - Can bridge to other protocols

2. Client: Conversations (Android)
   - Omemo encryption built-in
   - 15 MB RAM usage

3. Storage: Syncthing (separate)
   - Handles encrypted file backup
   - P2P sync without server

Getting Started¶

# Server: Install Prosody
# docker run -d prosody/prosody

# Client: Install Conversations
# Get from F-Droid or conversations.im

# Self-host XMPP for complete privacy

4. Syncthing¶

P2P encrypted file synchronization

Repository: github.com/syncthing/syncthing
License: MPLv2 (Open Source)
Platforms: Windows, macOS, Linux, Android, iOS

What It Does¶

Sync files across devices P2P
End-to-end encrypted
No cloud storage required
Works offline (queues syncs for later)
Direct connections between devices
Relay servers if direct connection impossible

Resource Usage¶

RAM: 50 MB (moderate)
CPU: Light
Battery: Good
Storage: ~20 MB app + minimal overhead

Architecture¶

Alice's Phone ↔ (Direct connection) ↔ Bob's Phone
    ↓ (If can't connect directly)
    └─→ Relay Server ←─ Bob's Phone
        (encrypted relay, server sees no data)

Strengths¶

✅ Best-in-class P2P file sync
✅ Works on weak devices
✅ Works offline (syncs when reconnected)
✅ True end-to-end encryption
✅ Mobile clients available

Limitations¶

❌ File sync only (not chat)
❌ Requires devices to have met before (discovery step)
❌ Not optimized for real-time chat

Use Case¶

Best for: Backup, photo sync, document collaboration across devices.

5. Scuttlebutt (SSB)¶

Append-only log P2P social network protocol

Repository: Multiple (ssb-ngi-pointer)
License: Open Source
Clients: Manyverse (Android), Patchwork (desktop)

What It Does¶

Peer-to-peer social network
Each peer keeps append-only log of posts/messages
Gossip protocol syncs logs between peers
Works offline (syncs when reconnected)
Messages, files, social connections
No server ever (pure P2P)

Resource Usage¶

RAM: 30-60 MB (light-medium)
CPU: Efficient
Battery: Good
Storage: ~100 MB database (grows over time)

How It Works¶

Alice creates post → Stored in Alice's append-only log
↓
Bob connects to Alice → Bob copies Alice's log
↓
Bob creates post → Stored in Bob's log
↓
Carol connects to Bob → Gets both Alice & Bob's logs
↓
Posts sync through the gossip network

Strengths¶

✅ Works offline
✅ Simple data model (append-only)
✅ True P2P (no servers)
✅ Good privacy (no metadata tracking)
✅ Good on low-end devices
✅ Mobile-friendly (Manyverse app)

Limitations¶

❌ Database grows (old messages not pruned)
❌ Slower sync on poor connections
❌ Less familiar architecture than XMPP
❌ Smaller ecosystem

Use Case¶

Best for: Communities, social networks, offline-first applications.

6. Cwtch¶

Metadata-resistant P2P messenger

Repository: github.com/openprivacy/cwtch
License: Open Source
Platforms: Android, iOS, desktop

What It Does¶

Encrypted P2P messaging
Metadata privacy (hide who's talking to whom)
Uses Tapir protocol (Tor-based but lighter)
Group chat support
File sharing

Resource Usage¶

RAM: 40 MB
CPU: Light
Battery: Good
Storage: ~80 MB

Key Feature: Metadata Resistance¶

Normal encrypted chat:
├─ Message contents: Encrypted ✓
├─ Sender/recipient: Visible ✗
└─ Timing: Visible ✗

Cwtch:
├─ Message contents: Encrypted ✓
├─ Sender/recipient: Hidden ✓
├─ Timing: Hidden ✓
└─ Connection pattern: Hidden ✓

Strengths¶

✅ Maximum privacy
✅ Lightweight
✅ Mobile-friendly
✅ True P2P

Limitations¶

❌ Requires internet (no offline mesh)
❌ Smaller community than Briar
❌ Less mature

Use Case¶

Best for: High-security applications, journalists, activists requiring metadata privacy.

Technology Comparison Matrix¶

Resource Usage¶

Technology	RAM	CPU	Battery	Storage
Helia/IPFS	100-200 MB	High	Poor	High overhead
Briar	20-50 MB	Low	Excellent	~50 MB
Jami	50-80 MB	Moderate	Good	~100 MB
XMPP/Conversations	10-30 MB	Very Low	Excellent	~5 MB
Syncthing	50 MB	Low	Good	~20 MB
Scuttlebutt/Manyverse	30-60 MB	Low	Good	~100 MB+
Cwtch	40 MB	Low	Good	~80 MB

Feature Comparison¶

Feature	Helia	Briar	Jami	XMPP	Syncthing	SSB	Cwtch
Chat	✓	✓✓	✓	✓✓	✗	✓	✓
Voice/Video	✗	✗	✓	✗	✗	✗	✗
File Storage	✓✓	✗	✓	✗	✓✓	✓	✓
Offline Mesh	✗	✓✓	✗	✗	✗	✓	✗
Works on 512 MB RAM	✗	✓	✓	✓✓	✓	✓	✓
No Server Required	✓	✓	✓	~	✓	✓	✓
Metadata Privacy	✓	✓	✓	~	✓	✓	✓✓
Mobile App Quality	✓	✓✓	✓	✓	✓	✓	✓
Maturity	✓	✓✓	✓✓	✓✓✓	✓✓✓	✓	✓

Recommended Stack¶

Scenario 1: Offline-First Communities (No Internet Assumed)¶

Best for: Humanitarian organizations, disaster response, rural communities

Stack:
├─ Briar (primary chat)
│  ├─ Bluetooth mesh between devices
│  ├─ Tor sync when online
│  └─ 20-50 MB RAM usage
│
└─ Syncthing (optional file backup)
   ├─ P2P file sync
   └─ 50 MB RAM usage

Total RAM: 70-100 MB
Minimum Phone: 512 MB RAM

Setup:

1. Install Briar on all devices
2. Exchange Briar contact info via QR code
3. Devices now form offline mesh automatically
4. When any device gets online → syncs via Tor
5. (Optional) Install Syncthing for document backup

Scenario 2: Resource-Constrained With Internet¶

Best for: Developing regions, low-bandwidth areas, maximum device compatibility

Stack:
├─ XMPP + Conversations (primary chat)
│  ├─ 10-30 MB RAM
│  ├─ Self-hosted Prosody server (optional)
│  └─ Strong encryption (Omemo)
│
├─ Syncthing (file sync)
│  ├─ 50 MB RAM
│  └─ P2P encrypted backup
│
└─ Scuttlebutt/Manyverse (optional social)
   ├─ 30-60 MB RAM
   └─ Offline-capable posts/comments

Total RAM: 90-140 MB
Minimum Phone: 512 MB RAM (XMPP only) to 1 GB (with extras)

Setup:

1. Install Prosody on server:
   docker run -d prosody/prosody

2. Install Conversations on phones
   Get from F-Droid: f-droid.org

3. Set up account in Conversations → connect to Prosody

4. Install Syncthing for file sync

5. Optional: Install Manyverse for social features

Scenario 3: All-in-One (Chat + Calls + Files)¶

Best for: Communities needing voice capability, occasional connectivity

Stack:
├─ Jami (chat + voice + files)
│  ├─ 50-80 MB RAM
│  ├─ P2P calling without servers
│  └─ File transfer built-in
│
└─ Syncthing (backup layer)
   └─ 50 MB RAM

Total RAM: 100-130 MB
Minimum Phone: 1 GB RAM

Setup:

1. Install Jami from F-Droid or jami.net
2. Create account (no email required)
3. Share your Jami ID with others
4. Add contacts → automatic P2P connection
5. Optional: Install Syncthing for backup

Scenario 4: Maximum Privacy (Metadata Resistant)¶

Best for: Journalists, activists, sensitive organizing

Stack:
├─ Cwtch (metadata-resistant chat)
│  ├─ 40 MB RAM
│  └─ Complete metadata hiding
│
└─ Syncthing (separate encrypted backup)
   └─ 50 MB RAM

Total RAM: 90 MB
Minimum Phone: 512 MB RAM

Architecture Examples¶

Briar Offline Mesh Architecture¶

┌─────────────────────────────────────────────────┐
│           Briar P2P Offline Mesh                │
└─────────────────────────────────────────────────┘

Scenario: 5 phones in rural area, no connectivity

    Alice ↔ Bob
      ↑     ↑
      └─ Carol
           ↑
         Dave ↔ Eve

Each phone:
├─ Stores all messages locally
├─ When meets another phone (Bluetooth)
│  └─ Syncs messages bidirectionally
└─ When any phone goes online (Tor)
   └─ Uploads messages to Briar relay
   └─ Downloads messages from relay
   └─ Relay forwards to other peers' Tor connections

Result: Messages propagate across entire mesh even if all offline

XMPP + Prosody Server Architecture¶

┌──────────────────────────────────────────────────┐
│   Self-Hosted Community Communication Setup      │
└──────────────────────────────────────────────────┘

Internet
  ↓
Prosody Server (1 server)
├─ Domain: chat.community.org
├─ Hosted on $5-10/month VPS
├─ Uses <100 MB RAM
└─ Stores encrypted messages

Users:
├─ Alice (phone)
│  └─ [email protected]
├─ Bob (phone)
│  └─ [email protected]
├─ Carol (laptop)
│  └─ [email protected]
└─ Dave (old phone)
   └─ [email protected]

All using Conversations app (or similar Omemo-enabled client)
- End-to-end encryption (server can't read messages)
- Server only sees: who connected, message timestamps
- No dependence on corporate servers
- Full control over data

Hybrid: Briar + Syncthing + XMPP¶

┌────────────────────────────────────────────────┐
│   Resilient Multi-Layer Architecture           │
└────────────────────────────────────────────────┘

Layer 1: Real-time Chat
├─ XMPP (if connected)
│  ├─ Messages within seconds
│  └─ Omemo encrypted
└─ Briar (if offline)
   ├─ Messages queue locally
   └─ Syncs when others nearby or online

Layer 2: File Backup
├─ Syncthing
├─ Continuous sync of important files
└─ Works offline (syncs later)

Layer 3: Social/Posts
├─ Scuttlebutt (Manyverse)
├─ Decoupled from chat
└─ Append-only posts

Result:
✓ Real-time chat when possible
✓ Offline mesh messaging (Briar)
✓ File backup (Syncthing)
✓ Social network (SSB)
✓ Works on 512 MB - 1 GB RAM phones
✓ Multiple redundant systems

Security Considerations¶

Strengths of These Approaches¶

✅ End-to-End Encryption: Message content encrypted before leaving device
✅ No Single Point of Failure: Distributed systems (except optional Prosody server)
✅ Cryptographic Verification: Signatures prove message authenticity
✅ User-Controlled Keys: Only you hold decryption keys
✅ Open Source: Code auditable, no backdoors
✅ Censorship-Resistant: Distributed content replicated across peers

Challenges to Address¶

1. Key Management¶

Problem: Loss of private key = permanent data loss
Mitigation: - Write seed phrase on paper (keep secure) - Back up encryption keys to encrypted USB - Use LUKS-encrypted external storage - Never store keys in cloud unencrypted

2. Metadata Privacy (XMPP)¶

Problem: Server sees who connects and when
Mitigation: - Use Tor if maximum privacy needed - Self-host Prosody (you control the data) - Use Cwtch for metadata resistance - Use Briar (metadata hidden via Tor)

3. Metadata Privacy (Briar)¶

Problem: Tor exit nodes could identify you
Mitigation: - Briar designed to minimize this risk - Uses Tor bridges (harder to block) - Device-level encryption recommended - Phone ownership authentication (fingerprint/pattern)

4. Device Security¶

Problem: Phone compromise = compromise of all messages
Mitigation: - Enable device encryption (most phones default now) - Screen lock (pattern/password/biometric) - Regular security updates - Don't install untrusted apps - Keep apps updated (F-Droid auto-updates available)

5. Initial Trust Establishment¶

Problem: How do you know you're talking to the right person?
Mitigation: - Briar: QR code exchange in person - Jami: Verify Jami ID in person - XMPP: OMEMO fingerprint verification - Cwtch: Trust on first use + verification codes - In-person verification essential for high-security use cases

6. Network Attacks¶

Problem: Attacker intercepts messages
Mitigation: - All traffic encrypted (attacker sees only encrypted data) - Perfect forward secrecy (if device compromised later, past messages safe) - Signature verification (tampering detected)

Implementation Resources¶

Documentation & Guides¶

Briar¶

Official: briarproject.org
Guide: "Briar Offline Mesh" tutorials
Source: github.com/guardianproject/briar
App: Available on F-Droid

Jami¶

Official: jami.net
Documentation: jami.net/wiki
Source: github.com/savoirfairelinux/jami
Support: Community forum at jami.net

XMPP¶

Official: xmpp.org
Prosody Server: prosody.im
Conversations App: conversations.im
Tutorial: conversations.im/quickstart
Omemo Encryption: xmpp.org/extensions/xep-0384.html

Syncthing¶

Official: syncthing.net
Documentation: docs.syncthing.net
Source: github.com/syncthing/syncthing
Tutorial: syncthing.net/intro

Scuttlebutt¶

Official: scuttlebutt.nz
Manyverse App: manyver.se
Documentation: ssbc.github.io
Source: Multiple repos at github.com/ssb-ngi-pointer

Cwtch¶

Official: cwtch.im
Source: github.com/openprivacy/cwtch
Docs: cwtch.im/download

F-Droid (Open Source App Store)¶

All apps can be installed from F-Droid:

F-Droid.org

Apps relevant to mpowerup:
├─ Briar (messaging)
├─ Conversations (XMPP client)
├─ Syncthing (file sync)
├─ Manyverse (Scuttlebutt)
├─ Jami (voice + messaging)
└─ Cwtch (metadata-resistant messenger)

Community Resources¶

Open Source Communities¶

Tor Project: tor.org (underlying infrastructure for Briar)
Guardian Project: guardianproject.info (Briar developers)
Disroot: disroot.org (free XMPP + other services)
Conversations Community: conversations.im/community

Development Resources¶

libp2p: js.libp2p.io (underlying P2P layer)
libsodium.js: libsodium.gitbook.io (cryptography)
TweetNaCl.js: tweetnacl.js.org (lightweight crypto)

Decision Tree: Choosing for mpowerup¶

START
  ↓
Is offline operation required?
├─ YES → Use Briar (offline mesh)
│        └─ Add Syncthing if file backup needed
│        └─ Add Manyverse if social features needed
│
└─ NO → Is metadata privacy critical?
        ├─ YES → Use Cwtch OR Briar (via Tor)
        │
        └─ NO → Is maximum device compatibility needed?
                ├─ YES → Use XMPP + Conversations
                │        └─ Self-host Prosody if desired
                │
                └─ NO → Do users need voice/video?
                        ├─ YES → Use Jami
                        │
                        └─ NO → Use XMPP for chat + Syncthing for files

Summary Recommendations for mpowerup¶

If targeting affordable used phones (512 MB - 1 GB RAM):¶

Primary Stack: 1. XMPP + Conversations (chat, minimal resources) 2. Syncthing (file sync) 3. Briar (offline fallback if needed)

Total footprint: ~100-150 MB RAM Phones supported: 512 MB and up

If targeting offline-first communities:¶

Primary Stack: 1. Briar (offline mesh messaging) 2. Syncthing (P2P file backup) 3. Manyverse (community posts/social)

Total footprint: ~100-150 MB RAM Phones supported: 512 MB and up Internet required: No (works fully offline)

If targeting maximum security/privacy:¶

Primary Stack: 1. Cwtch (metadata-resistant chat) 2. Syncthing (encrypted file sync) 3. Briar (offline capability, if needed)

Total footprint: ~130-180 MB RAM Phones supported: 512 MB and up

What NOT to do:¶

❌ Don't use Helia/IPFS for phone apps (too heavy)
❌ Don't expect centralized servers (defeats P2P goal)
❌ Don't use legacy encryption (outdated security)
❌ Don't assume devices have continuous internet
❌ Don't ignore local encryption setup

Conclusion¶

For affordable used mobile devices running a P2P chat + data storage system:

All recommended technologies are open source
XMPP + Conversations is best for internet-dependent use (10-30 MB RAM)
Briar is best for offline-first use (20-50 MB RAM)
Syncthing should handle all data storage (50 MB RAM)
Combined stack uses <150 MB RAM (phones with 512+ MB work fine)
Helia/IPFS not recommended (100+ MB overhead, not mobile-optimized)

mpowerup recommendation: Start with XMPP + Conversations + Syncthing (the "hybrid" approach), then add Briar if offline mesh becomes a priority.

Document Metadata¶

Created: May 24, 2026
Topic: P2P messaging for low-resource mobile devices
Status: Reference material for mpowerup project
Technologies: Briar, Jami, XMPP, Syncthing, Scuttlebutt, Cwtch, Helia
Next Steps: Prototype with chosen technology stack, test on target phones