DEV Community: Gowshik S

Rio: An AI Agent That Lives Inside Notion — Voice Task Live Notion Memory

Gowshik S — Mon, 30 Mar 2026 06:38:40 +0000

This is a submission for the Notion MCP Challenge

What I Built

Rio is a voice-controlled multi-agent AI system. You speak a task — Rio's agents plan it, execute it on your desktop, research it on the web, and write the result. Every single step of that process lives in your Notion workspace, written in real time, structured, searchable, and yours.

Notion isn't a plugin here. It's the mind Rio thinks in.

The Problem

AI agents are powerful and invisible. They spin up, do work, disappear. You get a final answer with no trace of how it got there — no audit trail, no structured memory, nothing you can build on top of.

Rio solves that by making Notion the surface where agents think out loud. Every task claimed, every browser step taken, every report written — it all lands in structured Notion databases as it happens, not after the fact.

Demo

What you'll see:

A pending task sitting in the Rio Task Queue database
A voice command to Rio — "Research the top 3 AI agent frameworks and write a comparison"
The Rio Logs database populating live — one row per agent step, in real time
The Creative Agent writing a full formatted Notion page as the final deliverable
The task row flipping to done

How Notion MCP Is Core

There are two distinct ways Notion is used — and both matter.

1. Notion as memory

Every agent writes structured logs as it works. Not at the end — during. The Orchestrator logs when it claims a task. The UI Navigator logs each browser action. The Creative Agent writes the full report as a Notion page.

# Every logger.info() becomes this
await memory.log_step("ui_navigator", "browser_step", action, "done")
# → live Notion row: agent name, event, detail, status, timestamp

2. Notion as a reasoning tool (via MCP)

Agents actively query and write Notion during execution — not just at completion. The Orchestrator polls the Task Queue for new jobs. The Creative Agent searches existing pages before writing.

tools, toolset = await MCPToolset.from_server(
    connection_params=SseServerParams(
        url="https://mcp.notion.com/sse",
        headers={"Authorization": f"Bearer {user_token}"}
    ),
    tool_filter=["notion-search", "notion-create-pages", "query-database"]
)

No .env Tokens. Anyone Can Use This.

Rio uses a full OAuth 2.0 + PKCE flow. A user clicks "Connect Notion," approves access, and their token lives in session memory. No database IDs are hardcoded anywhere. The moment they connect, Rio auto-creates their Rio Logs and Rio Task Queue databases — zero manual Notion setup.

User clicks Connect Notion
  → /oauth/start  — PKCE verifier generated, redirect to Notion login
  → /oauth/callback — code exchanged, token stored in session memory
  → auto_setup() — Rio Logs DB + Task Queue DB created in their workspace
  → WebSocket init — agents get NotionMemory + MCPToolset injected

The only things in .env are your app's own client_id and client_secret from notion.so/my-integrations.

Architecture

RIO — SYSTEM ARCHITECTURE
==========================

                        User
                          |
                    Voice Input
                          |
                          v
              +-------------------------+
              |   Orchestrator Agent    |
              |  polls Notion Task      |
              |  Queue for pending jobs |
              +-------------------------+
                 |         |        |
                 v         v        v
        +------------+ +----------+ +-----------------+
        | Live Agent | | UI Navi- | | Creative Agent  |
        | voice STT  | | gator    | | research, write |
        | + TTS      | | browser  | | full Notion     |
        |            | | desktop  | | pages + reports |
        +------------+ +----------+ +-----------------+
                 |         |        |
                 v         v        v
        +---------------------------------------+
        |            NotionMemory               |
        |  writes every step live to Notion     |
        |  via REST API  (httpx async)          |
        |                                       |
        |   Rio Logs DB       Task Queue DB     |
        |   Agent / Event     Task / Status     |
        |   Detail / Status   Agent / Result    |
        +---------------------------------------+
                          |
                          v
        +---------------------------------------+
        |             MCPToolset                |
        |  lets agents query + search Notion    |
        |  during execution  (SSE transport)    |
        |                                       |
        |   notion-search    query-database     |
        |   notion-create    append-block       |
        +---------------------------------------+
                          |
                          v
              +-------------------------+
              |   User Notion Workspace |
              |   connected via OAuth   |
              |   PKCE — no env tokens  |
              +-------------------------+


