DEV Community: Biprayan Choudhuri

Turnaround: an open-source hiking buddy that knows when you should turn back, and tells someone if you don't come home

Biprayan Choudhuri — Mon, 12 Oct 2026 03:12:09 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

Most hiking trouble isn't dramatic. Nobody falls off a cliff. Someone simply keeps going a little too long because the summit is "just around the corner", the sun sets earlier than they thought, and the only person who knows where they went is themselves.

Two things would fix most of that:

Knowing, before you leave, the time you should turn around, based on how fast you actually walk rather than a sign at the trailhead.
Someone you trust finding out automatically if you don't come back, without you having to remember to tell them.

So I built Turnaround. You spend about two minutes with it before a hike, then put your phone in your pocket.

What I Built

Turnaround is a hiking companion that runs entirely on your own laptop. Before a hike it gives you three times:

Turn around by: not at the top or the far end by this time? Head back.
Back by: 9 in 10 hikes like yours finish before this.
Sunset margin: how much daylight you have to spare.

Then it does four things:

Predicts how long you will take, as a range rather than a single guess. An open tabular foundation model (TabPFN) learns from 7,186 real recorded hikes and adjusts to your pace after every hike you finish.
Briefs you out loud. Gemma 4, running locally, turns the numbers into a short spoken briefing that sounds like a friend who hikes. It's saved to your phone before you leave, so it plays with no signal.
Watches. When you tap Start, a durable safety timer begins waiting for your check-in.
Tells someone. If you're well past your back-by time and still haven't checked in, your emergency contact gets an email with your plan, your route and a map link to where you set off. If you then check in late, they get a second email saying you're safe.

No GPX file? You just enter the three numbers every trail page lists (distance, elevation gain and trailhead), and Turnaround plans from those.

Who it's for: anyone who hikes alone or is new to it, and anyone with a parent, partner or friend who worries when they head out.

How it gets you off the screen: the screen part is the beginning and the end of the trip. Plan, listen, pocket the phone, walk. The next time you look at it is to tap Hike complete.

How it works

Demo

The video walks through the whole flow: planning a hike, the spoken briefing, starting the trip and the safety timer, and checking in.

Turnaround runs on my laptop, by design (more on that below), so there's no public link. The repo has one-command-per-terminal setup if you want to run it yourself.

Code

CodeNeuron58 / Turnaround

An open-source hiking companion

MIT-licensed. CI runs typechecks, the app build and two unit-test suites on every push. Everything I claim below has a file in the repo backing it.

How I Built It

Everything runs on one laptop:

Phone or browser → the app (React + Vite), reached over Wi-Fi or Tailscale
App → the prediction service (FastAPI + TabPFN + SQLite)
Prediction service → Gemma 4 (via Ollama) for the briefing, Kokoro for the voice, and the Temporal server to arm the timer and send check-ins
Temporal worker → the alert and all-clear emails to your contact

The only things that leave it are an anonymous weather lookup (coordinates only) and, if you're overdue, the alert email.

1. Predicting your hike time: TabPFN

The classic hiking-time rule is Naismith's rule: roughly 12 minutes per kilometre plus 1 minute per 10 m of climbing. It's on half the trail signs in the world, and it gives the same answer for everyone.

I wanted a range, and I wanted it to fit the person. TabPFN is an open tabular foundation model: you give it a table of examples and it predicts new rows in context, with no training loop. Crucially for a safety tool, it returns a full predictive distribution rather than one number.

The data is 7,186 GPS-recorded hikes from hikr.org (a public Kaggle dataset, CC0). The features are distance, climb, descent, highest point and the SAC difficulty grade (T1–T6). I held out 1,438 hikes the model never saw and compared it with Naismith:

On 1,438 unseen hikes	Naismith's rule	TabPFN v3.5
Average error	44.1 min	34.8 min
RMSE	69.1 min	54.5 min
Real times inside the predicted 90% band	—	89.5%
Hikers back before the "back by" time (P90)	—	90.4%

The last row is the one I care about most. A safety tool has to be honest about its uncertainty, not just accurate on average. When Turnaround says "9 in 10 hikes like this are done by 4:40", that turns out to be true for 90.4% of hikes. Average error being 21% lower is a nice bonus.

On a laptop CPU I serve TabPFN v2 by default. It's about 3x faster with nearly identical calibration (89.7%). The v3.5 checkpoint is one environment variable away.

How the prediction becomes decisions:

Back by = the 90th percentile + your planned breaks.
Turn around by = the share of that time you should spend heading out, assuming you retrace your steps. Climbing happens on the way out, so steep routes front-load it (Naismith's split, clamped between 50% and 70%).
Alert = the 95th percentile + breaks + 30 minutes of grace. I deliberately didn't make it the back-by time: your contact should only be emailed when you're genuinely late, not five minutes slow.

Learning your pace. The crowd isn't you. Every hike you finish compares your actual moving time with the model's median for the same route, and the ratios combine into a personal pace factor. It's shrunk toward 1.0 on purpose, so one bad day can't swing the safety timer. A hike that was 40% slower than predicted moves your next estimate up about 12%, not 40%. Hikes where you tapped I turned back early don't count, because a turned-back time says nothing fair about the whole route. All of these rules are in a small, unit-tested module.

2. A promise that survives a crash: Temporal

The scariest bug a safety app can have is a timer that silently dies. If the alert depends on a Node process staying alive for six hours on a laptop, it's not a safety feature, it's a hope.

So the safety timer is a Temporal workflow. One tripWorkflow per hike races a check-in signal against a durable timer set to the alert moment. Sending the email is an activity with retries. A late check-in after the alert triggers the all-clear. I run Temporal's free local dev server with an on-disk database, so timers survive a restart of the server itself, not just the worker.

Then I tried to break it. Each scenario has its workflow history or logs committed in docs/evidence/:

#	What I did	What happened
1	Checked in on time	Timer closed, nobody emailed
2	Missed the check-in while the mail server failed	Activity retried; alert went out on attempt 2
3	Killed the worker mid-trip, restarted it 25 s later	Alert still fired exactly on the deadline: 90.5 s after start, despite the worker being dead from second 20 to 45
4	Drill: missed check-in, then a late check-in	Alert on the deadline, then an all-clear
5	Killed the Temporal server mid-trip	Timer survived on disk; a check-in sent during the outage reported the failure honestly and landed when re-sent

Scenario 3 is the whole reason Temporal is here. The promise didn't notice the outage.

This is what your contact actually receives. Both emails below were delivered to my own phone through Brevo, using the same templates and code path the worker uses (sent with the preview command, which is why they're marked [PREVIEW]):

The alert says who, which route, when they set off and when they should have been back, with a one-tap map link to the starting point. The all-clear tells your contact they can stand down. Nobody has to decode a log file at 4 a.m.

The app is equally honest when something is wrong. If the timer fails to arm, the trail screen shows a red "safety timer NOT armed" banner with a retry button rather than pretending you're covered. If you check in with no signal, the check-in is saved on the phone and sent the moment it can reach the laptop, and re-sending is idempotent, so a flaky connection can't double anything.

3. A briefing that sounds like a friend: Gemma 4 + Kokoro

Numbers on a screen are easy to ignore. A voice in your ear saying "If you're not at the top by 1:40, turn around. The view will still be there next weekend" is not.

Gemma 4 (E4B) runs locally through Ollama's OpenAI-compatible endpoint. The service hands it the trip's facts (distance, climb, turn-around and back-by times, sunset, rain chance, trailhead) and asks for 4 to 6 short sentences "like a friend who hikes, not a robot", always including the turn-around rule. Kokoro, an open 82M-parameter text-to-speech model, reads it aloud on the same machine. The text and audio are generated once, stored, and saved to your phone while you still have signal.

Gemma is the voice, never the source of truth: every number it speaks comes from the prediction service, and if the sunset time is unknown, the prompt tells it to say so rather than invent one.

The app

React + Vite, three screens: Plan, On trail and Summary. Your phone reaches the laptop over the same Wi-Fi, or over Tailscale on mobile data, so nothing is exposed to the public internet. Weather and sunset come from Open-Meteo, with no API key and coordinates only. Alert emails go through a free Brevo account, and every email is also written to a local outbox as a record.

Why Does Open Innovation Matter?

Think about what a hiking plan reveals: where you'll be, that you'll be alone, and until when. I don't think that belongs on someone else's server, and with open models it doesn't have to.

Your location stays on your machine. Gemma 4, TabPFN and Kokoro all run on my laptop. A closed AI API would see every trailhead I start from and every hour I'm out alone.
It costs nothing to run. No subscription, no per-request bill, no key that expires mid-hike. A hiking club could host it for its members on one old laptop or a Raspberry Pi-class box.
The uncertainty is mine to inspect. With TabPFN's weights and a public dataset, I could measure calibration on 1,438 unseen hikes myself. A closed "estimated time" API gives you a number and asks for trust. For a feature that decides when your family gets an alarming email, I wanted the evidence.
Everything is swappable. The checkpoint is one environment variable (v2 for speed, v3.5 for accuracy), Gemma could be any model behind an OpenAI-compatible endpoint, and Piper is a drop-in fallback for Kokoro. Nothing in the stack can be deprecated out from under it.
The data is a commons. The model learns from thousands of hikers who shared their tracks publicly, and gives each new hiker something back.

Where open was genuinely better for me, not just cheaper: calibration. I needed to know that "back by" means 90%, and I could only know that because I could run the model myself on data I could see.

Honest limits. So far I've tested Turnaround at home, with sample routes and missed-check-in drills; taking it on a real trail is next. It's a prototype, not a replacement for telling someone your plan or carrying a satellite messenger in real backcountry. The laptop has to stay awake and online for the alert to send. The model knows hikr.org's mostly Alpine hikers best, and the pace factor exists precisely because you are not them.

Prize Categories

Best Use of TabPFN: TabPFN predicts each hike's moving time as a calibrated distribution. Its P90 becomes the back-by time, its P95 sets when your contact is alerted, and its median feeds your personal pace factor. On 1,438 unseen hikes it beat Naismith's rule (34.8 vs 44.1 min average error) with 90.4% of hikers back before P90.
Best Use of Temporal: the safety timer is a durable Temporal workflow that races a check-in signal against the alert deadline, retries the alert email, and sends an all-clear on a late check-in. Tested by killing the worker and the Temporal server mid-trip, with evidence in the repo.
Best Use of Gemma: Gemma 4 runs locally via Ollama and turns each trip's numbers into a short spoken briefing (voiced by Kokoro) that's saved to your phone before you lose signal.

Thanks for reading. If you hike alone, I'd love to hear what would make you actually use something like this, and what time you'd want to be told to turn around. 🥾

He asked for "fully secure" note sharing. Here's what I built instead.

Biprayan Choudhuri — Sun, 04 Oct 2026 23:23:42 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

He asked for "fully secure" note sharing. He wouldn't stop asking, honestly. So before writing a single line of code, I had to be honest with him about what that sentence actually means.

Fully secure note sharing is not possible. Not on the web, not anywhere. No website can stop someone from taking a screenshot, pointing a phone camera at the monitor, or retyping what they see. Anyone who promises otherwise is selling something.

But "fully secure" being impossible doesn't mean "secure" is. So I built the most controlled version of the idea I could, and named it SecureNote.

What I Built

SecureNote is end-to-end encrypted note and file sharing, and I built it for my friend. His notes aren't text, by the way: they're PDFs, scanned documents, photos of whiteboards. So files are first-class citizens here, and they're encrypted exactly like everything else.

What it actually gives you:

Notes and files (PDFs, docs, images, up to 10 MB) are encrypted in your browser with AES-256-GCM before upload. The database stores ciphertext: it cannot read your content, your titles, or even your filenames.
You share with a person, not a link. Pick someone by their account, set an expiry and a view limit. The note's key gets wrapped for their public key alone.
Revocation is instant. One click and their key stops working, even if they already read the note. Their open tab locks itself the next time it gets focus.
Every read is on the record. Each view is watermarked with the reader's email and written to an audit log: who, when, from which IP, on what device. Even pressing the PrintScreen key is logged as an attempt.
The AI never leaves your machine. Semantic search and "chat with your notes" powered by Gemma 3 (Google's open-weight model) running in the browser via WebGPU. Open the network tab while using it: nothing goes out.

So what about screenshots? Like I said: I can't stop them. Nobody can. What I can do is make sure a screenshot isn't anonymous. Every page a reader opens is tiled with their identity and a timestamp. If they leak it, they leaked a page with their own name on it, at a logged time, from a logged IP. You can also cap the views or expire the share in an hour.

My friend's response was something like "okay, fair."

Demo

Live app: https://securenote-j8b0.onrender.com

It's hosted on Render's free tier, so the very first load can take about 50 seconds to wake up. Every load after that is instant. Sign up with two accounts: write a note as A, share it to B with a 2-view limit, open it as B, then check A's audit log. Press PrintScreen as B and watch it land there too.

Code

The full source is on GitHub, MIT licensed: https://github.com/CodeNeuron58/SecureNote

The README covers the whole security model, including the threat model and the things no website can honestly promise.

How I Built It

No crypto libraries, just the browser's built-in WebCrypto:

Signup generates an ECDH P-256 keypair in your browser. The private key is encrypted with a key derived from your password (PBKDF2-SHA-256, 310,000 iterations) before it's ever uploaded. The server stores a bcrypt hash, a salt, your public key, and your sealed private key. It never sees your password.
Every note gets a random content key. Title, body, and uploaded files are encrypted client-side; the content key is wrapped to your own public key.
Sharing unwraps that key in your browser and wraps it for the reader's public key (ephemeral ECDH + HKDF). The server relays sealed blobs it cannot open, while still enforcing expiry and view limits.
The AI is the part I'm proudest of. Private notes plus a cloud AI API is a contradiction, so the AI runs in the browser: MiniLM embeddings and Gemma 3 1B (open weight) via transformers.js on WebGPU, with the vector store in IndexedDB. After the one-time model download, searching and chatting make zero network calls.

Stack: Next.js 15, TypeScript, Tailwind, MongoDB Atlas, hosted on Render.

Why Does Open Innovation Matter?

My friend's whole point was "my notes stay mine." Sending that data to a closed cloud AI would betray the entire premise, so an open-weight model running on-device wasn't a nice-to-have. It was the only architecture that made sense.

It also cost exactly nothing to run, it works with pluggable models (swap Gemma for any ONNX model without asking anyone's permission), and he can clone the repo and host the whole thing himself if he ever stops trusting me. The open approach didn't just work better than a closed one here. It was the difference between using software and owning it.

Prize Categories

Best Use of Gemma: Gemma 3 1B (open weight) powers the in-browser "chat with your notes" and semantic search, running locally via WebGPU
Best Use of Render: the whole app is hosted on Render's free tier
Best Use of MongoDB Atlas: Atlas is the data layer, deliberately storing only ciphertext, grants and audit events

It's built for one friend, but if you've ever needed to send something sensitive without losing control of it, it's for you too. Roast it, break it, tell me what you'd add.

I Built Yumii — An Open-Source AI Companion

Biprayan Choudhuri — Sun, 07 Jun 2026 14:45:43 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Yumii is an open-source, locally-run AI companion with a Live2D avatar, real-time voice, and six distinct personalities — and she now actually remembers you.

She listens to your voice. She responds through an animated avatar. Her face reacts to what you say. And as of this sprint, she builds a long-term memory of who you are — across every conversation, every session, every restart.

Beyond the core AI experience, Yumii focuses heavily on accessibility and ease of use. The project features a dedicated website, comprehensive documentation, a one-line installation command, and a streamlined CLI onboarding process that helps users get started quickly.

GitHub: https://github.com/CodeNeuron58/Yumi
License: MIT

Demo

Before vs After — at a glance:

Before	After
Forgot you on every restart	Persistent memory across sessions
One shared conversation, no history	Full session management — create, resume, rename
No user facts	Auto-extracts facts from every conversation turn
No CLI beyond launch	`/memory`, `/sessions`, `/resume`, `/forget` commands
Wiped on exit	Survives restarts
No dedicated website	Full documentation website
Basic audio capture	Active VAD — only speaks when you actually do
Manual setup	One-line installation

The Comeback Story

I saw Project Ava and a few other AI companion demos and thought — I could build that.

I enjoy anime. The idea of an anime-style AI that actually talks and reacts to you genuinely excited me. So I built a scrappy version that barely held together, it worked, I was happy, and I dropped it. I mean i just build it for fun so i didn't care that much .

Months later I saw the same concept being sold as a subscription product. That bothered me. I'd already built this, yeah a scrappy one , but still i built it. And i thought to myself that I could build it properly — and make it free or opensource .

So I restarted. Proper CLI. Web interface. Clean architecture. VAD, STT, LLM, TTS — the full real-time voice loop. And one hard rule: it has to run on a CPU. I don't have a GPU. Most people don't. If it needs one, it's not really for everyone.

That's what you're looking at now. Still alpha, still rough in places, not yet user-tested beyond myself. But it works, it's free, and it runs locally on your machine.

Note on the demo: I'm skipping a video walkthrough — the Live2D model I use locally has redistribution restrictions, so I can't share footage with it publicly. Voice, memory, and everything else works fine as much as i can tell , it works without an avatar if you want to try it yourself.

What's next

Making her actually do things.

Right now Yumii talks. What I want is for her to act — search the web, read your emails, help you shop, browse on your behalf. A real assistant, not just a companion.

It would be done by giving her tool access via mcp.

Contribute

Yumii is fully open source — MIT license. If you're a developer who builds with LangGraph, vector databases, voice pipelines, or just finds this kind of project interesting — contributions are genuinely welcome.

I'd love to hear what other developers think of the architecture, the approach, or what they'd build on top of it. Open an issue, start a discussion, or just drop a comment here. Every perspective helps.

Small Note

Yumii is still in a very early stage and actively being developed, so expect rough edges here and there.

This is my first time properly sharing the project outside LinkedIn, and I’d genuinely love feedback, ideas, or contributions from fellow developers while building it

My Experience with GitHub Copilot

Copilot was running throughout this sprint mostly through tab completion — and that's where it genuinely helped.

The repetitive async patterns across the session and memory modules are where it earned its place. Once it saw the structure of the first method, it completed the rest almost entirely — correct SQL, correct await placement, correct error handling. What would've taken an hour took fifteen minutes.

The SQLite schema was another moment. I typed CREATE TABLE sessions ( and it suggested the full schema, including columns I hadn't thought of yet but ended up needing.

It didn't make any decisions. The architecture, the three-database design, the fire-and-forget fact extraction, the async queue pipeline — all of that was thought through manually. But for translating decisions into correct boilerplate fast, it was genuinely useful.

I also used Claude for cross-checking integration points — particularly verifying the LangChain tool interface when I added web search. Both tools, different jobs.