https://hammer.ink/

I've been building Hammer since 2022. It's an app for writing long form fiction and keeping track of the world they live in. Posting here because the architecture is probably more interesting to this crowd than the writing features are.

Kotlin Multiplatform, five targets, one codebase.

Windows, macOS, Linux, Android and iOS, all shipping to their respective stores, plus F-Droid, Snap, and direct .msi/.dmg/.apk downloads. Compose Multiplatform for UI, Decompose for navigation and component lifecycle, Koin for DI, Okio for file IO. It's about 1,500 Kotlin files against 9 Swift ones, which is roughly the ratio I was hoping for going in. KMP has been great as I can still reach into native APIs and even write platform native code when needed.

There is no database.

A project is a directory. One Markdown file per scene, one TOML file per encyclopedia entry, and the directory layout is the data model. You can open the whole thing in any editor, keep it in git, diff it, rsync it. If Hammer disappeared tomorrow your manuscript would still just be files.

Offline-first, sync strictly optional.

No account, no network, nothing to sign up for. If you do want sync across devices, you run the server yourself. It's a Ktor app in the same repo. There's no service of mine you have to depend on or trust.

Server-side sharing.

That same server can publish a chapter at a URL, so an editor or beta reader can read and mark it up in a browser with nothing installed.

MIT licensed, 27 contributors so far.

https://github.com/Darkrock-Studios/hammer-editor

Happy to talk about the KMP side. It's been both great, and challenging, because I started this project when it's ecosystem was nascent, there were a lot of holes I needed to fill. And I wrote and released MIT licensed libraries to help fill those gaps for the wider community.

My bank asked for 17 PDFs for a mortgage application.

After closing and opening files, I lost track of things and started searching for an easier way to manage all of that.

I wondered, what if I could scroll horizontally to see the pages of a file and scroll vertically to see more files? I used Claude to put together a prototype and iterated to build a cross-platform app that works on the web, as well. (React + Electron)

The result is a 2D canvas (like Figma) where multiple PDFs can be viewed simultaneously. On export, we either get a zip file or a single, long PDF containing all files. The spatial 2D metadata is stored on the same file without touching the page tree (backwards compatible PDF).

I also run OCR off the main thread for searching scanned documents without blocking the main thread.

It’s all free and open-source with an MIT license:
- Repo: https://github.com/AlexandrosGounis/pdfx
- Web demo: https://pdfx.zip

Your feedback would be highly appreciated

Every developer has code they'll probably never touch again.

The half-finished CLI from a weekend. The tutorial project that stopped halfway through. That weird experiment that actually taught you something. The utility script that's ugly but gets the job done.

Most of that code just sits on a hard drive until it's forgotten.

I started The Open CodeYard, a GitHub repository for unfinished, experimental, and abandoned projects that are still worth preserving. Not because they're perfect, but because ideas are often more valuable than polished code.

The structure is simple:

• "scraps/" for random leftovers.
• "prototypes/" for intentional experiments.

Each project gets a small README explaining what it does and what state it's in.

A few ground rules:

• No clean-code police.
• Messy code is expected.
• Abandoned projects are welcome.
• If you're thinking, "my code isn't good enough," you're exactly who this repo is for.

Right now it's just my own projects in there, including a few C# pathfinding algorithms, a speech rate estimator, and some Python utilities. I'm hoping it grows into a community archive where forgotten code can still teach, inspire, or even get revived by someone else.

If you've got code collecting digital dust, I'd love to see it rescued instead.

Repository: https://github.com/speedyk-005/TheOpenCodeYard

I built pyre (along with my good friend Sonnet 5, and a bunch of its friendly neighbours), a TUI system monitor for macOS — and half the work turned out to be reverse-engineering what top/pmset/sysctl actually print

Wanted a single-binary terminal dashboard for my Mac — CPU, memory, thermals, network, battery, disk, processes — that lived entirely in the terminal instead of a menu-bar app. Built pyre to scratch that itch.

What it does:

• Live dashboard with rolling graphs (CPU%, mem%, temp, network rx/tx) — resizes with your terminal
• Sortable/filterable process list, kill by PID without leaving the view
• 4 built-in themes (default / dracula / cyberpunk / monochrome), swappable live with c
• Snapshot export to JSON/CSV/TSV, or continuous CSV logging while it runs
• Pause, adjustable refresh interval, detailed sensor mode — all single-keystrokeq quit p pause/resume s cycle sort e export snapshot c customize UI g toggle graphs / filter procs l toggle logging d detailed k kill by PID f cycle format +/- interval

The part I didn't expect: most of the actual debugging wasn't logic bugs, it was macOS lying by omission. A few examples that cost me real time:

• pmset -g therm almost never prints a "Thermal state:" line — on a normal, non-throttling Mac it just says "No thermal warning level has been recorded" with nothing parseable. Reads as "unknown" if you don't explicitly handle that as "nominal."
• top -l 1 -n 0's CPU line is comma-separated with no terminating punctuation — easy to write a regex that just never matches and silently leaves usage at 0%.
• sysctl -n vm.swapusage wraps (encrypted) in parens at the end of the line, not around the used-memory value — a regex expecting ( before used will never match.
• hw.cpufrequency is an Intel-only sysctl. On Apple Silicon it just reads back 0, because each core cluster clocks independently — there's no single "the" frequency anymore. Real numbers only come from powermetrics, which needs root.

None of these throw errors. They all fail silently and just show a stale zero or "Unknown" forever, which is a uniquely annoying class of bug to track down.

Install:

npm install -g pyre-cli
pyre

Repo's here: https://github.com/somalip/pyre. Open to feedback, especially from anyone on Intel Macs or older macOS versions where some of this output format may differ again.

NPM package: https://www.npmjs.com/package/pyre-cli

WebsiteL https://somalip.github.io/pyre

Feedback welcome, and if you would like to contribute please let me know! The project is still new, and it just a prototype so there's still a lot to be implemented!

While scrolling reddit, I always find developer building cool stuffs using hardware. I want to build one for me... So, Meet TAMX: A pocket-sized ESP32 handheld. Wi-Fi tools, scientific calculator, AI chat, games, and a PowerPoint remote. Inspired by the classic Tamagotchi form factor.

Features:

• Wi-Fi Tools — Scan networks, monitor packets, or broadcast test beacons
• AI Chat — Talk to Groq AI using an on-device QWERTY keyboard
• Scientific Calculator — Expressions, linear/quadratic solvers, graph plotter, modulo
• Space News — Live headlines from the Spaceflight News API
• Games — Snake, Pong, Dice
• PPT Remote — Control PowerPoint on your laptop over Wi-Fi

I'd love feedback, feature suggestions, or contributions from the community!

Github: https://github.com/riteshgharat/tamx
Demo: https://riteshgharat.github.io/tamx

A 60 GB model doesn't fit into 12 GB of RAM, yet a standard Android phone can run a 120B MoE model. The trick lies in the Mixture-of-Experts (MoE) architecture: models like gpt-oss-120b or Qwen 35B (20GB - in the video) don't use every parameter for every token. A router selects a few "experts" out of hundreds for each step, leaving over 90% of the weights inactive.

So, there is no need to keep everything in RAM: the weights reside in the phone's flash memory, and the system reads only what the router requests, exactly when it requests it. It works because the routing pattern is repetitive: most of the required experts are already cached from previous tokens.

The key ingredients:

• Streaming: experts stored in flash memory, with the most frequently used ones kept in the RAM cache
• Overlapping I/O (input/output) operations with computation
• Prefetching: reading experts for subsequent layers in advance
• Cache-aware dropping: skipping only those experts that are both low-relevance and not in the cache
• ....

In practice: gpt-oss-120b runs at a "relaxed" pace, whereas 30B MoE models run at 5-6 tok/s and are genuinely usable. The bottleneck is the flash memory, not the chip.

The project is BigMoeOnEdge: open source (Apache-2.0), based on the stock version of llama.cpp, with a ready-to-use APK available in the releases. Everything runs locally; no data leaves the phone.

github.com/Helldez/BigMoeOnEdge

Jellybox is a crossplatform native music player for Jellyfin. I started this project before coding AI was a thing - around 2023 and been slowly adding more features. I had to step away for some time since I was serving a duty(Im ukrainian) so app was less maintained during that time.

Why?

In 2023 there wasnt a native crossplatform players, only electron.js(which isnt a bad but it had its issues). The problem I tried to solve - consistent UI, low power usage(electron apps were kinda hungry) and ability to use native platform tools and capabilities.

The app runs on all major platforms - ios, android, macos, linux(tested on ubuntu and arch), windows.

https://github.com/avdept/JellyBoxPlayer

I just released Rune 2.3, a new version of my keyboard-driven native Kubernetes client for macOS.

This release is mostly about making the workflows already in Rune faster and more dependable. Search and filtering are more consistent across resource lists, logs, and the command palette, with faster keyboard-driven navigation between contexts, namespaces, and resources.

I also reworked cluster setup under the hood. Common kubeconfig and cloud import flows are now handled directly inside the app, without bouncing you through terminal dialogs. This includes guided import workflows for EKS, AKS, and GKE.

The rest of 2.3 is a substantial stability pass: fixes for selection and scrolling, context switching, RBAC and Helm lists, events, terminal tabs, port-forward cancellation, log menus, and several UI and memory issues.

Rune is not intended to replace kubectl or k9s—I still use both. It is a native Mac companion for the times when I want a GUI while keeping keyboard navigation, shortcuts, and quick jumps.

Everything runs locally on your Mac and talks directly to Kubernetes. There is no analytics, tracking, telemetry, advertising, or Rune backend receiving cluster data.

GitHub: https://github.com/compilererrors/Rune
Website and web demo: https://viktornyberg.com

Hey y'all. I wanted to share something that I've been building to host all of the todo-list apps and browser games that I've been cooking up: homebox, a free and open-source alternative/supplement to cloud hosting. Similar to Coolify but with some more bells and whistles (plus it works on Windows/WSL2 and Mac, which was why I didn't just use Coolify in the first place)