OAUTH FLOW
----------

  User clicks "Connect Notion"
          |
          v
  /oauth/start
  generate code_verifier + code_challenge (PKCE S256)
          |
          v
  api.notion.com/v1/oauth/authorize
  user approves Rio access in their own browser
          |
          v
  /oauth/callback
  exchange code + verifier for access_token
  store token in session (in-memory, per user)
          |
          v
  NotionMemory.setup()
  auto-creates Rio Logs DB + Task Queue DB
  in the user workspace if not already present
          |
          v
  MCPToolset.from_server()
  connects to mcp.notion.com/sse
  with user access_token — agents ready

Stack: Python · Google ADK · FastAPI · WebSockets · Notion REST API · Notion MCP (SSE) · httpx async · Google Cloud Run

What I Learned

Building agents is easy. Building agents with observable, persistent memory is what actually makes them useful.

The shift from logger.info() to await memory.log_step() sounds trivial — but it completely changes the character of the system. Rio's work is no longer ephemeral. It accumulates. You can go back, search it, build on it, share it. That's what Notion gives it.

The OAuth decision was also non-negotiable. An agent that only works with hardcoded tokens is a demo. An agent that any person can authorize with their own workspace is a product.

Rio Notion Live Web - Rio-Notion Live Web

Source Code

Gowshik-S / Rio-Notion

I built an autonomous voice agent that sees your screen and acts across your apps — here's how

Gowshik S — Mon, 16 Mar 2026 23:59:05 +0000

Most AI agents make the human do the work.

You craft the prompt carefully. You wait. It misunderstands. You rephrase.
You wait again. That's not autonomy — that's a smarter search bar.

I wanted to build something different. An agent where you speak once,
naturally — interrupt mid-sentence, change your mind — and it keeps up
without missing a beat. Then acts. Across your applications. Without
follow-up prompts.

That's Rio.

What Rio actually does

Here's the simplest demo I can describe:

I say: "Log this as a support ticket — my order hasn't arrived in 5 days"

Rio listens, identifies it as a support request, extracts the issue,
severity, and category from my voice, then writes a row to Google Sheets
in real time — ticket ID, timestamp, status OPEN — and confirms back
via voice: "Your ticket #007 has been logged."

No typing. No clicking. One instruction, end-to-end.

And while that's happening, Rio is watching my screen. It knows what
application is open. It can read text off the display. It sees context
I never explicitly told it.

The architecture that makes it possible

Rio runs as a split system — and this is the decision that made everything else work.

Local machine  ←──── binary WebSocket ────→  Cloud Run
  owns hardware                               owns thinking
  mic, screen,                                Gemini Live session,
  UI actions,                                 ADK orchestration,
  file system                                 model routing,
  browser                                     ToolBridge

Why split?

Because the things that need to be fast (audio capture, screen frames,
UI clicks) need to live close to the hardware. And the things that need
to be powerful (model inference, multi-step planning, API integrations)
need to live in the cloud.

Mixing them kills both. Splitting them makes both excellent.

The binary WebSocket protocol

Everything — audio, video, tool calls — flows over a single WebSocket
connection. I designed a simple binary prefix protocol:

0x01 + PCM16 mono audio at 16kHz → goes to Gemini Live session
0x02 + JPEG screenshot bytes → goes to vision pipeline
JSON frames → tool calls, tool results, control signals

The key insight: audio and video can't share the same queue without
head-of-line blocking. A large JPEG frame will delay audio by hundreds
of milliseconds if they're treated equally.

Solution: priority queue on the send side. Audio at priority 0, frames
at priority 1. Audio always wins.

Native audio — not STT → LLM → TTS

This is the part I'm most proud of architecturally.

Most voice agents are secretly text agents wearing a voice costume:
speech-to-text → LLM → text-to-speech. The latency is acceptable.
The naturalness isn't.

