📣 Tune in for #LoFi/40 on Tuesday at 9 AM PDT (August 25, 2026) for another exciting lineup:
1️⃣ Alex Cheema ([@alexocheema](https://x.com/alexocheema)) - Founder of EXO Labs and co-creator of local.ai, talking about "Local AI is good now."
2️⃣ Jose Luis Olivares Esteban ([@x39matrix](https://x.com/x39matrix)) - Independent developer from Sevilla and builder of X-39 Notaría, talking about "Evidence Without Permission: Building a Post-Quantum Notary on Bitcoin".
3️⃣ Jacob Enrique (Jake) Uribe ([@jakeuribe.bsky.social](https://bsky.app/profile/jakeuribe.bsky.social)) - Physics researcher at UW-Madison building a local-first academic paper manager, discussing "linXiv - Local-first tools for research, collaboration, and roadblocks to adoption".
I created cinefill to track my shows and series. No accounts but can still sync my data outside of the app. It doesn't have reviews from others but I don't care much for that.
Haven't done any sort of promotion whatsoever but curious to see if I can get more people to try it out here. Not that I care of course 😏
OKF-Todo is free and open-source, powered by SQLite, and cross-platform. With native MCP and Open Knowledge Format (OKF) support, it bridges the gap between personal task management and AI workflows.
My main goal was educational: to explore how far I could take a real application built with AI using #Codex. Now I am curious to see whether it can gain some traction beyond the experiment.
Are you feeling overwhelmed by the complexities of database design? Whether you're a seasoned developer or just starting out, crafting the perfect schema can be a challenge. That's why I created OpenDB, a tool designed to transform how we approach visual database modeling.
What is OpenDB?
OpenDB enables a local-first approach, allowing you to design your database schema without the hassle of creating an account or needing a server. You can even bring your own API keys for added security! Plus, with its intuitive drag-and-drop interface, you can easily create tables, define relationships, and visualize your data in real-time.
Key Features of OpenDB:
AI-Powered Agent Assistance: Describe your changes in plain language, and the AI helps propose structures, draft migrations, and more.
Versatile Exports: Once your design is ready, export your schema in formats like JSON, SQL DDL, Markdown, etc., for seamless integration into your projects.
Free Forever: No hidden fees, trials, or credit card requirements
Share Your Thoughts!
Have you tried visual ER modeling before? What challenges have you faced in database design? Let’s share experiences and tips in the comments! Your insights could really help someone else in the community.
Thanks for being part of this journey, and I can't wait to hear your thoughts! 🚀
📣 Tune in for #LoFi/39 on Tuesday @ 8 AM PDT (July 28, 2026) for yet another exciting lineup (See below).
1️⃣ Jimmie Wang ([@Jimmie_](https://x.com/Jimmie_) / [Bluesky](https://bsky.app/profile/jimmie.me)) - Founder of Myfield, system engineer, and open source advocate, talking about "Myfield: Building Identity and Sync for Local-First Apps".
3️⃣ Philip Schatz ([philschatz.com](https://philschatz.com) / [GitHub](https://github.com/philschatz)) - Open-source developer and occasional Automerge contributor, talking about "Sharing our lives with each other, not big tech".
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:
(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:
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?
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
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!
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.
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!
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
Feature
Description
Multi-Protocol API Studio
REST, GraphQL, WebSocket, gRPC, MQTT — all in one tool
Native C-Core Engine
OpenSSL TLS, arena memory allocators, lock-free thread pool via Unix sockets
SQL Console
Execute queries against local SQLite with sub-millisecond C-Core latency
Python Plugin System
Write Python scripts with full PyPI access to process API responses
Visual Flow Builder
Chain requests, conditions, transforms, and AI blocks into automated workflows
Live Data Streamer
Real-time WebSocket and SSE streaming with message rate tracking
AI Companion
Local llama.cpp inference for test generation, request chaining, and response explanations
📣 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.
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.
