Mesh Services
Create and share lightweight services directly on the mesh network. Publish polls, weather reports, checklists, trail updates, and more — nearby peers discover and interact automatically. No internet required.
Service Templates
Choose from 10 built-in templates. Each defines the fields, actions, and TTL bounds for a specific use case.
Bulletin Board
Share posts with nearby users. A public message board for your local mesh community.
Signal Beacon
Ephemeral status broadcasts: SOS, All Clear, Hazard, Weather Alert, Meeting Point, Camp, Water Source, Trail Marker.
Quick Poll
Ask a question with multiple options. Peers vote in real-time. One vote per peer, live tallies.
Shared Checklist
Collaborative checklists that peers can check off. Great for group trip planning or supply tracking.
Resource List
Share inventory or resource availability. Let peers know what\'s available at your location.
Weather Station
Publish temperature, humidity, and pressure readings. Long-lived sensor data for nearby hikers.
Sensor Node
Generic sensor readings with two data channels, status indicator, and timestamps.
Task Board
Kanban-style task management shared across the mesh. Track tasks, in-progress counts, completions.
Trail Conditions
Report trail status: Clear, Muddy, Snowy, Flooded, Blocked, or Hazardous. Keep fellow hikers informed.
Lost & Found
Track lost and found items with status updates (Lost, Found, Claimed). Help reunite gear with owners.
Creating a Service
A guided wizard walks you through three steps. No protocol knowledge required.
What
Choose your service template from the catalog. Each template defines the fields, actions, and default TTL for your service.
Who
Select your audience. Services are currently public to all nearby mesh users.
Review & Publish
Confirm your choices, fill in the details (title, description, poll options, items), set your TTL, and publish. Your service is live on the mesh instantly.
Managing Your Services
The My Services screen shows all your published services with real-time status.
Active
Services that are running and being advertised to nearby peers. Shows accurate remaining time, updated in real-time.
Expired
Services that reached their TTL and expired naturally. No longer advertised or accepting interactions. Can be deleted.
Stopped
Services you stopped before their TTL expired. Immediately stops advertising. Peers cached entries age out within 1 hour.
Discovery & Interaction
Nearby peers discover your services automatically through the mesh network.
Automatic Advertising
Your services are periodically broadcast on the mesh via SERVICE_ADVERT frames. An immediate broadcast fires on publish; periodic broadcasts continue throughout the TTL.
Mesh Explorer
Peer services appear in Mesh Explorer, grouped by type. See what services are available nearby and how many peers are offering each type.
Real-time Delivery
Interactions use MRRP request-response with live delivery tracking. See the delivery phase in real-time: preparing, sending, delivered, or failed.
How TTL Works
Every service has a Time-to-Live (TTL) that controls how long it stays active. TTL is absolute and clock-based — it never pauses, resets, or extends.
Template Bounds
Each template defines a default and maximum TTL. You choose within these bounds during creation. A poll defaults to 60 minutes; a weather station to 24 hours.
Absolute Timestamp
When you publish, the app computes expiresAt = now + TTL. This absolute timestamp is stored in the database. App restarts, sleep mode, and device reboots don't affect it.
Real-time Countdown
Remaining time is calculated fresh every time. Late-joining peers see accurate time left, not the original TTL. A peer joining 20 minutes into a 60-minute service sees "40 min remaining".
Real-World Scenarios
What happens in common (and edge-case) situations:
Publish & Discover
You publish a 60-minute trail report. Nearby peers see it immediately via an instant broadcast. The service appears in their Mesh Explorer. They can tap to view details and interact.
Late Joiner
A peer powers on 20 minutes after you published. They receive your next periodic advertisement and see "40 min remaining" — always accurate, never stale.
Early Stop
You stop your service manually before the TTL expires. It immediately stops appearing in your advertisements. Peers' cached entries age out within 1 hour.
Expiry During Interaction
If your service expires while a peer is mid-interaction, their request will get an error response. There is no grace period — the TTL boundary is absolute.
Mesh Partition
If no routing path exists between you and a peer, they won't discover your service. Periodic re-advertisements improve chances if the partition heals.
App Restart
Your service survives app restarts. The expiry timestamp is absolute (stored in SQLite), so a 60-minute service created at 2:00 PM expires at 3:00 PM regardless of app lifecycle.
Multiple Services
You can run multiple services simultaneously. Each has independent TTL. All active services are bundled into a single advertisement frame (max 8 per broadcast).
Congested Mesh
If the airtime budget is exhausted by other traffic, your advertisement may be delayed — but the service exists locally immediately. Ads resume when budget refills.
Behaviour & Limits
- Max 50 services per device. When the limit is reached, the oldest expired services are automatically removed. If no expired services exist, oldest stopped, then oldest active are evicted.
- Poll votes are ephemeral. Vote counts are tracked in-memory only. If the publisher's app restarts, vote tallies reset to zero. Each peer gets one vote per poll — voting again changes their vote.
- Checklist state is ephemeral. Like poll votes, collaborative check-off state lives in memory. It resets if the publisher's app restarts.
- No cloud sync. Services are stored locally in a SQLite database on your device. There is no backup or cross-device sync.
- Airtime budget protected. Service advertisements respect a 1024-byte per 60-second airtime budget. This protects the shared mesh from congestion.
- No distributed clock sync. Each device uses its local clock to determine service expiry. Small clock differences between devices (a few seconds) are expected and acceptable.
- No service editing. Once published, a service's title, description, and config cannot be changed. To modify, stop the current service and create a new one.
- Discovery is best-effort. Services are broadcast, not guaranteed. If no routing path exists to a peer, they won't discover your service. Periodic re-advertisements improve reliability.
- Max 8 descriptors per advertisement. If you have more than 8 active services, only 8 are advertised per broadcast cycle.
- Schema caching. Remote peers cache service schemas for up to 1 hour (64 max entries). Repeated interactions don't require re-fetching the schema over the radio.
Privacy & Security
Technical Details
Mesh Services are built on the MRRP (Mesh Request-Response Protocol) which rides inside SIP (Socialmesh Interaction Protocol) frames over the Meshtastic LoRa transport. The wire format is binary and compact to fit within the 237-byte LoRa MTU.
MRRP Service ID: 0x10
All user-created services share a single MRRP service ID (0x00000010). The handler demultiplexes by instance ID and action code.
4 Actions
listInstances (0x0001), getInstance (0x0002), interact (0x0003), getSchema (0x0004). All are request-response pairs over MRRP.
195-byte Payload
MRRP frames carry up to 195 bytes of payload (237B LoRa MTU minus SIP and MRRP headers). Schemas and responses are encoded in compact binary.