Rio uses gemini-live-2.5-flash-native-audio — Gemini's native audio
model. Voice goes in, voice comes out. No transcription middle layer.
The model hears tone, pace, hesitation. It responds like a conversation,
not a query.

The tradeoff: native audio models are unreliable for function calling.
I had to route all tool execution through a text-based orchestrator via
live_model_tools=False. There's a hidden parsing layer between what
the model says and what the tool dispatcher hears. Getting that clean
took the most iteration of anything in this build.

True interruptions via Silero VAD

Real interruption handling is harder than it sounds.

The naive approach: detect silence, stop playback. This breaks constantly
— background noise, breath sounds, pauses mid-thought all trigger false
interruptions.

The right approach: Silero VAD running in a sounddevice callback thread,
detecting actual voice activity with a trained model. When it triggers,
it hands off to the asyncio event loop via call_soon_threadsafe.

The gotcha: getting that handoff fast enough to feel instantaneous.
VAD detection to playback stop needs to be under ~100ms or it feels
laggy. The threading boundary between sounddevice callbacks and asyncio
is where most of that latency lives.

The ToolBridge pattern

This is the pattern I'm most likely to reuse on future projects.

The problem: Gemini running in Cloud Run needs to execute actions on
my local machine. It can't do that directly. So I built a bridge:

# Cloud side — when Gemini calls a tool:
async def bridge_tool_call(name, args):
    call_id = str(uuid.uuid4())
    future = asyncio.Future()
    pending[call_id] = future

    await ws.send_json({
        "type": "tool_call",
        "id": call_id,
        "name": name,
        "args": args
    })

    result = await asyncio.wait_for(future, timeout=30)
    return result

# Local side — when tool_call arrives:
async def handle_tool_call(msg):
    result = await execute_tool(msg["name"], msg["args"])
    await ws.send_json({
        "type": "tool_result",
        "id": msg["id"],
        "result": result
    })

Every tool is a closured async function, isolated per WebSocket connection.
Adding a new tool is 10 lines. The cloud model never knows it's talking
to a local machine.

Struggle detection — ML inside the agent

One thing I haven't seen in other agent demos: behavioral adaptation.

Rio runs a scikit-learn classification model in real time, trained on
user interaction patterns — retry frequency, error rate, response latency
variance. When the model predicts a user is struggling, Rio shifts its
response style proactively. Simpler language. More scaffolding. Without
being asked.

The hard part was feature engineering. Hesitation alone isn't struggle.
A retry alone isn't struggle. The signal lives in the combination —
and finding that combination required building a small labeled dataset
from my own interaction logs.

The next evolution: wiring this directly into ADK's LiveRequestQueue
as a streaming tool so the adaptation happens inside the agent loop,
not as an external observer.

The graceful degradation model

Free-tier Gemini API limits are real. 30 RPM disappears fast.

I built a token bucket rate limiter with 4 degradation levels:

Level	Condition	Rio's behavior
0	Healthy	Full capability
1	70% bucket	Reduce screenshot frequency
2	40% bucket	Disable proactive vision
3	10% bucket	Voice only, no tools
4	Empty	Graceful hold with user message

The agent never crashes. It degrades. That distinction matters a lot
in a live demo.

What I'd do differently

Start with the protocol design. I retrofitted the binary frame protocol
onto an existing JSON-only WebSocket. It worked, but doing it upfront would
have saved two days of refactoring.

Wire the struggle detector earlier. I built it as a standalone pipeline
first, then realized it needed to be inside the agent loop to be useful.
That's a lesson about where ML belongs in agent systems — not as an
observer, but as an actor.

InMemorySessionService is a trap. Fine for development. The moment
Cloud Run cold-starts mid-conversation, your session handle is gone.
Design for persistence from day one.

What's next

The current build is one powerful agent. The next version is four:

Orchestrator — ADK + Gemini 2.5 Pro, plans and delegates
Live Agent — owns all voice and vision
UI Navigator — Playwright + Computer Use API, true visual grounding
Creative Agent — interleaved output, mixed-media responses

