meshtastic-deadlight LoRa Internet Gateway, an origin story

How a proxy project evolved into something I didn't expect

The Problem

There are places where people have devices and apps but no Internet access:

1. Rural areas - Too far from infrastructure
2. Disaster zones - Towers down for weeks
3. Network shutdowns - Deliberate censorship

Existing solutions all have tradeoffs:

Satellite Internet (Starlink, etc.)

• Works well, but $100+/month plus $500+ hardware
• Detectable and can be remotely disabled or geofenced

Mesh messaging apps (Firechat, Briar)

• Work without infrastructure
• Require everyone to install the same app
• Can't use existing services (Gmail, maps, websites)

LoRa projects

• Long range (10km+ per hop), ultra low power
• Mostly sensor data or basic text messaging
• No practical Internet bridging

The gap: People want to use their existing apps in places with no connectivity, ideally on hardware that's affordable and can run on solar power.

I built something to explore this problem.

What Deadlight Does

Deadlight is a multi-protocol proxy written in C that I've been developing for a while. It handles HTTP/HTTPS, SOCKS, SMTP, IMAP, and other protocols through a unified architecture. Recently, I added Meshtastic support as a plugin.

How It Works

Your device connects to Deadlight as a standard proxy. Deadlight:

1. Terminates the connection and parses the protocol
2. Fragments the data into ~220-byte chunks
3. Transmits over LoRa using Meshtastic's protobuf format
4. A gateway node (with real Internet) reassembles the stream
5. Forwards your request to the actual destination

Responses follow the reverse path.

Result: Standard applications work over LoRa mesh without modification. You can send email, browse text-heavy sites, or make API calls—just at ~5 kbps with higher latency.

Why This Approach

Protocol-Aware Bridging

Most attempts at LoRa Internet bridging fall into two categories:

IP-over-LoRa: Tunnel raw packets

• Inefficient (IP headers consume 18% of your 220-byte limit)
• No optimization opportunities
• NAT/firewall issues

Application-Specific: Build custom email-over-LoRa, web-over-LoRa, etc.

• Requires custom clients
• Rebuild for each protocol
• Low adoption (nobody wants another app)

Deadlight's approach: Terminate and understand protocols, then repackage at the message level.

This enables:

• Intelligent prioritization
• Protocol-aware compression
• Caching opportunities
• Zero client modifications

Why Now

The timing worked out because:

• Deadlight already had the proxy infrastructure (protocol handlers, connection pooling, fragmentation logic)
• Meshtastic provides mature, standardized LoRa protocols
• Hardware costs dropped ($30-40 for ESP32+LoRa)
• Real-world need is increasing (more disasters, more shutdowns)

Real-World Scenarios

Where this makes sense:

Disaster Response

Deploy solar-powered nodes after infrastructure failure. Responders and affected people can check weather, coordinate via email, access online resources—using their existing devices and apps.

Rural Connectivity Sharing

One satellite uplink serves dozens of users across 20+ kilometers via LoRa mesh. Communities share infrastructure costs.

Censorship Circumvention

When networks are shut down, traffic tunnels through LoRa mesh to border nodes with access. Difficult to block without widespread jamming.

Remote Operations

Field teams maintain connectivity for critical operations (research stations, remote worksites) without traditional infrastructure.

The core insight: Application compatibility often matters more than bandwidth. People will tolerate slow Gmail rather than abandoning the entire Internet application ecosystem.

Technical Architecture

┌─────────────────────┐
│   Standard App      │ ← Normal application behavior
├─────────────────────┤
│   TCP Connection    │
├─────────────────────┤
│   Deadlight Proxy   │ ← Protocol termination
│   (Client Side)     │   Fragmentation
├─────────────────────┤
│   Meshtastic/LoRa   │ ← 220-byte chunks
│   868/915 MHz       │   Mesh routing
└─────────────────────┘
         │
         │  [Multi-hop mesh network]
         │
         ↓
┌─────────────────────┐
│   Meshtastic/LoRa   │ ← Chunk reassembly
│   (Gateway)         │
├─────────────────────┤
│   Deadlight Proxy   │ ← Stream reconstruction
│   (Gateway Side)    │   Internet forwarding
├─────────────────────┤
│   Internet          │
└─────────────────────┘

Key Implementation Details

Protocol Termination

• Parse application protocols to understand semantics
• Optimize based on protocol behavior (suppress unnecessary keepalives, etc.)

Smart Fragmentation

• Preserve message boundaries where possible
• Priority queuing for different traffic types
• Adaptive retransmission

