DEV Community: Bhuvan_M_Acharya

OFFLINE: An AI Walking Companion That Gets Out of the Way

Bhuvan_M_Acharya — Wed, 07 Oct 2026 19:22:29 +0000

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

What I Built

OFFLINE is an offline-first AI walking companion designed around a simple idea:

The best AI outdoor experience is one where you stop using the app.

Most AI applications are designed to maximize interaction: more messages, more notifications, more screen time, and more engagement.

OFFLINE takes the opposite approach.

The goal is to help people spend more time outside while requiring less attention from their phone.

You enter how much time you have and choose a walking mode:

Quiet — minimal intervention and a calmer walk
Curious — encourages noticing the physical environment
Explore New Area — encourages discovering unfamiliar surroundings

OFFLINE then prepares a short walking experience containing:

A route
Points of interest / landmarks
Physical-world missions
Walking objectives
An attention budget
Minimal guidance instructions

Once the walk starts, the phone becomes secondary.

Instead of opening a chat interface or constantly looking at a map, OFFLINE provides occasional spoken cues and haptic feedback for meaningful moments such as:

Turns
Route recovery
Landmarks
Mission pacing
Walking progress

The intention is for the user to look at the world rather than the screen.

After the Walk

When the walk finishes, OFFLINE creates a story-like session debrief containing metrics such as:

Outdoor time
Uninterrupted walking time
Route completion
Missions noticed
Digital Intrusion Score
Physical Engagement Score
AI Disappearance Rate

These are project-defined experimental metrics, not clinically validated measurements.

The project is intended for anyone who wants help exploring the outdoors without turning their walk into another screen-based activity.

Demo

GitHub Repository

The complete project is available here:

https://github.com/j4b3-21/OFFLINE

The native application runs as an Expo development build.

The iOS simulator build has been verified, and the repository contains instructions for running the native application.

npm install
npx expo start
npm run ios

Live GPS navigation requires the native development build because it depends on device location capabilities.

Code

The complete open-source code is available on GitHub:

https://github.com/j4b3-21/OFFLINE

The repository is licensed under the MIT License.

The project is structured so that the AI/model layer is separated from deterministic navigation, route geometry, movement tracking, and safety logic.

This means the application can continue functioning even when an AI model is unavailable.

How I Built It

OFFLINE is built as a native React Native application using Expo.

Core Stack

React Native
Expo SDK 57
Expo Router
TypeScript
SQLite
Expo Location
Expo Speech
Expo Haptics
llama.rn
TinyLlama 1.1B Chat GGUF
Vitest

Local-First Architecture

The project is designed around local execution and local data storage.

                    User
                      │
                      ▼
             Duration + Walk Mode
                      │
                      ▼
             Local Experience Planner
                      │
                      ▼
                Schema Validation
                      │
                      ▼
           Safety / Constraint Checks
                      │
                      ▼
        ┌──────────────────────────────┐
        │       Walking Experience     │
        │                              │
        │  • Route                     │
        │  • Landmarks                 │
        │  • Missions                  │
        │  • Attention Budget          │
        │  • Guidance                  │
        └──────────────────────────────┘
                      │
                      ▼
             Walking Session
                      │
          ┌───────────┴───────────┐
          ▼                       ▼
     GPS Tracking             Haptics
          │                       │
          └───────────┬───────────┘
                      ▼
                Voice Guidance
                      │
                      ▼
              Local Session Data
                      │
                      ▼
                Walk Debrief

AI Abstraction

The AI layer is abstracted behind a LocalModel interface.

The interface provides operations such as:

load()
generate()
stream()
unload()
metadata()

This allows the application to separate the model implementation from the rest of the walking experience.

The current MVP uses a deterministic offline MockModel as its default planner.

The planner uses real inputs such as:

Walking duration
Walking mode
Random seed
Starting location

to generate the walking experience.

This keeps the MVP usable without requiring a server, API key, or model download.

Optional On-Device AI

The project also supports optional local TinyLlama 1.1B Chat GGUF inference through llama.rn.

The model can run directly on the device and is downloaded into the application's private storage.

The model layer remains isolated from:

Navigation
GPS tracking
Route geometry
Movement detection
Safety decisions
Session storage

This makes it possible to experiment with different local models without rebuilding the entire application architecture around a single model.

Deterministic Systems vs AI

One of the most important architectural decisions in OFFLINE is that the AI is not the authority for safety-critical behavior.

The system separates generative responsibilities from deterministic responsibilities.

AI / Generative Responsibilities

The model can help with:

Walking experience generation
Mission generation
Descriptions
Interpretive content
Session storytelling
Personalized suggestions

Deterministic Responsibilities

The application itself handles:

Route geometry
Distance calculations
Position tracking
Movement detection
Route progress
Constraint validation
Safety checks
Session persistence

Conceptually:

              AI
               │
               ▼
      Experience Suggestions
               │
               ▼
       Schema Validation
               │
               ▼
      Deterministic Systems
               │
        ┌──────┴──────┐
        ▼             ▼
      Route         Safety
     Tracking       Logic