Connected via A2A protocol with Agent Cards. Rio as a node in a
larger agent network, not a standalone tool.

Try it / follow along

GitHub: https://github.com/Gowshik-S/Gemini-Live-Agent

The repo includes a one-command Cloud Run deployment via service.yaml:

gcloud run services replace cloud/service.yaml

If you're building something in the agent space — especially anything
involving Gemini Live API or ADK — I'd love to compare notes.
Drop a comment or find me on LinkedIn.

One human. One instruction. Rio does the rest.

When Disasters Strike, Cell Towers Fall First — So I Built a Mesh Network for Coastal Communities

Gowshik S — Mon, 02 Mar 2026 07:15:56 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

Over 2 billion people live within 100km of a coastline. Fishermen in Indonesia, families in the Philippines, communities in Haiti and India — people who face cyclones, tsunamis, and floods not as rare events, but as a way of life.

Every time disaster strikes, the same thing happens: the cell towers go down first.

I grew up in India, where this hit close to home. During Cyclone Ockhi in 2017, dozens of fishermen died at sea off the Tamil Nadu coast. Not because rescue teams didn't exist — because when the storm hit, towers went down and no one knew where they were. Families waited on shores for days. Rescue teams deployed blind.

That moment stuck with me. We had phones. We had apps. It wasn't a technology failure — it was an infrastructure failure. The system built to connect people in emergencies was the first thing the emergency destroyed.

This is not just India's story. It's every coastal community that has ever lived through a major disaster. Ocean Sentinels is built for all of them.

What I Built

Ocean Sentinels is an Android app that lets coastal communities report hazards, coordinate rescues, and stay connected — even when there's no internet.

The core idea: turn ordinary Android phones into a disaster-proof relay network using Bluetooth. When a user submits a hazard report offline, it hops phone to phone through Bluetooth — up to ~400 metres per hop — until any device in the chain finds internet and uploads it to the server.
No cell towers. No WiFi. No special hardware. Just phones.

  [ Phone A ] ---BLE 400m---> [ Phone B ] ---BLE 400m---> [ Phone C: Has Internet ]
  No signal                   No signal                    Uploads to server ✓

What the app does:

Report coastal hazards (high waves, flooding, lost boats) with GPS + photo
Relay reports offline via BLE mesh — tested at ~400m in open areas
Live map with real-time incident markers
Role-based access for Citizens, Rescue Teams, Authorities, and Admins
Push notifications via Firebase even with the app closed

There's also a web dashboard for authorities who need a larger screen — but the Android app is the real lifeline. The web requires internet. The mesh doesn't.

Demo

The cover video above gives a full walkthrough of the app.

Real-world BLE mesh test — three phones communicating at ~400m in open area,no internet, report relayed successfully:

App walkthrough — reporting, map, and mesh screens:

Download Ocean Sentinels APK (Android)

If the download is slow use this link (Alternate Download Link)
[Ocean Sentinels v1.1]

Better Use the APK version, because our primary goal is build a Application.

Ocean Sentinels Web

iOS is Developed but can't be exported due to some limitations. Refer the github repo for source code.

Test Credentials

Role Email Password

Citizen sihcitizen@vi.com SIH@2025

Rescue sihrescue@vi.com Ocean@123

Admin OceanAdmin1 admin

Works on both the Android app and web dashboard.

Screenshots

Home Dashboard — quick action cards:

Report Incident — GPS, hazard type, photo upload:

BLE Mesh Screen — live peers and relay status:

Live Map — real-time incident markers:

Code

Gowshik-S / Ocean-Sentinels

About Ocean Sentinels is an offline-first disaster management platform designed to save lives in coastal regions. It solves the critical problem of connectivity failure during disasters by implementing a custom "Store-Carry-Forward" Bluetooth Mesh Network.

Ocean Sentinels - A Coastal Safety Network

A full-stack coastal safety and hazard reporting platform built for coastal communities worldwide. The system enables real-time maritime incident reporting, response coordination, and offline BLE mesh networking for areas with limited or no connectivity — keeping communities connected when disasters take down the infrastructure.