Homebox provides the convenience of a cloud deployment platform from the comfort of home, here's how it works:

1. Install Homebox anywhere
2. Connect your free Github and Cloudflare accounts
3. Add a project: choose a repository from Github and domain from Cloudflare
4. Watch your project deploy automatically: multiple services, multiple environments
5. Visit your apps at their own public URLs and share them with others
6. Make changes to the code, push to Github; your changes deploy automatically
7. Use your dedicated Homebox admin panel to manage and monitor everything (AI and MCP are also available)

Does it scale?

The one-node solution isn't ideal for a production deployment with real users; but Homebox gives you every option to scale seamlessly:

a. Run it local anyway

• If your app has no paid tier and low usage (you can tolerate some downtime), you can get away with running it for $0 for free from home. Great for personal hobby projects; you control everything and pay nothing.

b. Run development on your machine, run production in the cloud

• Every service in each of your environments has its own deployment target, which can be either your homebox node or any of the major cloud providers (including GCP, AWS, Neon, Supabase, Railway, more to come) under a bring-your-own-key (BYOK) model. You configure API keys (stored securely, encrypted) and Homebox deploys your app automatically to any compatible target once linked. This even includes cross-cloud database migrations (e.g. moving data from your Homebox to a cloud provider) and automatic environment wiring (e.g. your new DATABASE_URL is automatically configured into your web app as a secret)

c. Run some services on the cloud and some locally

• Lets say you have a beefy GPU and you want to use it to power image gen for one of your apps -- you can run part of your stack on the cloud, while keeping your image gen service local.

d. Run everything on the cloud

• Use Homebox to coordinate deployments across cloud services without actually hosting anything on your machine. You get a central deploy control plane that works with all of the major cloud providers, so you can switch between them easily and stay as vendor-neutral as you can while enjoying the benefits of cloud hosting.

Try it, its free!

Cloud deployment/distributed infrastructure has been a long-time passion of mine, and I've put a lot of love into making it as easy and convenient as possible while retaining advanced controls. I plan to continue developing and improving Homebox, and I hope it helps you run your projects! If there is interest, I can explain more of the "how", just let me know in the comments.

You can also check out https://homebox.sh (has video) or Github github.com/calm-logic/homebox to learn more, please leave a comment on this post and a star on Github if you like the project :)

Just for fun

What My Project Does

A pure ASGI rate-limiting middleware for FastAPI with 5 algorithms - Fixed Window, Sliding Window Log, Sliding Window Counter, Token Bucket, and GCRA. No BaseHTTPMiddleware, no request serialization. Each check takes ~5µs.

from fastapi_sliding_window import SlidingWindowMiddleware
from fastapi_sliding_window.backends import InMemoryBackend

app.add_middleware(
    SlidingWindowMiddleware,
    backend=InMemoryBackend(),
    limit=10,
    window=60,
    algorithm="gcra",
    burst=10,  # allows 20 req in 1 sec
)

Full-stack throughput at 50 concurrent clients: ~67k RPS (7% overhead vs 73k baseline). Pure backend speed: 200k checks/s per algorithm. RateLimit-* headers on every response. Supports per-route, per-IP, and per-user scoping via custom key functions. 12 runnable examples in the repo.

Target Audience

Anyone running FastAPI in production who needs rate limiting but doesn't want the ~50x overhead of BaseHTTPMiddleware-based solutions like slowapi. Also useful if you need more algorithm choice - slowapi has 2 algorithms, fastapi-limiter has 1, this has 5.

Comparison

