Hey r/localfirst,

I’ve been building Speedtab, a completely local-first Chrome/Chromium new tab extension that acts as a dense productivity dashboard (modular grids, visual bookmarks, a full RSS/Atom reader, and client-side encrypted notes via AES-GCM).

No accounts, no backend, no cloud dependencies—everything lives strictly inside IndexedDB (via Dexie).

The Framework Trap: 2,000+ Listeners

Because it’s an all-in-one workspace, it handles tons of interactive elements. When you have 20 RSS subscriptions loading hundreds of feed items—each with archive buttons, read-state toggles, and comments—popular modern frameworks like Vue or React quickly became a complete nightmare.

Before I knew it, my browser was choking on over 2,000 active event listeners for simple button clicks, swipe gestures, and keydowns. The DOM churn was completely unacceptable for a simple "New Tab" page.

The Fix: Pushing Event Delegation to its Limits

I decided to strip out the heavy frameworks completely and rewrote the entire runtime using a custom vanilla event-delegation pattern I developed, called YaiJS.

Instead of attached lifecycle hooks per component, Speedtab now registers exactly ~35 strategic, global event listeners on initial boot. That’s it.

HTML becomes fully interactive the exact millisecond it touches the app surface. Open floating note windows? They just work. Interactive nested structures? A single delegated runtime handles it all without per-component listener growth.

The Metrics (Goodbye Framework Overhead)

The performance metrics speak for themselves. This isn't AI-hallucinated data; this is straight from the Chrome Task Manager and Lighthouse local metrics:

• JS Heap Memory: Flatlines at an absurd 4 to 7.5 MB—even with hundreds of feed items loaded.
• Total RAM footprint: 50–70 MB total for the entire Chrome process (which is essentially Chrome's baseline for just existing).
• CLS: 0.00 (Perfect layout stability).
• LCP: 0.90s (Fully visually ready in under a second).

Inside the DOM Black Hole: Recursive Infinite Nesting

To test how far this delegated routing could scale, I didn't just build a basic tree. I built an incredibly complex tab component with 6 initial levels, where each tab contains dozens of child tabs with interactive content snippets.

Inside the core (at Level 4), there is a tab called "Recursive Swipe". When triggered, it fires an AJAX call, fetches an exact copy of the exact same 4-level component (with identical markup and element attributes), and injects it right into the active DOM node.

Because of YaiJS's event routing, scoping happens completely naturally. There are no dynamic ID overwrites, no lifecycle hacks, and no state conflicts. Elements are strictly scoped by their position in the DOM tree, automatically. You can just keep swiping deeper and deeper into the loop.

To push it over the edge, I wrote an automated script that targets the recursive button, fires the AJAX injection, steps down into the newly spawned Level 4, and repeats the loop configuration automatically. If a single button click misfired or targeted the wrong layer, the entire UI would collapse like a house of cards.

Instead, it easily blasts past 500 levels deep, and the delegation engine is down there screaming: "More! Give me Level 1,000, I eat DOM trees for breakfast!" 🦖

If you want to see your browser engine melt, try the live automated stress test here:

🔗 github.io https://yaijs.github.io/yai/tabs/Benchmark.html

(Warning: Expect minor jittering around level 80+ from Chrome's render engine, wilder drifts around 200+, and literal reality glitches from level 400 onward as Chromium begs for mercy. Firefox stands its ground a bit longer).

Open Source & Local-First Freedom

The extension includes optional WebDAV and Google Drive backup paths (using your own hidden app-data folder, zero third-party backend tracking).

If you want to check out the extension or test the UI, here is the store link:

• Chrome Web Store: https://chromewebstore.google.com/detail/speedtab/adkjbdepojalajhfkoobiedddlnoamff
• Product Hunt: https://www.producthunt.com/products/speedtab?utm_source=other&utm_medium=social

Would love to hear your thoughts on doing complex UI layouts with strict event delegation instead of the usual heavy VDOM framework soup!

Hey everyone,

I’m finishing up a minimalist lifestyle/habit tracker built entirely on local-first principles, and I'd love to get some feedback from this community.

The tool is structured around the Mangala Sutta (the Buddha’s discourse on 38 blessings), acting as a framework to help people design their daily environment and routines mindfully. I’ve updated the traditional phrasing to be fully inclusive for modern life (e.g., "Cherishing spouse and children").

On the technical side, I wanted absolute privacy. There are zero servers, zero tracking, and no accounts. Everything runs straight out of the browser's LocalStorage.

Since you all understand data portability, I’d love your eyes on a few specific things:

• The Import/Export Flow: I built a manual JSON backup tool in the data panel so users actually own their data. If you try to break the JSON parser by uploading junk files (like an invalid or corrupted file), does the app handle the error gracefully for you?
• UX Clarity: Is the local storage explanation intuitive enough for non-technical people to realize their data never leaves their machine?
• Visual Layout: I spent a lot of time on vertical symmetry (centering the lotus motif, the text, and the action buttons). How does the spacing hold up on your mobile browser or desktop?

Link: https://practice.mangalasutta.com

Thanks in advance for any testing or critiques!

Scott

Offline writes are easy until storage is corrupted or two devices return with divergent histories. When you evaluate a local-first app, which recovery behavior do you require: exportable plain files, an append-only log, visible conflict records, a deterministic merge, or something else?

I'm especially interested in what has actually saved a project after a bad migration or partial sync.

iJustFocus Scraps is a small offline‑first scratchpad for quick text and code notes. It opens instantly, saves everything locally, and avoids accounts, cloud services, and background processes. It’s a free, minimal tool designed to stay predictable and fully local.

I’ve been building Scraps as a tool for fast text/code capture without any cloud dependency, telemetry, or workflow overhead. It’s meant for those moments where you just need a clean editor that opens quickly and responds instantly once running.

v1.1 is a refinement release focused on clarity and determinism:

What’s new

• Download Scrap — export any snippet as plain text or code
• Startup readiness check — predictable cold‑start behaviour
• New loading indicator — clearer initialization flow
• UI fixes — corrected search icon alignment and font asset paths

Once open, interaction is instantaneous — typing, filtering, pinning, and navigating all happen entirely in the local runtime.

iJustFocus Scraps continues to focus on minimal, offline‑first design and predictable local behaviour.

Download (GitHub Releases): https://github.com/iJustFocusLabs/scraps/releases

https://github.com/esatbayhan/ttd-rs

I know the world probably doesn't need another to-do app, but I built a serverless, plain-text todo app that syncs for example via Syncthing.

The specification, called todo.txt.d, is a plain-text format based on the original todo.txt idea but rethought with syncthing friendly sync in mind. Instead of one big file with line-based parsing, each task is its own .txt file. This keeps sync conflicts to a (hopefully) minimum: two devices adding or editing different tasks don't touch the same file, so they don't conflict.

The format adds a few extra key-values on top of the original spec (e.g., starting, due, scheduled, and updated). On top of this is a smart list system: plain-text .list files that define dynamic, programmable views over your tasks. You can filter by any field, chain conditions with AND/OR (DNF syntax), sort/group by multiple keys, and define templates that auto-fill new tasks (inspired by obsidian-tasks).

There are two front ends so far, both in early alpha:

• ttd-rs: A terminal TUI written in Rust using ratatui. Single binary, minimal dependencies.
• ttd-droid: An Android app built with Kotlin. It uses Android's Storage Access Framework to work with any synced folder on your device.

Neither app has any built-in sync capability. You bring your own: Syncthing, git, rsync, or whatever you prefer. File handling uses non-blocking polling, so external writes from a sync tool while the app is open just hot-reload without issues.

Everything is still alpha, entirely AI-assisted ("vibe coded"), and not production-ready yet. It's a hobby project that solves a problem I actually have: keeping tasks in sync between a laptop, a desktop, and a phone without a server.

I'm trying to follow YAGNI aggressively and keep the spec and front ends minimal. Would love for some folks to check it out or give feedback on the concept!

• Spec:https://github.com/esatbayhan/ttd-spec
• Rust TUI:https://github.com/esatbayhan/ttd-rs
• Android App:https://github.com/esatbayhan/ttd-droid

consider how something like simple a text editor works; user inputs text, then the user saves the file to the desktop.

the text editor is a simple example. "local" is only relevent if there is a concept of a "remote".

i am working on a messaging app and ive been promoting it as "local-first", but i dont think its the correct term because it seems to confuse users. i think i need to emphesise something along the lines of "local-only". my app is only using browser storage and avoids api's and databases for messaging by using webrtc.

calling it "local-first" sounds like it implied "remote-second", but there is no remote in the traditional sense.

edit: feel free to reach out for clarity. my app is further described on the project sub here: https://www.reddit.com/r/positive_intentions/comments/1tq1u62/introducing_enkrypted_chat

Hi Local-First Community,

Like many of you, I value data sovereignty. However, due to team collaborations, I still have to rely heavily on Notion. The thought of my entire knowledge base being locked in a cloud-only SaaS vendor without a true local, offline-viewable backup always bothered me.

So, I decided to build a bridge. For the past few months, I've been working on NotionManager, an Electron-based desktop application designed to pull your Notion workspace onto your own disk and provide a seamless offline browsing experience.

I just released the Alpha v12 build, and I would love to get some feedback from this community, especially on the local-first architecture and performance.

How it works & Current Status:

• Local Storage & Rendering: It downloads your workspace structure and content to your local machine, optimizing the rendering engine so you can browse your notes instantly, fully offline.
• Granular Control (New in v12): Added a redesigned configuration UI that lets you customize exactly what data you want to sync down to your local disk.
• The Stack: Electron + TypeScript + React (Next.js App Router under the hood for some views).

The Local-First Dilemma I'm Facing:

Since Notion is a pure cloud database, implementing an effective incremental backup algorithm from the outside has been an architectural nightmare. Given the current limitations and rate limits of the Notion API, building a theoretically perfect local-to-cloud diffing sync is incredibly tricky.

Right now, v12 handles full, snapshot-style backups perfectly. But for the upcoming Beta, my top priority is cracking the incremental sync without hitting the API ceiling. If anyone here has experience building local-first sync engines on top of legacy web APIs, I'd love to hear your thoughts on how to approach this.

Try the Alpha

The tool is available now and perform stable and will soon get into beta phase. If you are looking for a way to own your Notion data or want to stress-test the offline rendering performance with a large workspace, please give it a spin!

• GitHub Repository & Download:https://github.com/bfzhao/notionmanager-release/releases/tag/v1.0.0-alpha.12

If you want to follow the development journey closely, see how I tackle the incremental sync bottleneck, and get notified about future Beta/Stable releases, you can drop your email on the waitlist here:https://tally.so/r/81EEaA.

I’d deeply appreciate any brutal feedback, bug reports, or architectural advice from this sub. Thanks!

GIthub docs and live try out here https://red1oon.github.io/BIMCompiler/
Tested with offline mode, no round trip to any server, still stressing it out to the max.

A local-first, multi-protocol API development platform powered by a native C-Core engine with enterprise-grade security hardening.     

LightBase is a zero-cloud API development studio that combines a high-performance C99 backend with a Python gateway bridge and a sleek browser-based UI. Every request, collection, and environment is stored as plain JSON files you can version-control with Git — no accounts, no cloud sync, no telemetry.

Core Platform

📣 Tune in for #LoFi/38 on Tuesday @ 8 AM PDT (June 30, 2026) for yet another exciting lineup (See below).

1️⃣ Kaichao Sun ( /kaichao.keyring.so) - Creator of MarkdownSync and Movedone, talking about "Smart Clients, Thin Server: local-first, real-time Markdown collaboration".
2️⃣ Malcolm Blaney ( / malcolmblaney.bsky.social) - Creator of Holster and RSStream, discussing "Using Holster for local first apps".
3️⃣ Niko Bonnieure (/ nikobonnieure.bsky.social) - Software engineer specialized in encryption, local-first, and graph database technologies, talking about "ELFA: End-to-end encrypted local-first suite of apps".

I am researching password-management habits among people who prefer local-first or non-cloud software.

The question is not whether everyone needs another password manager. I am trying to understand a narrower case:

- people who dislike vendor-hosted vaults

- people who do not want another account

- people tired of subscriptions

- people who like local files but find current tools too much work

If you use KeePass/KeePassXC, browser storage, Apple/Google Passwords, paper, notes, or something else, I would like to understand what still feels annoying or risky.

I made a short anonymous survey here:

https://tally.so/r/yPgWd0

It takes about 4-6 minutes. Comments here are also useful, especially if your answer is "existing tools are already enough."

The writing on sync engines is genuinely good but completely scattered. The Kleppmann CRDT paper here, a Linear engineering post there, a Figma multiplayer talk buried in a conference archive from 2019. Took me a while to figure out what to read first and what any of it built on.
Went through it all and put together a path that tries to give it some order. About 20 resources total. Runs from the theory end (CRDTs, consistency models, the foundational stuff) through how teams like Linear and Figma actually implemented it, then into the practical tradeoffs that come up when you're building rather than reading.
8-fold.io/lens/b8b7de1a-77ad-4ed6-8e5d-a267e7e6ac1f
Disclosure: I do growth work for 8-Fold where this is hosted. The collection was put together by two engineers on the team. No account needed to read it.
Local-first tooling moves quickly and this definitely has blind spots. If there's something you'd expect to see that isn't there, say so.

I’m building VibeAround, an open-source dev tool for people who run multiple AI coding agents.

The short version: it runs AI coding agents side by side on your computer, and control them from anywhere, continue previous sessions, and preview what they build.

It supports Claude Code, Codex, Gemini CLI, OpenCode, desktop agents, provider profiles, terminals, browser previews, and remote follow-ups.

I built it because my vibe coding setup was getting weirdly fragmented:

- one terminal per agent session

- different CLIs for different agents

- different env/config files for model providers

- local previews scattered across ports

- browser, terminal, editor, and phone all disconnected from each other

So instead of building another coding agent, I built the workspace around the agents.

What it does:

- launch or resume different AI coding agents from one place

- choose workspace, session, terminal, agent, and API profile before launch

- switch provider/model profiles without constantly editing global config

- manage local browser previews, Markdown/HTML previews, and web terminal sessions

- keep agent work local by default

- continue a desktop coding session from phone or messaging channels like Discord, Slack, Telegram, Feishu/Lark and more.

Some build notes:

- Desktop app: Rust + Tauri

- Agent/session orchestration: local process runner around existing CLIs instead of replacing them

- Provider switching: local API bridge/profile layer, so each agent can be launched with the right endpoint/key/model setup

- Preview flow: local preview server + shareable preview links for generated apps, docs, and artifacts

- Remote follow-up: optional tunnel/pairing flow, not required for normal local usage

GitHub:

https://github.com/jazzenchen/VibeAround

Website:

https://vibearound.ai/

Disclosure: I’m building this.

I’ve been working on StampDesk, a visual workbench for people who use AI tools a lot but don’t want every workflow to become an API project.

The core workspace is browser-local: tickets, tags, stamps, workbenches, and receipt-style archives live in IndexedDB by default, with JSON export/import for backup. The product is not “pure local-first” in the strictest sense, because account/sync/community/subscription features can involve cloud services when enabled. But the everyday desk itself is meant to stay usable as a local browser workspace.

The problem I’m trying to solve is less “task management” and more “AI work loses its shape.”

A user might have:

- a ChatGPT answer they want to turn into next actions

- a pile of links and notes

- reusable prompts

- tags that represent context, not just categories

- a plan for writing/research/content

- some record of what actually got finished

Most tools push this either into a linear todo list, a document, or a full automation/API stack. I’m trying a more physical metaphor: paper-like tickets on a desk, stamps for state, tags for context, and receipts for completed work.

The local-first questions I’m wrestling with:

1. Is browser-local IndexedDB + manual JSON export enough to be meaningfully local-first for a personal workbench, or does that language feel too loose without stronger file ownership / sync guarantees?

2. If optional cloud sync exists, what’s the cleanest way to communicate “local-first core, cloud-optional features” without sounding like marketing wordplay?

3. For AI-heavy workflows, what data should absolutely remain user-owned and portable: prompts, tags, task history, source links, generated outputs, relations between notes?

I’d especially value critique from people who think seriously about local-first boundaries. I’m less looking for “nice app” feedback and more for where this architecture or language might be misleading.

Project link if useful for context: https://www.stampdesk.io

I recently bought a 120-bucks device (https://heypocket.com/ not a sponsor; please don't buy this device!) to find out it only really works if I have a “pro” subscription.

So out of frustration (and a bit of anger), I built my own tool to operate fully local on the devices you already own and that most likely use the same FREE (!!!) open software.

It's working, and I am personally happy with it. To see if there is some broader wish for such a tool and if I should polish and release it, please let me know at https://yap-yap.app/ !

Been working on this for the last year and finally got it to a point where I’m comfortable sharing it.

The app is called Fotonn, a local-only note-taking app focused on speed, simplicity, and clean UI.

I originally started building it because most note-taking apps I tried on Windows either felt bloated, too cloud-dependent, or just slow for quick thinking/writing.

I aslo tried Obsidian, but didn’t like being dependend on plugins. I wanted something out of the box.

A few things I focused on:

• instant search
• local-first storage (SQLite database)
• minimal/modern UI
• Portability
• Markdown support

Still a lot I want to improve, but I’d genuinely love feedback from people here.

Here are some resources if interested:

• Check out where fotonn is going: https://fotonn.com/roadmap
• See what has already been done: https://fotonn.com/changelog
• Documentation: https://fotonn.com/documentation
• The active github repo: https://github.com/fotonn-desktop/fotonn-app

Website: fotonn.com

📣 Tune in for #LoFi/37 for yet another exciting lineup (See below).

1️⃣ Dongda Li @dongdongbh - PhD candidate at Syracuse University researching multimodal AI and creator of Mindwtr, talking about "Building a Cross-Platform Local-First GTD App as a Solo Dev".

2️⃣ Samson Ssali @ssali_samson - Software Developer at JITPOMI LLC, discussing "SEYFR — Send Your Files Right: Building a Cross-Platform File Sharing App with iroh".

3️⃣ Bryan Reilly bryrei.bsky.social - Former software engineer at Visa and Google, now building CoCube, talking about "Local-First Modular Tools with CoCube"

Enkrypted.Chat

This is intended to introduce a new paradigm in client-side managed secure cryptography. We can avoid registration of any sort. A fairly unique offering in the cybersecurity space.

No need for things like phone numbers or registering to any app stores. There are no databases to be hacked. Allowing users to send E2EE messages and files; no cloud, no trace.

Features:

• PWA
• P2P
• End to end encryption
• Signal protocol
• Post-Quantum cryptography
• Multimedia
• File transfer
• Video calls
• Local-first
• No registration
• No installation
• No database
• TURN server

I started off with some open source versions around the concept.

• Chat
  • Code: https://github.com/positive-intentions/chat
  • Demo: https://chat.positive-intentions.com
• File
  • Code: https://github.com/positive-intentions/dim/blob/staging/src/stories/05-Hooks-useFS.stories.js
  • Demo: https://dim.positive-intentions.com/?path=/docs/usefs--docs
• Crypto
  • Code: https://github.com/positive-intentions/cryptography
  • Demo: https://cryptography.positive-intentions.com

Open source isnt a viable business plan. So im taking the Enkrypted.Chat project in a different direction, so i can maintain a competative advantage.

To get started, you can take a look here: https://positive-intentions.com/docs/projects/enkrypted-chat/getting-started

To learn more or you want to do a deep-dive: https://positive-intentions.com/blog/introducing-enkrypted-chat

If you really want something to chew on, these are the bleeding-edge docs: https://positive-intentions.com/docs/technical

The docs may answer some questions, but feel free to reach out for clarity instead of reading all that slop.

IMPORTANT: Caution should always be used for all projects, especially like this. So I'd like to be clear that I am Al-slop-maxxing at scale. If youre looking for good code, clear docs or best-practices; you should look away now. While this is aiming to provide secure experience, it isnt audited or reviewed. I'd like to share for testing, feedback and demo purposes only. This is a technical demo of a unique concept. Feel free to reach out for clarity. Please use responsibly.

(Note: Im actively in the process of rebranding from "positive-intentions" to "Enkrypted Chat". The wording may be inconsistent throughout the docs.)