Overview

Ocean Sentinels provides a unified platform for coastal hazard reporting across worldwide. It supports four user roles -- Public citizens, Authorities, Rescue Teams, and Administrators -- each with dedicated consoles and workflows.

Core capabilities:

Real-time incident reporting with GPS coordinates and photo evidence
Live interactive map (Mapbox) with incident markers and monitoring zones
Role-based dashboards for incident verification, response deployment, and analytics
BLE mesh networking for offline hazard report relay between Android devices
Weather…

View on GitHub

How I Built It

The Android app is built with Kotlin and Jetpack Compose, with Hilt for dependency injection, Room for local offline storage, and Mapbox for the live map. The BLE mesh networking layer — the offline relay system — is also entirely written in Kotlin, running as a foreground service so it keeps relaying reports even when the app is in the background. Firebase handles push notifications so rescue teams are alerted even with the app closed.

The web dashboard for authorities and rescue teams is powered by a FastAPI + PostgreSQL backend — handling incident reports, role-based access control, and WebSocket live updates for real-time map monitoring.

The hardest part was the BLE mesh layer. A few things I learned:

Hop-count TTL doesn't work in disasters. A relay chain can be 50+ devices long before reaching internet. I switched to 72-hour time-based expiry so messages survive however long the chain needs to be.

Android 6+ hides MAC addresses. You can't use Bluetooth MACs to identify
devices. I generate a SHA-256 fingerprint from the device ID instead —
persistent and privacy-safe.

Reports are stored in Room first. Even if mesh relay takes hours, the report
is never lost. It uploads automatically when connectivity returns.

When the network goes down, the mesh goes up.

Ocean Sentinels - An Offline App for Worldwide Costal Communities

Gowshik S — Mon, 16 Feb 2026 07:59:56 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

Ocean Sentinels — A full-stack coastal safety platform (Web + Android) with an offline BLE Bluetooth mesh network for disaster scenarios.

When natural disasters knock out cell towers, coastal communities are left stranded. Ocean Sentinels solves this by turning ordinary Android phones into a Bluetooth mesh network — hazard reports hop phone-to-phone until any device finds connectivity and uploads to the server, alerting rescue teams and authorities instantly.

Ocean Sentinels is personal to me — coastal communities in India are among the most disaster-prone in the world, and the cruel irony is that when disasters strike hardest, the communication infrastructure goes down first. I built this because I believe no one should be unreachable just because a cell tower fell.

The Platform

Web App — Interactive Mapbox map with real-time incident markers, role-based dashboards for 4 user types (Public, Authority, Rescue Team, Admin), WebSocket live notifications, analytics charts, and responsive design
Android App — 21 Jetpack Compose screens built with Material3, offline-first architecture with Room DB caching, Firebase push notifications, GPS location tracking, and the BLE mesh networking layer
Backend — FastAPI + PostgreSQL with async operations, 16+ REST endpoints, JWT authentication, role-based access control, and mesh message deduplication

The BLE Mesh Network

This is the core innovation. When there's no internet:

A user submits a hazard report on their phone
The report broadcasts over BLE to nearby phones (~400m range using Coded PHY S8)
Each phone relays it forward using store-carry-forward protocol
When ANY phone in the chain gets internet → the report uploads to the server → authorities are alerted

No special hardware needed. Just phones.

Cover Video :

Technical specs:

Coded PHY S8 — 8x forward error correction, extends BLE range to ~400m (vs 100m standard)
72-hour time-based message expiry instead of hop-count TTL — because in a disaster, a message chain might be 50+ devices long before reaching internet
Triple-layer deduplication — relay path tracking + in-memory LRU cache (10K entries) + database-level dedup
SHA-256 deterministic message IDs — same report from same device always generates the same ID
Dual PHY fallback — tries Coded PHY first for range, gracefully degrades to 1M PHY for older devices

Tech Stack