Delay Tolerance

• Hold client connections open during high-latency mesh transit
• Applications don't see the underlying delay
• Typical roundtrip: 30s - 2min depending on hop count

Security

• TLS termination on client side
• Meshtastic AES-256 encryption over mesh
• Re-encryption to destination servers
• Three layers of encryption end-to-end

Current Status

What's Working (v1.0.0):

• Bidirectional bridge implemented as Deadlight plugin
• Official Meshtastic protobuf support
• Automatic fragmentation and reassembly
• Works over USB serial, Bluetooth Serial, TCP
• Zero-config device detection

Tested Protocols:

• HTTP/HTTPS (curl, browsers for text-heavy sites)
• Email (SMTP/IMAP)
• SOCKS5 proxying
• Basic web APIs

Known Limitations:

• ~5 kbps maximum throughput
• High latency (30s - 2min)
• Not suitable for video, real-time apps, or latency-sensitive protocols
• LoRa regulations vary by region
• Needs comprehensive security audit before sensitive deployments

Why This Might Be Novel

I haven't seen this exact approach shipped elsewhere, though I could be missing prior art.

Similar Projects:

• IP-over-LoRa implementations: Different architecture (packet vs. message level)
• Meshtastic: Peer-to-peer messaging, no Internet bridging
• Reticulum: LoRa networking but requires custom routing stack

What's Different:

• Protocol-aware bridging rather than blind tunneling
• Transparent to existing applications
• Leverages standard proxy patterns

If similar work exists, I'd be interested to learn about it.

Realistic Expectations

This approach has a specific sweet spot:

Good For:

• Email and asynchronous messaging
• Weather, maps, and information lookup
• API access for IoT/sensor applications
• Text-based web browsing
• Emergency communications

Not Good For:

• Video streaming or calls
• Real-time gaming
• Large file transfers
• Low-latency applications
• High-bandwidth general browsing

The use case is delay-tolerant applications where ~5 kbps is sufficient and the alternative is no connectivity.

Open Questions

Areas where I'd value input:

1. Deployment experience: Real-world performance in challenging RF environments
2. Regulatory compliance: LoRa usage rules vary significantly
3. Economic viability: Cost/benefit vs. alternatives in different scenarios
4. Security posture: Comprehensive audit needed for sensitive use cases
5. Scalability: Gateway capacity under realistic loads

Next Steps

Immediate:

• Real-world testing (seeking deployment partners)
• Performance benchmarking across configurations
• Comprehensive documentation
• Security review

Future Possibilities:

• Store-and-forward for offline nodes
• Multi-gateway failover
• Edge caching layer
• Enhanced compression algorithms

Get Involved

Deadlight is open source and this is an active experiment:

Code: github.com/gnarzilla/proxy.deadlight
Blog: deadlight.boo
Support Development: ko-fi.com/gnarzilla

Particularly interested in:

• Feedback on architecture and approach
• Pointers to related work
• Real-world testing opportunities
• Mesh deployment experience

If you see potential applications or fundamental issues, I'd like to hear about them.

Layer-by-Layer Translation

┌─────────────────────┐
│   Gmail App         │ ← User just sees "slow internet"
├─────────────────────┤
│   SMTP (TCP port    │
│   587)              │
├─────────────────────┤
│   Deadlight Proxy   │ ← Terminates SMTP connection
│   (Client Side)     │   Parses: "MAIL FROM: alice@..."
├─────────────────────┤
│   Meshtastic        │ ← Breaks into 220-byte chunks
│   Fragmentation     │   Chunk 1: [Header + "MAIL FROM..."]
│                     │   Chunk 2: [Continuation...]
├─────────────────────┤
│   LoRa Radio        │ ← 868 MHz, ~5 kbps, 10 km range
│   (Physical)        │
└─────────────────────┘
         │
         │  [Mesh hops: Node B → Node C → Gateway]
         │
         ↓
┌─────────────────────┐
│   LoRa Radio        │
│   (Gateway Side)    │
├─────────────────────┤
│   Meshtastic        │ ← Reassembles chunks
│   Reassembly        │   Back into "MAIL FROM: alice@..."
├─────────────────────┤
│   Deadlight Proxy   │ ← Opens real TCP to smtp.gmail.com
│   (Gateway Side)    │   Forwards reconstructed SMTP
├─────────────────────┤
│   Internet          │
│   (smtp.gmail.com)  │
└─────────────────────┘

November 2025 - This is active development. Sharing the approach and looking for feedback from people working on similar problems.