Abstract

Modern digital infrastructure assumes continuous internet connectivity and centralized cloud services. While efficient under normal conditions, this assumption creates a critical failure mode during network congestion, disasters, large public gatherings, infrastructure outages, and emergency situations. In these scenarios, nearby devices often become incapable of coordinating despite being physically close to one another.

This paper proposes Firefly, a local-first event mesh architecture that enables devices to cooperate directly without requiring internet connectivity, cloud infrastructure, user accounts, or centralized control. Instead of modeling communication as messages exchanged between users, Firefly models coordination as the propagation of short-lived events through opportunistic wireless connections.

The system treats nearby devices as temporary infrastructure. As device density increases, network resilience improves rather than degrades. Firefly is intended as a protocol and SDK for integration into mobile devices, vehicles, embedded systems, and smart infrastructure, enabling local coordination during both normal operation and network failure scenarios.

1. Introduction

Current communication systems depend heavily on centralized infrastructure.

A typical interaction between two nearby devices often requires:

Internet connectivity
Cloud services
Authentication systems
Remote routing infrastructure
Third-party service providers

This dependency creates an architectural paradox:

Devices separated by thousands of kilometers can communicate instantly, while devices separated by a few meters may become unable to coordinate if internet access is unavailable.

The consequences become visible during:

Natural disasters
Network outages
Large festivals and public gatherings
Traffic congestion
Stadium events
Emergency response situations
Rural and remote deployments

In these environments, coordination requirements increase precisely when centralized infrastructure becomes unreliable.

Firefly explores an alternative assumption:

Nearby devices should be capable of coordinating locally without requiring permission from distant infrastructure.

2. Design Philosophy

Firefly is built upon five core principles.

2.1 Local First

Communication should occur locally whenever possible.

Instead of routing through remote servers, information propagates directly between nearby devices.

2.2 Event-Oriented Communication

Traditional systems prioritize conversations and messages.

Firefly prioritizes events.

Examples include:

Accident detected
Road obstruction
Emergency alert
Assistance requested
Resource available
Device presence notification

Events describe situations rather than conversations.

2.3 Ephemerality

Information should naturally expire.

Every event contains a finite lifetime.

Expired events disappear automatically without requiring centralized cleanup.

2.4 Infrastructure Independence

The system must continue functioning without:

Internet access
Cellular connectivity
Cloud platforms
User accounts
Global identity systems

2.5 Privacy by Architecture

Privacy should emerge from system design rather than policy.

The protocol avoids:

Permanent identifiers
Global user databases
Long-term location histories
Centralized tracking systems

3. System Architecture

Firefly consists of a distributed collection of nodes.

A node may be:

Smartphone
Vehicle computer
Embedded IoT device
Roadside unit
Sensor node
Personal computer

Each node performs four basic functions:

Discover nearby peers
Receive events
Relay unseen events
Remove expired events

No node possesses special authority.

The network emerges through cooperation.

4. Event Model

Events represent the fundamental unit of coordination.

A generic event structure contains:

Event {
    EventID
    EventType
    CreatedAt
    TimeToLive
    HopLimit
    Payload
    OriginNonce
}

EventID

Globally unique identifier used to prevent duplicate propagation.

EventType

Defines event semantics.

Examples:

ALERT
ACCIDENT
ASSISTANCE
RESOURCE
PRESENCE

TimeToLive

Maximum lifetime of an event.

After expiration, propagation ceases.

HopLimit

Maximum number of relay operations.

Prevents uncontrolled spread.

Payload

Minimal contextual information.

Payloads should remain intentionally small.

OriginNonce

Random value used to distinguish event origins without revealing persistent identities.

5. Event Propagation

Firefly adopts a store-carry-forward model.

When a node receives an event:

Validate event integrity
Check expiration status
Check duplication cache
Store locally
Relay to neighboring peers

This mechanism allows information to move through dynamic and intermittent topologies.

A device may carry information physically and relay it later when new peers become available.

This behavior resembles delay-tolerant networking (DTN) principles.

6. Example Scenarios

6.1 Vehicle Accident Notification

A vehicle detects a collision event.

The vehicle emits:

ACCIDENT_ALERT
TTL = 300 seconds
HopLimit = 10

Nearby vehicles receive and relay the event.

Drivers approaching the area receive warnings without requiring cloud services.

6.2 Emergency Crowd Alert

An authorized emergency node emits:

EMERGENCY_ALERT
TTL = 600 seconds

Devices inside a stadium or festival propagate the alert locally.

Communication remains functional even if cellular networks become congested.

6.3 Local Resource Discovery

Taxi operators broadcast:

RESOURCE_AVAILABLE

Nearby users discover available transportation without relying on centralized ride-hailing platforms.

6.4 Home and IoT Automation

A vehicle entering a driveway emits:

ARRIVAL_EVENT

A nearby embedded node receives the event and triggers local automation such as gate access.

No cloud platform is required.

7. Security Considerations

Security remains a critical research area.

Potential threats include:

Event Flooding

Malicious nodes may generate excessive events.

Mitigations include:

Rate limiting
Reputation systems
Event quotas

Replay Attacks

Previously observed events may be rebroadcast.

Mitigations include:

Event expiration
Duplicate suppression
Nonce validation

False Event Injection

Attackers may create fraudulent alerts.

Potential mitigations include:

Multi-source validation
Confidence scoring
Local trust models

8. Challenges

Several technical challenges remain open.

Congestion

Dense networks may generate excessive traffic.

Research directions:

Gossip routing
Adaptive relay probability
Density-aware forwarding

Energy Consumption

Continuous participation may impact battery life.

Research directions:

Duty cycling
Opportunistic synchronization
Relay role election

Trust

Determining event authenticity without centralized authorities remains a difficult problem.

9. Potential Applications

Firefly may enable:

Disaster response systems
Emergency communication
Smart transportation
Community mesh networks
Industrial coordination
Vehicle-to-vehicle communication
Smart-city infrastructure
Rural connectivity solutions

The architecture is intended to complement existing internet infrastructure rather than replace it.

10. Future Work

Future versions may investigate:

Wi-Fi Direct integration
Bluetooth Low Energy transport
End-to-end encryption
Trust frameworks
Event prioritization
Adaptive routing algorithms
Vehicle-to-everything (V2X) integration
Large-scale simulation studies

Conclusion

Firefly proposes a shift in how digital coordination is modeled. Instead of assuming persistent connectivity to centralized infrastructure, the system treats nearby devices as temporary participants in a cooperative event mesh.

The objective is not to replace the internet but to remove dependency on it during situations where local coordination matters most.

If successful, Firefly could enable resilient, privacy-preserving, infrastructure-independent communication between devices, transforming nearby hardware from isolated endpoints into a cooperative local network.

The central hypothesis is simple:

When infrastructure fails, nearby devices should cooperate rather than wait.