Layer	Stack
Backend	Python 3.11, FastAPI, SQLAlchemy 2.0 (async), PostgreSQL, JWT, WebSocket
Frontend	Vanilla JS, Mapbox GL JS, CSS3, role-based navigation
Android	Kotlin, Jetpack Compose, Material3, Hilt, Room, Retrofit, Mapbox SDK, Firebase
Mesh	BLE 5.0 Coded PHY S8, GATT server/client, SHA-256 dedup, foreground service
Deploy	Render (backend), Vercel (frontend)

Demo

https://vid.gowshik.in

Live Test at Open Area :

Live Test In Screen :

Live Demo :

Live Web App: [Ocean Sentinels - Web]
GitHub Repo: https://github.com/Gowshik-S/Ocean-Sentinels
APK Link: [Ocean Sentinels - APK]
APK Link: (Alternate Link) [Ocean Sentinels - APK]
IOS Link: Developed but can't be exported due to some limitations. Refer the github repo for source code.

Test Credentials

Role	Username/Email	Password
Citizen	sihcitizen@vi.com	SIH@2025
Rescue	sihrescue@vi.com	Ocean@123
Admin	OceanAdmin1	admin

Works on both the Web App and Android APK.

Screenshots

Web Analytics (Public) :

Authority Analytics :

Android - Home Screen (dashboard with action cards):

Android - Report Incident (form with GPS, hazard type)

Android - Mesh Network Screen (BLE peers, relay status)

Android - Map View (Mapbox with markers)

Architecture Diagram (phone-to-phone mesh relay)

My Experience with GitHub Copilot CLI

GitHub Copilot CLI was instrumental across every layer of Ocean Sentinels. Here's how it shaped my development:

GitHub Copilot CLI terminal examples :

Using `gh copilot` in the Terminal

The challenge is built around GitHub Copilot CLI — and here's where it directly shaped my workflow:

Designing the BLE deduplication strategy:

$ gh copilot suggest "how do I deduplicate BLE mesh messages across 50+ relay hops in Android without using hop count TTL"

Copilot suggested time-based TTL (72hr) + SHA-256 deterministic IDs + LRU in-memory cache — the exact triple-layer system I implemented.

Debugging Coded PHY negotiation failure:

$ gh copilot explain "BluetoothAdapter.listenUsingInsecureL2capChannel returning null on Android 11 with Coded PHY"

It explained the Android 11 BLE stack quirk and suggested the dual-PHY fallback pattern I now use.

Generating FastAPI async SQLAlchemy boilerplate:

$ gh copilot suggest "FastAPI async SQLAlchemy 2.0 endpoint with JWT role-based access control for incident reporting"

Scaffolded the entire endpoint pattern — I reused this template across all 16+ backend routes.

BLE Mesh Layer — The Hardest Part

Building a Bluetooth mesh network from scratch is complex. Copilot CLI helped me:

Design the BleMeshManager that runs a GATT server and BLE scanner simultaneously
Implement the triple-layer deduplication strategy (relay path + LRU cache + DB check)
Build the DeviceIdentifier system — Android 6+ masks real MAC addresses, so Copilot suggested a SHA-256(deviceId + androidId) fingerprint approach
Debug BLE Coded PHY negotiation and fallback logic when devices don't support PHY S8
Architect the time-based TTL system — Copilot understood why hop-count TTL fails in disaster scenarios and suggested 72-hour expiry instead

Full-Stack Development at Speed

Backend: Generated all FastAPI endpoints, SQLAlchemy async models, Pydantic schemas, and JWT middleware with role-based guards — gh copilot suggest understood the access control patterns I needed
Frontend: Role-based navigation manager, Mapbox GL custom markers, WebSocket reconnection handlers — Copilot scaffolded the boilerplate so I focused on user experience
Android: 21 Compose screens with Hilt dependency injection, Room database entities, Retrofit API client — it understood my clean architecture layers and generated consistent code across data/domain/presentation

Cross-Layer Intelligence

The most impressive moment: while working on mesh message dedup in the Android BleMeshManager, Copilot correctly suggested that the backend's Incident model also needed a mesh_message_id unique constraint. It understood the end-to-end flow — BLE relay → API upload → database dedup — without me explicitly describing it.

Impact on Development