The model is never treated as the authority for emergency or safety-critical decisions.

Why Does Open Innovation Matter?

A closed AI API would make it easy to build a conversational walking assistant.

But that would work against the core purpose of OFFLINE.

A conventional AI assistant could require:

Continuous internet access
Sending location-related context to a remote service
API credentials
Continuous interaction
A large conversational interface
A dependency on a third-party AI provider

OFFLINE explores a different approach.

Open Models Make Local AI Possible

With open-weight models and local inference, AI functionality can move closer to the device.

That makes it possible to experiment with:

Offline walking plans
Local inference
Private location context
Local session data
Replaceable AI models
No mandatory cloud AI dependency

The application can continue working even if the model is unavailable.

Open Architecture Makes Experimentation Possible

The AI layer is deliberately abstracted behind a local model interface.

That means the project isn't locked to one model.

A developer can experiment with different local models while keeping the rest of the walking system unchanged.

For example:

                 LocalModel
                     │
          ┌──────────┼──────────┐
          │          │          │
          ▼          ▼          ▼
      MockModel   TinyLlama   Future Model
          │          │          │
          └──────────┼──────────┘
                     ▼
             OFFLINE Planner

This is important because the interesting question isn't simply:

"Can an AI generate a walking route?"

The more interesting question is:

"Can AI be useful while deliberately disappearing from the user's attention?"

Open innovation makes that experiment possible.

AI That Measures Success by Disappearing

Most AI products measure success through engagement:

Messages sent
Sessions started
Time spent
Interactions
Retention

OFFLINE intentionally experiments with the opposite direction.

The ideal session is one where the user spends less time interacting with the application.

The phone should provide enough assistance to make the walk interesting and safe, and then get out of the way.

This is why OFFLINE includes experimental concepts such as:

Digital Intrusion Score

An experimental measure of how much the digital interface interrupts the walking experience.

Physical Engagement Score

An experimental measure representing how much of the experience encourages attention toward the physical environment.

AI Disappearance Rate

An experimental concept representing how often the AI can successfully provide useful assistance without requiring direct user interaction.

These metrics are exploratory project concepts, not validated scientific or clinical measurements.

What Makes OFFLINE Different?

The project is intentionally not another AI chatbot with a map attached to it.

It is designed around AI restraint.

Instead of asking:

"How can I make the user interact with AI more?"

OFFLINE asks:

"How can AI help the user and then disappear?"

That changes the product architecture.

There is:

No continuous chat requirement
No AI-generated feed
No engagement-optimized notifications
No requirement for constant screen interaction
No dependency on a cloud AI API for the core MVP

The AI prepares the experience.

The physical world becomes the interface.

My Agent Session

I used an AI coding workflow to design and implement the OFFLINE MVP, including its architecture, local model abstraction, walking experience planner, native Expo application structure, and testing workflow.

DevRelay Agent Session:

https://dev.to/agent_sessions/building-offline-for-hacktoberfest-an-ai-walking-companion-7tjxgv

Prize Categories

I am entering the overall:

Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass

The project focuses on using open-source/local AI to encourage people to spend more time outdoors while reducing their dependence on the screen.

I am not currently entering a partner category, because the current implementation does not use one of the listed partner technologies as a qualifying integration.

Project Goals

OFFLINE is an experiment in a different kind of AI product.

The goal isn't to make AI more visible.

The goal is to make AI useful enough to become invisible.

The project explores whether local AI can help people:

Spend more time outdoors.
Discover their surroundings.
Walk without constantly looking at their phone.
Keep location/session data local.
Use AI without requiring a cloud API.
Treat AI as an occasional tool rather than a constant companion.

Touch grass. Let the AI disappear.

Credits

Built as an open-source project for the Hacktoberfest Open-Source AI Challenge.

GitHub: https://github.com/j4b3-21/OFFLINE

License: MIT

Memora: Personal Memory System

Bhuvan_M_Acharya — Sun, 04 Oct 2026 13:00:30 +0000

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

What I Built

I built Memora, a personal memory system that turns unstructured information into an organized, connected memory.

Don't organize your memories. Just give them to Memora.

People constantly receive information they may want to remember later:

conversations
people
relationships
events
plans
photos
places
ideas
important facts

Traditional note-taking apps generally require the user to decide where and how to organize that information.

AI assistants such as Siri and Google Assistant are primarily designed to answer questions or perform actions.

Memora focuses on something different:

Memora is a persistent memory layer that understands information, determines what it represents, connects it with existing memories, and stores it in the appropriate structure.

Example

Instead of manually creating:

People/
└── Rahul/
    ├── Birthday: October 12
    └── Works at: Google

Events/
└── October 12/
    └── Rahul's Birthday

The user can simply say:

"Rahul's birthday is October 12. He works at Google and we met at the hackathon."

Memora can determine:

Person
└── Rahul
    ├── Birthday → October 12
    └── Workplace → Google

Relationship
└── User → met → Rahul → Hackathon