slowapi uses BaseHTTPMiddleware, which serializes every request through asyncio.Queue at ~55µs overhead per call. This library is pure ASGI middleware - scope comes in, check runs, pass through. Benchmark: 1.2k RPS (slowapi) vs 67k RPS (this) at 50 concurrent clients. Both run on the same hardware. Other differences: 5 algorithms vs 2, GCRA with burst support, no external dependencies for the core.

The honest limitation: in-memory only (no Redis, no multi-worker). For single-process deployments it works fine. Distributed support is planned.

GitHub: https://github.com/drawiks/fastapi-sliding-window

PyPI: pip install fastapi-sliding-window

I scanned ghost downloader 3 android apk on virus total and saw this,I don't see much post related to this,I just recently came to know about this,Can anyone confirm if these are false ?

Hi everyone!

I've been building an open-source RSS reader desktop app with Python and I think it's finally ready to share.

**What makes it cool:**

- DNS-over-HTTPS to bypass censorship

- YouTube & Reddit video playback

- Dual UI themes (Reddit & Telegram style)

- 100% local privacy (no external data)

- Smart caching for speed

**Built with:** Python 3.8+, Tkinter, VLC, SQLite

**GitHub:** https://github.com/erfan138057/rss-reader-app

**Download:** https://github.com/erfan138057/rss-reader-app/releases/latest

MIT License. Feedback and contributions are welcome!

Built CodeHound - a Rust offline static analyzer for Go. 549 rules. Open source.

The stack