What would have taken weeks of researching BLE specs, GATT protocol documentation, and Android Bluetooth stack quirks was compressed into days. Copilot CLI didn't just autocomplete — it understood context across files, layers, and even the research paper concepts I was implementing.

It generated the NetworkModule, DatabaseModule, and AppModule with proper @Provides and @Singleton annotations — all correctly wired.

BLE Mesh Network — Where Copilot Truly Shined

The mesh layer was the most complex part. I had the IEEE BitChat paper as reference, but translating academic protocols into Android BLE code is a different beast.

┌─────────────────────────────────────────────────────────────────────────┐
│                           DEVICE ROLES                                   │
└─────────────────────────────────────────────────────────────────────────┘

┌──────────────┐         ┌──────────────┐         ┌──────────────┐
│   GATEWAY    │         │    RELAY     │         │   NORMAL     │
│    DEVICE    │         │    NODE      │         │    NODE      │
├──────────────┤         ├──────────────┤         ├──────────────┤
│  Internet    │         │ No Internet  │         │ No Internet  |
│              │         │              │         │              │
│  Relay       │◄───────►│ Forward      │◄───────►│ Send         │
│  Upload      │         │ Receive      │         │ Receive      │
│  Download    │         │ Re-broadcast │         | Broadcast    │
└──────────────┘         └──────────────┘         └──────────────┘

  * Any device can become Gateway if it gets internet

BLE Mesh Relay Network (Offline Mode)

  +------------------+                +------------------+
  |  Offline Device  | ----BLE------> |   Relay Peer     | ----BLE----->  ...
  |                  |                |                  |
  |  Creates Report  |                |  Receives Msg    |
  |  Stores in Room  |                |  SHA-256 Dedup   |
  |  Broadcasts via  |                |  Checks 72h      |
  |  BLE GATT Server |                |  Expiry Window   |
  +------------------+                +--------+---------+
                                               |
                                   +-----------+-----------+
                                   |                       |
                              No Internet             Has Internet
                                   |                       |
                                   v                       v
                          +----------------+    +--------------------+
                          | Continue Relay |    | Upload to Backend  |
                          | to Next Peers  |    | (Server Dedup via  |
                          | (Append to     |    |  mesh_message_id)  |
                          |  Relay Path)   |    |                    |
                          +----------------+    +--------------------+

  Mesh Specifications:
  +------------------------+--------------------------+
  | Parameter              | Value                    |
  +------------------------+--------------------------+
  | Max Connections        | 7 simultaneous peers     |
  | Fragment Size          | 469 bytes                |
  | Max Packet Size        | 512 bytes                |
  | Dedup Cache            | 10,000 message IDs (LRU) |
  | Message Expiry         | 72 hours (time-based)    |
  | Peer Stale Timeout     | 180 seconds              |
  | Scan Restart Interval  | 30 seconds               |
  | PHY Strategy           | Coded PHY (long range),  |
  |                        | 1M PHY fallback          |
  +------------------------+--------------------------+

📡 BLE Mesh Protocol Stack

┌─────────────────────────────────────────────────────────────────┐
│                     MESH APPLICATION LAYER                      │
├─────────────────────────────────────────────────────────────────┤
│  ┌────────────┐  ┌────────────┐  ┌────────────┐  ┌────────────┐ │
│  │  Incident  │  │   Status   │  │   Sync     │  │   Ack      │ │
│  │  Report    │  │  Update    │  │  Request   │  │  Message   │ │
│  └─────┬──────┘  └─────┬──────┘  └─────┬──────┘  └─────┬──────┘ │
└────────┼───────────────┼───────────────┼───────────────┼────────┘
         │               │               │               │
         ▼               ▼               ▼               ▼