Event
└── Rahul's Birthday → October 12

The user doesn't have to decide where any of this belongs.

The Core Difference

Note-Taking App

User
  ↓
Creates note
  ↓
Organizes note
  ↓
Searches note later

AI Assistant

User
  ↓
Asks a question
  ↓
AI answers

Memora

User
  ↓
Provides raw information
  ↓
AI understands it
  ↓
Extracts entities and facts
  ↓
Finds related existing memories
  ↓
Determines where the information belongs
  ↓
Creates / updates memories
  ↓
Builds a connected personal knowledge structure

The user provides information. Memora handles the organization.

How I Built It

Memora uses a two-part backend architecture.

                         Mobile App
                             │
                    Text / Photo / Voice
                             │
                             ▼
                   ┌───────────────────┐
                   │    Spring Boot    │
                   │                   │
                   │    MainBoard      │
                   │    Ingestion      │
                   └─────────┬─────────┘
                             │
                             ▼
                   ┌───────────────────┐
                   │      SQLite       │
                   │                   │
                   │ Temporary Input   │
                   └─────────┬─────────┘
                             │
                             │ AI Analysis
                             ▼
                   ┌───────────────────┐
                   │      FastAPI      │
                   │                   │
                   │    AI Memory      │
                   │      Engine       │
                   └─────────┬─────────┘
                             │
                             ▼
                   ┌───────────────────┐
                   │ Structured Memory │
                   │                   │
                   │ People            │
                   │ Events            │
                   │ Places            │
                   │ Facts             │
                   │ Relationships     │
                   └───────────────────┘

Backend

Java
Spring Boot
Spring Data JPA
SQLite
Flyway
REST APIs
[ADD OTHER TECHNOLOGIES]

The Spring Boot service acts as the ingestion layer.

Initial input is temporarily stored with:

unique ID
timestamp
input type
raw content

It is then passed to the AI service for analysis.

AI Layer

Python
FastAPI
[ADD MODEL NAME]
[ADD AI FRAMEWORK / AGENT HARNESS]

The AI service determines what the information represents instead of relying on predefined categories.

Possible memory types include:

Person
Event
Place
Task
Preference
Relationship
Fact
Conversation
Experience

The structure is not limited to a fixed folder system created by the user.

Memory Processing

Raw Input
   ↓
Temporary Storage
   ↓
AI Analysis
   ↓
Entity Extraction
   ↓
Relationship Detection
   ↓
Existing Memory Matching
   ↓
Memory Classification
   ↓
Create / Update Memory
   ↓
Remove Temporary Raw Input

For example:

"Rahul is moving to Bangalore next month"

could become:

Person:
    Rahul

Event:
    Rahul moving to Bangalore

Location:
    Bangalore

Time:
    Next month

Relationship:
    User → knows → Rahul

The AI decides how the information should be represented.

Why Does Open Innovation Matter?

Personal memory is highly sensitive.

A closed AI API can provide powerful intelligence, but it also means that the core intelligence and infrastructure are controlled by an external provider.

Memora is designed around an open architecture where the AI layer can be:

replaced
self-hosted
run locally
upgraded independently
experimented with using different open models

This makes it possible to explore private, user-controlled AI memory without locking the entire application to one AI provider.

What Makes Memora Different?

Memora is not another chatbot.

It is also not a traditional note-taking app with an AI button.

The fundamental interaction is different:

Traditional App:

"I have information.
Where should I put it?"

Memora:

"I have information.
You figure out what it means."

The AI is responsible for understanding information and deciding how it becomes part of the user's existing memory.

A new memory can introduce:

New Person
New Event
New Place
New Relationship
New Fact
New Category

without requiring the user to manually create the structure first.

My Agent Session

DevRelay Agent Session: [ADD DEVRELAY SESSION LINK]

The project was developed with an AI coding workflow involving:

architecture planning
code generation
debugging
implementation
refactoring
testing
documentation

Prize Categories

Best Use of Gemma

Creator

Name: Bhuvan M Acharya

GitHub: j4b3-21

DEV: j4b321

What's Next?

[ ] Voice input
[ ] Photo understanding
[ ] Automatic relationship extraction
[ ] Semantic memory search
[ ] Memory graph visualization
[ ] Better temporal reasoning
[ ] Local AI inference
[ ] Cross-device synchronization
[ ] User-controlled memory editing
[ ] Memory deletion and privacy controls
[ ] Memory confidence and provenance
[ ] Better conflict resolution between memories

The long-term goal is to create a system that becomes more useful as it learns the user's world.

Built for a Friend

Memora was built for:

Madhav (My roommaye)

The problem they faced was:

The one man who forgets everything at the perfect time and calls himself the "Clutch Master" for doing the task at the last minute.

Instead of asking them to change how they take notes or organize their life, I wanted to build something that works with the way people naturally remember things:

messy, incomplete, contextual, and connected.

Try It

GitHub: https://github.com/j4b3-21/Memora

Memora

Don't organize your memories. Just give them to Memora.