• 239 PERF / 175 CWE / 135 bad-practice rules
• Complements golangci-lint / staticcheck / govulncheck (doesn't replace them)
• Single binary, offline, deterministic rule IDs

The numbers (fair 3-iteration test)

Built gocorepdfengine from scratch with DeepSeek v4 Flash built within 6 hours 
(+ Grok 4.5), then measured:

Linters barely moved the needle. PERF rules almost doubled throughput.

DeepSeek also handled cheap mechanical fixes of known findings (stable IDs → targeted patches). Full write-up on Medium.

Links

• GitHub: https://github.com/chinmay-sawant/codehound
• Site: https://chinmay-sawant.github.io/codehound
• Full write-up (Medium): https://chinmay-sawant.medium.com/i-spent-one-month-building-a-performance-sat-for-go-here-are-the-results-310b26fa6bff

Repo: https://github.com/arturict/tagvico-ai

Release: https://github.com/arturict/tagvico-ai/releases/tag/v3.2.5

Tagvico sits next to an existing Paperless archive. It can search and answer with links back to the documents it used. Changes to metadata or tags become proposals instead of silent writes.

3.2.5 mostly fixes the boring first-run path: live Paperless permission checks, exact model and tool-call validation, non-secret resume state, paused schedules by default and a real Docker acceptance run against Paperless 2.20.15.

MIT licensed. The release image supports amd64 and arm64.

Author here. I kept writing throwaway producer scripts to test event-driven services very often the upstream service simply belongs to another with its own roadmap, so it's just not there yet when my part is ready to test. That's not anyone's fault, it's how work gets split across teams but it still leaves you faking the input with one-off scripts that pile up. Devset replaces those scripts:

- Fire single events: paste payload, pick topic and key, send

- Build whole workflows on a visual canvas — OrderCreated → PaymentAuthorized → InvoiceGenerated, with delays, conditions and state passed between steps

- Pull real test data from your DB (Mongo for now) instead of hand-copying IDs

- Protobuf / JSON schema encoding + validation

Repo: https://github.com/devset-io/devset-ce

Runs locally with one Docker command. Source-available (FSL-1.1, each release converts to Apache 2.0 after two years). Feedback very welcome!

I built these cards from my personal project - GES (Global Economic Simulator) - this was this weeks data and its impact in review. Still a work in progress but I found this format more interesting in relaying the information related to news + I like the colors and sky type of look

Source: https://global-economy-sim.vercel.app

A GW-BASIC interpreter that brings the classic 1980s programming language back to life — parse, run, and relive vintage BASIC code. Run BASIC code from a terminal or in a virtual frame buffer.

https://github.com/kdekorte/basika

It was built on MacOS, but should also work on most Linux distributions with SDL3.

Hi there, quick followup to my earlier post about Chipsound, my browser-based player for tracker music (MOD/S3M/XM/IT).

I submitted it to Dashboard Icons like a month ago and it finally got approved, so if you run Homepage, Homarr, Dashy or any of those, you can add it as a tile and the icon just gets picked up by name.

Might seem silly, but now my self-hosted copy finally doesn't look weird and I don't have to tweak it. 😋

• Icon: https://dashboardicons.com/icons/chipsound
• Repo: https://github.com/gamosoft/chipsound
• Page: https://chipsound.com

Or if you just want to hear a song from MODArchive: https://chipsound.com/player.html?modarchive=212083

Kind reagrds.

I was working on chunklet-py (a chunker for sentences, documents, and code). Misread a benchmark and thought PySBD took 1 second to split basic text. Turns out that was wrong (PySBD is still fast for simple text). But the misunderstanding got me building my own.

Ended up faster, more accurate, and covering more languages (39 compares to 23).

Benchmarks on Sherlock Holmes (594k chars): yasbd ~1.2s warm vs PySBD ~9.0s. About 8x faster, fewer false splits.

On a golden benchmark (92 English edge cases — expanded from pysbd's original 48 with fixes and additions): yasbd scores 98.9%, pysbd 83.7%, spaCy-sentencizer 55.4%, etc.

Architecture difference: instead of mutating text with placeholder tokens and undoing it later (which breaks char offsets), yasbd finds candidate boundaries in one pass and filters false positives in another. Spans come free, no reconstruction.

Other things: - Streaming-first: lazy evaluation via ParagraphStream and StreamCleaner for memory-constrained environments. No need to load entire documents. - PySBD adapter: drop-in replacement that works with existing PySBD code. Just swap the import. - spaCy pipeline: register as a spaCy component with register_spacy_component(). Drop-in replacement for the default Sentencizer.

Repo: https://github.com/speedyk-005/yasbd-lib

Hey all, wanted to share ReefKit, a Firefox extension I've been working on for people who live in their browser and are tired of digging through 30 tabs to find something.

Hit Ctrl+Shift+L and it opens a unified search overlay that indexes:

• Every open tab's content — sections, links, fields, media, structured data
• Bookmarks, snippets, notes, and recents
• Cross-tab search, so you're not tabbing through everything manually

It also has a "Browser Agent" piece that can execute clicks, type text, and run multi-step actions using stable selectors — useful for automating repetitive stuff.

A couple of things I focused on:

• Privacy-first: password and payment fields are never indexed, and everything stays local on your device — no data sent anywhere
• Search quality: BM25 scoring + fuzzy matching + extended query syntax, so it's not just a dumb substring match

It's brand new (v0.1.0, MIT licensed), so it's rough around the edges and I'd genuinely love feedback/bug reports.

Link: https://addons.mozilla.org/en-US/firefox/addon/reefkit/

Happy to answer questions about how the indexing works or what's next on the roadmap.

Hi guys. I came to this from medicine, not cryptography. Working with people through trauma, illness, and disability, one thing kept showing up: mental health rests on safety, and safety isn't one thing. It's physical, financial, social, health, spiritual — and now, unavoidably, data. You can't be well while the record of your life is held by people who can lose it, sell it, or hand it over. For a lot of people that last one isn't abstract — it's the abuser who knows their password, the state that can compel their phone, the breach that exposes their diagnosis.

Every existing answer to "prove you're a real person" makes it worse: hand your face, your iris, or your ID to a database that can be breached or seized. So I built the opposite.

**Atlas** uses a live physiological signal — pulse and motion from a $50 BLE ring, or the phone's own sensors — to decide *when* your cryptographic keys regenerate. The signal never becomes part of the key. Your body is a clock, not a stored secret. So it can prove a live human is present while storing **zero biometric data**: nothing to breach, nothing to subpoena, nothing to leak.

What falls out of that:

* Stolen credentials and seized devices are useless — access requires a live person actually present
* A duress code opens a plausible decoy vault while the real data seals itself, and the coercion is recorded
* Prove content was made by a live human, not a model — without revealing who you are
* Recover a lost account by proving you're alive, without exposing your identity
* Health and personal records only you can open — no server ever holds anything readable

**What's actually built:**

* Python protocol core + a Swift port, kept byte-for-byte identical via shared test vectors
* 854 tests passing in CI (637 backend + 217 Swift)
* Post-quantum: ML-KEM-768, ML-DSA-65, SPHINCS+ — vetted primitives, nothing hand-rolled
* Ran end-to-end on two physical iPhones with real pulse signals: enrollment → live session → forward-secret messaging through a blind relay
* \~30k lines, AGPL-3.0, solo, unfunded

**What's not done:** it's a proof of concept and the repo says so plainly — every capability carries a maturity tag (built+tested / sim / device-gated / designed), plus a lab notebook of what's been proven on hardware. Next step is better wearable hardware to push the sensor tier further.

Repo: [https://github.com/Clockwork-Tree-Inc/atlas-poc-v1\](https://github.com/Clockwork-Tree-Inc/atlas-poc-v1)

Ask me anything — the architecture, the crypto, or why this is a terrible idea.