┌─────────────────────────────────────────────────────────────────┐
│                     MESH TRANSPORT LAYER                        │
├─────────────────────────────────────────────────────────────────┤
│  Serialization: Protocol Buffers → Byte Array                   │
│  Fragmentation: 469 bytes per fragment (512-byte BLE limit)     │
│  Reassembly: Sequence numbers + CRC verification                │
│  Encryption: ChaCha20-Poly1305 (via libsodium)                  │
└─────────────────────────────────────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────────────────────────────────────┐
│                     MESH NETWORK LAYER                          │
├─────────────────────────────────────────────────────────────────┤
│  TTL Management: Time Based upto 72Hrs                          |         
│  Deduplication: SHA-256 message IDs, 10K cache                  │
│  Flood Control: Randomized delays to prevent collisions         │
│  Peer Discovery: mDNS/Zeroconf for local service discovery      │
└─────────────────────────────────────────────────────────────────┘
         │
         ▼
┌─────────────────────────────────────────────────────────────────┐
│                     BLE PHYSICAL LAYER                          │
├─────────────────────────────────────────────────────────────────┤
│  ┌──────────────────┐    ┌──────────────────┐                   │
│  │   CODED PHY S=8  │    │    STANDARD PHY  │                   │
│  │    (Primary)     │    │    (Fallback)    │                   │
│  ├──────────────────┤    ├──────────────────┤                   │
│  │ • Long range     │    │ • Standard range │                   │
│  │ • ~400m outdoors │    │ • ~100m outdoors │                   │
│  │ • 125 kbps speed │    │ • 1 Mbps speed   │                   | 
│  │ • High FEC       │    │ • Lower latency  │                   │
│  └──────────────────┘    └──────────────────┘                   │
│                                                                 │
│  Timeslot: Each node scans 30ms, then advertises 100ms          │
└─────────────────────────────────────────────────────────────────┘

GATT Server + Scanner Setup:
I used Copilot in VS Code to help write BleMeshManager.kt — it understood that I needed a BLE GATT server advertising a custom service UUID while simultaneously scanning for other devices. When I typed the GATT server callback scaffold, Copilot auto-completed the entire onConnectionStateChange, onCharacteristicReadRequest, and onCharacteristicWriteRequest handlers with proper response codes.

Device Identification Problem:

> Android 6+ randomizes MAC addresses, so I couldn't use them to identify devices.
> Need a persistent unique device identifier since Android 6+ masks real MAC addresses

Built for coastal communities worldwide. When the network goes down, the mesh goes up.

Built within 2 weeks. Impossible without Github CLI !

DEV Community: Gowshik S

Rio: An AI Agent That Lives Inside Notion — Voice Task Live Notion Memory

What I Built

The Problem

Demo

How Notion MCP Is Core

No .env Tokens. Anyone Can Use This.

Architecture

What I Learned

Source Code

Gowshik-S / Rio-Notion

I built an autonomous voice agent that sees your screen and acts across your apps — here's how

What Rio actually does

The architecture that makes it possible

The binary WebSocket protocol

Native audio — not STT → LLM → TTS

True interruptions via Silero VAD

The ToolBridge pattern

Struggle detection — ML inside the agent

The graceful degradation model

What I'd do differently

What's next

Try it / follow along

When Disasters Strike, Cell Towers Fall First — So I Built a Mesh Network for Coastal Communities

The Community

What I Built

Demo

Download Ocean Sentinels APK (Android)

Ocean Sentinels Web

Screenshots

Code

Gowshik-S / Ocean-Sentinels

About Ocean Sentinels is an offline-first disaster management platform designed to save lives in coastal regions. It solves the critical problem of connectivity failure during disasters by implementing a custom "Store-Carry-Forward" Bluetooth Mesh Network.

Ocean Sentinels - A Coastal Safety Network

Table of Contents

Overview

How I Built It

Ocean Sentinels - An Offline App for Worldwide Costal Communities

What I Built

The Platform

The BLE Mesh Network

Tech Stack

Demo

Test Credentials

Screenshots

My Experience with GitHub Copilot CLI

Using gh copilot in the Terminal

BLE Mesh Layer — The Hardest Part

Full-Stack Development at Speed

Cross-Layer Intelligence

Impact on Development

BLE Mesh Network — Where Copilot Truly Shined

BLE Mesh Relay Network (Offline Mode)

📡 BLE Mesh Protocol Stack

Using `gh copilot` in the Terminal