[Sorry for the re-post the video was not showing]

Favnyr is a lightweight file browser (Rust+Slint) for Windows and Linux. At its core are workspaces: separate environments that keep their own views, tabs, folders, layouts, and display settings. You could have one workspace for work, another for games, and another for learning a new subject, then switch between them in just two clicks. Favorites remain shared and persistent across all workspaces.

Each workspace can contain multiple split views and movable tabs. Tabs can be dragged between views, detached, or dropped onto another view to create a new split layout.

Favnyr also includes shortcuts, local and network drives, configurable keyboard shortcuts, and custom commands.
It is not intended to compete with or replace the native file browsers provided by Windows and Linux, but to complement them with a different way of organizing and navigating files.

Because of the project’s complexity, AI has been used as a development assistant. However, every feature is reviewed and hand tested extensively before being considered complete.

Link here (include a video demo) => https://github.com/GlitchAwakened/Favnyr

We’ve released Topic Bench — a free, open-source desktop MQTT client for viewing, publishing, and managing any size or number of brokers and data sets.

It was built for daily work: multi-broker profiles, a live topic tree that stays usable on huge hierarchies, stickies, search, publish, and TLS — without the resource drag we kept hitting in other explorers.

Windows and Linux builds are on GitHub. Details and screenshots:

https://github.com/unipsycho/topicbench

the rust side is Tauri 2, and a few parts were fun to build:

speech runs on transcribe.cpp in its own worker process, so a GPU driver crash or a GGML assert kills the worker instead of the app. if the GPU worker dies it retries once on a CPU-only worker.

voice commands go to a small router model as one forced tool call. every tool (open an app, play media, write an email, press keys) goes through a single Effects trait, so a dry run just records what would have happened.

the phone app reaches the PC through a tiny relay server, and the live window view is WebRTC with webrtc-rs, Windows.Graphics.Capture and Media Foundation H.264.

the video is a real screen recording.

https://github.com/ishangautam7/Talvio

Hi everyone,

Last week I published a shared build cache manager that handles compiled dependencies and Cargo’s artifacts inside a shared directory. The idea is simple: why recompile the same dependencies every time? epicenter takes advantage of the “freshness” rules Cargo uses when compiling a project and lets you reuse what’s already built. No wrapper, no RUSTC_WRAPPER like kache or sccache.

These are some benchmarks on 5 test projects with 37 dependencies (best case: a monorepo with a shared platform crate): five cold builds went from 71.3 s to 15.3 s, and disk usage dropped from 3.65 GiB to 0.91 GiB.

epicenter is a state layer for Cargo builds. It uses features of Cargo that for some reason are not enabled by default, like a shared build directory, and rust-lld instead of the default linker (unfortunately this can’t be used on macOS, because ld64.lld is not a drop-in replacement for Apple’s linker). It manages everything as three tiers: a durable vault (store) of compiled units that survives cargo clean, the shared build dir that every project compiles into, and disposable per-job work dirs seeded from the vault.

How is this different from sccache or kache? They are rustc wrappers: they cache compiler outputs keyed by their inputs, but Cargo still invokes rustc (through the wrapper) for every unit, and each project’s target/ gets its own copy of the artifacts. epicenter works one level above, on the state Cargo itself uses to decide that a unit is Fresh. Restored units never reach rustc at all, and files are hard-linked rather than copied. It’s a different approach to the same problem, and the two can even be combined if you want.

I also developed it to help everyone writing Rust with agents who need different workdirs without creating a worktree for every feature. epicenter lets you create per-job build dirs seeded from the vault, without Cargo locking them and without duplicated dependencies. It also manages the dependencies for you: you can see what’s in the cache, prune old stuff by age, or evict a specific crate or a stale toolchain generation, with a dry run first so nothing gets deleted by surprise.

It’s built to be plug and play: run epicenter setup (or epicenter setup --fast) once, then keep building like always. It works with both stable and nightly toolchains. Linux/WSL and Windows are verified, while macOS is only compile-verified for now, so if you’re on a Mac I’d really appreciate it if you tried it and told me what breaks.

Requires Rust 1.91+.

https://crates.io/crates/epicenter-cli

There are a few nuances to my approach, but the key detail is that I wanted it to also work in a browser so I needed the ability to build to a wasm to be used in js.

Signal libraries don't offer browser based capabilities and so I created this to target web aswell as native.

I wanted to implement the Signal protocol for a series of secure messaging apps I’m working on, so I built this project to test and use in my own work. It’s still far from finished, but I think it’s at a stage where it’s worth sharing with the community.

IMPORTANT DISCLAIMER: This project is not professionally audited and is not production-ready. I do not recommend anyone use this in their own code yet. It is provided strictly for testing, experimentation, and demo purposes. I used AI as an assistant to help build this, so double-check everything before taking it seriously.

Project Links:

• GitHub: https://github.com/positive-intentions/signal-protocol
• Live Demo: https://signal.positive-intentions.com/
• Formal Verification Docs: https://glitr.io/docs/technical/formal-verification/signal-protocol
• Security Feedback (ROS): https://www.reddit.com/r/CyberSecurityAdvice/comments/1su8lir/security_audit_feedback_from_radically_open

Current Status & Development:

• Spec Alignment: The goal is to fully align with the official Signal protocol spec.
• Testing: It includes unit tests, but due to WASM testing limitations, I also added a Storybook-like UI to run and test it directly within a browser environment.

The impementation here is being used in a few experimental messaging apps (similarly unaudited and unreviewed):

• https://enkrypted.chat - javascript based approach
• https://glitr.io - rust based approach

I am also working towards adding it to an open source project soon as seen at: https://github.com/positive-intentions/chat for e2e open-source transparency in the implementation.

I've been working on a simple journaling web app where all your entries appear in a vertical timeline (I love to read my past journals and this timeline view helps me to look through my past journals easily without going over different files every single time I want to read a different entry), so you can easily scroll through previous days.

For now, this only supports text because I don't add media to my entries but if someone really uses it and they actually need media support then I'll add that too

It's local-first, supports Markdown, and is completely open source and self-hostable.

This is part of my SMBL project, where I'm building open-source alternatives to everyday software.

Here's a short demo of how it works. Would love to hear your feedback!

Live: click here

GitHub: click here

Cargo sucks for polyglot monorepos

Your AI coding assistant finishes a feature. The tests pass. But did anyone test the requirement it forgot?

SpecForge is an open-source tool that makes the connection between requirements and test evidence explicit.

You describe behaviors, rules, events, and verification obligations in structured .spec files. SpecForge checks their structure and relationships, then lets you inspect what has—and hasn’t—been supported by linked tests.

What it does: - Catches unresolved references and missing required information. - Links tests to the specific requirements they verify. - Shows verification gaps, even when the existing suite passes. - Exposes the specification through MCP, so coding agents can request relevant context. - Supports CLI checks, editor tooling, and custom extensions.

What it doesn’t do: generate your application code or automatically prove that prose requirements are satisfied. A consistent spec and passing linked tests are evidence—not a blanket correctness guarantee.

Built in Rust, with a deterministic checker: no model calls inside the validation loop.

▶️ Watch the demo: https://www.youtube.com/watch?v=qHeqgL9xydE

🔗 GitHub: https://github.com/leaderiop/SpecForge

Curious whether this would fit your workflow—or just add another thing to maintain. Feedback welcome, and a ⭐ is appreciated if you find it useful.

After using zed for a while and being impressed with its performance, I started building a DB Client in Rust + GPUI, to start with just started with simple features like just running a query or viewing tables but kept on adding features and it now has all the features I need in a DB Client (don't expect feature parity with DBeaver or other clients yet). Open sourced it and have people contributing to it too now. My focus was on performance, just the general ease of use and a non AI slop UI and I like to think I succeeded in all.

Benchmarks compared to DBeaver:

Video: scrolling speed with 1m rows loaded with 100+ columns and tab switches.

Give it a try and let me know how it feels and what it lacks. https://github.com/ShayanAbbas1/dbdelve

The part in the picture was built with Arris, a CAD geometry kernel. Each face is coloured by the operation that made it. You can rotate it in your browser: https://arris-labs.github.io

Repo: https://github.com/arris-labs/arris · `cargo add arris` · `pip install arris`

How it started: I wanted to build a CAD app and mostly play with the GUI. Then I hit the limits of the Rust kernels that exist today. truck, monstertruck and Fornjot are great projects that I learned a lot from, but none of them yet did what a CAD app needs from booleans, fillets and STEP. So I decided to build the kernel first, as an experiment: could coding agents build one if I designed the process around them? I set the architecture and the rules, made the decisions and built the checking. The agents wrote nearly all of the code, even though it appeared more complex and long task than I expected and the exhaustive tests have been burning up my PC (and GitHub CI) for several months already (and lots of hardening and corner cases search is up to do).

What it does:

• Booleans over planes, cylinders, cones, spheres, tori and NURBS, including NURBS against NURBS
• Fillets and chamfers, extrude, revolve, sweep, loft, shell
• Mass properties, queries, tessellation, STEP read and write
• Python bindings with prebuilt wheels for Linux, macOS and Windows

Why it's interesting as Rust:

• No `unsafe` anywhere and no C++ underneath
• Deterministic: same input, same output and ids on every platform, wasm32 included
• No panics on geometry: an unsupported case is a typed error naming the faces or edges
• Every operation reports what it generated, modified and deleted. That provenance is what colours the faces in the picture.

How I know it works: Open CASCADE is the test oracle. Every test fixture carries values computed by OCCT (volume, area, centroid, point classifications), and Arris has to match them. OCCT is never linked. An invariant checker runs after every operation in debug builds, and property tests run on random shapes in random poses.

What it doesn't do yet: fillets are the weak spot. They still refuse on 12 of the 38 real parts I test against. No variable-radius fillets, no non-manifold bodies. But I would probably fix that in a few days.

If it refuses or breaks on something you try, a short script in an issue is the most useful thing you can send. Each one becomes a regression test.

the core of my civilization sandbox is a single rust crate (crates/sim-core) that does no i/o at all. everything else is just a host for it:

• apps/web builds it with wasm-pack and runs it in a web worker, so the whole world lives in your browser tab
• apps/server wraps the same crate in a websocket server, and that's what the electron desktop app spawns
• crates/headless runs it flat out with no rendering, for seed sweeps and a perf gate in ci (three seeds at 8000 ticks plus one 25000-tick run, checking max, p99 and mean time per tick, and memory)

runs are deterministic, so the same seed and tick count give the same world. when i refactor something that shouldn't change behaviour, i save worlds at a few tick counts on main and on the branch and compare the hashes.

the sim itself: tribes of tabular q-learners that grow their own vocabularies and cultures, stone age to computers over 45 eras.

play: https://thehumanbox.com source (mit): https://github.com/1homsi/thehumanbox

A fast, native Oracle PL/SQL IDE written in Rust

A few months ago I switched from Telegram to Signal as my main messaging app and spent some time exploring CLI/TUI options. After using gurk for a while I decided to build my own client (faro), based on my own requirements and taste (you can probably see the UI/UX inspiration from tools like btop, OpenCode CLI, neovim).

It covers all features I commonly use within Signal:

• chats, replies, reactions, edits, mentions, search
• inline images (if your terminal supports them) or halfblock rendering otherwise
• voice notes and transcription (supports local whisper models)
• quick navigation menu for everything (Ctrl+P)
• copying over SSH, pasting images from clipboard

On the Rust side, the UI is built with ratatui and the Signal protocol side uses presage (which builds on Signal's own libsignal). The browser demo at getfaro.dev is the same binary compiled to WebAssembly. The GitHub repo is public: harababurel/faro.

For setting it up with a real account, you can run faro link and link it as a secondary device just as you would with Signal Desktop or any other client.

Disclaimer: I built it with a lot of help from AI coding agents, including open-weight models running locally on my own home server. However, I designed, reviewed and tested it thoroughly. I try to always pay attention to the details, and the general direction of the project is usually informed by my day to day experience using the project.

I wrote this post myself with zero use of any LLM. I am as allergic to reading slop as everyone else these days.

I hope some of you will give it a try and maybe provide some feedback on your experience!

Hey everyone!

I've been working on Dirule, an open-source CLI written in Rust for organizing personal folders and enforcing naming rules in coding projects.

It supports file sorting, reusable TOML presets, naming transformations, change previews, conflict detection, CI checks, and undo.

In v0.5.0, I also added optional LSP integration for updating source references when files are renamed, provided the configured language server supports it.

I've included a short demo showing how it works. Still improving the project, so feedback and suggestions are welcome!

GitHub: https://github.com/Slyverr/dirule

Disclosure: I used AI assistance to implement and refine features based on my own ideas, requirements, and design decisions.

https://github.com/linuztx/alter-zero
Hi everyone, I'm developing Alter Zero, an open-source terminal agent for coding, cybersecurity, and automation. It's written in Rust and runs on Linux and macOS.

It works directly in your project: reading files, making edits, running commands, and checking the results. You can ask it to investigate a failing test, trace authentication and access checks in your own code, or write a script to summarize logs.

It can also interact with running terminal programs and keep commands running in the background. There's support for subagents, reusable skills, MCP servers, and resuming previous sessions. Commands and file changes ask for approval by default.

It's light on resources: a single ~24 MB binary that typically uses 20–60 MB of RAM per session (~100 MB of free RAM is a comfortable recommendation), and it stays low even when subagents are running. It's also prompt- and token-efficient, so your API spend stretches further per task.

You can connect supported model providers, use local models through Ollama, or add a custom OpenAI-compatible API. The latest release, v0.15.0, adds simpler custom-provider configuration and shows generated file content as it streams.

The project is licensed under Apache-2.0. Installation instructions and a demo are in the repository: https://github.com/linuztx/alter-zero

I'd appreciate feedback, especially on the setup process, terminal compatibility, and tasks where it gets stuck. Issues and contributions are welcome.

I’ve had this project in my mind for more than a decade, but only in 2026 were the stars properly aligned for me to scratch that itch and build Melin: a replicated state machine capable of handling a million events per second with extremely low tail latency over LAN, strong durability guarantees, and automatic failover.

Most systems don’t need all of that. Some may tolerate occasional latency spikes, others loosely consistent ordering, or even optimistic durability. For all of these, a myriad of solutions already exist.

But in other cases, like in the HFT domain, compromising on latency, consistency or durability costs too much money. Companies will go to great lengths building specialized software to get a competitive advantage and keep it for themselves.

This project is an attempt to make such a system available to more, and for more use cases.

Melin’s use case

Technically you could build a whole website with just Melin behind an HTTP gateway, but that would make it the hammer in the "if the only tool you have is a hammer, you tend to see every problem as a nail" maxim.

Where Melin particularly shines is in highly concurrent state machines. Problems that are hard to shard and can be solved deterministically.

For example a matching engine can be sharded by instrument, but an exchange core with balance checks and risk checks cannot without consistency or latency tradeoffs, since every order may affect others. A game world can be sharded by zone, but any player can interact with any other, so every zone border becomes a synchronization hazard and anything global, like a shared economy or a leaderboard, still needs a single authoritative order. And even where sharding works, each shard needs its own replication, failover and journal, and recovering all of them to the same consistent point is a problem of its own.

The range of applications includes the financial domain, where most of the techniques I used are common, but also ads, logistics, games, science, and more. Its durability guarantees, recovery capabilities, and the byte-identical journals with a BLAKE3 hash chain make it particularly suitable for domains subject to regulatory audits.

On the other hand, Melin isn't a good fit for any service that involves digging into historical data, because the application state must fit in memory (twice actually, more on that later), and I/O is heavily discouraged for the sake of determinism and latency. It’s also designed to handle small payloads: requests and responses in the low hundreds of bytes.

Performance

Here’s how Melin performs:

Under load. About 1M events/s over four connections, each a closed loop keeping a fixed number of requests in flight.

Single event. One client, one request in flight.

Every figure is a full round trip as the client sees it, including persistence and replication under the default ack policy, on four bare-metal servers (one client, one primary, two replicas). See Melin's readme for more details on the hardware and benchmarking conditions.

Building a durable, low-latency distributed system

Anyone who has read about low latency programming has probably heard about mechanical sympathy and the related best practices: avoid allocations, locks & yielding, pointer traversal, syscalls, encourage contiguous memory access and cache locality, atomics, amortization.

Another maybe less well-known piece but foundational to Melin is the LMAX architecture. It provides safe and efficient concurrency: multiple threads revolving through common ring buffers in an orderly fashion, with one task per thread and one thread per isolated core. This implies a relatively small context per thread that is likely to fit well in the CPU cache. Overall: high mechanical sympathy, few context switches. The caveat though is that you need a thread per task, and this is the reason why Melin in a production setup currently recommends 12 cores.

Fast PLP NVMe SSDs are now common at most providers and can perform writes with extremely low latency, typically in the microseconds range. While PLP isn't strictly necessary for Melin to enforce its durability guarantees it makes fdatasync much faster. Still, Melin can’t dictate when the firmware or the filesystem will interrupt writes for housekeeping reasons and these can cause spikes in the milliseconds range. But because it is built to operate in a cluster the natural option is to just wait for the fastest journal disk(s) before acknowledging a record as durable, hiding the impact of the slowest one(s). This is a case where, counterintuitively, a cluster can have a lower tail than a standalone node. This ack policy is configurable. By default, a record needs to be persisted on disk by one node and present on another in memory before being acknowledged as durable, enabling RPO=0 through any single-node failure, with exposure to a double failure limited to the time the second node takes to persist the record.

DPDK-capable NICs are also fairly common today and can even be found on servers to be rented by the hour, allowing for “cheap” experimentation. If you don’t know about DPDK it’s a way for a program to bypass the kernel and take direct control of the hardware interface. The result of this direct line of communication from Melin to the NIC was already shown in the benchmark table: the whole profile shifts down and the tail stays flat much further out than it does with kernel TCP. This is far from a free win though: not only does DPDK bring non-negligible operational complexity, a good chunk of Melin's code was written to deal with DPDK. Bypassing the kernel also means bringing its own TCP stack. Thankfully we have TCP stacks written in Rust! UDP is also an option, and should make Melin even faster, but it would mean tens of thousands more lines of code for a custom protocol.

Storage kernel bypass in the form of SPDK was also considered but quickly discarded. The first reason is that preventing the kernel from accessing the place where the critical data is stored sounded like an operational nightmare. The second reason is that a huge majority of Melin's latency is network-related, not storage-related. As tempting as it was for me to try to squeeze out even more microseconds of latency, the benefits/effort ratio is just too low.

Another thing that helps with reducing latency while also providing fast recovery is performing snapshots on a separate shadow thread. Regular snapshots avoid the need for a new node to retrieve the whole history before being live, but Melin can’t afford to pause the application in order to copy its state (the snapshot) to disk, because that would result in a very noticeable latency spike. To solve that, the shadow thread executes a copy of the application. This is the reason why the application state must fit twice in memory: because there’s a copy of the application running in parallel.

LLMs were essential in this project because of its scale, and their involvement is quite obvious in the code. There is a lot of data to keep in mind in such a project and it touches so many aspects of software engineering. I knew before I even started that this was impossible to do alone, since I had already tried a decade ago. I don’t want to dive too deep into the topic of LLMs, but I can't avoid mentioning these either. And while I miss the pride I had in writing my own code, there definitely are things that LLMs are orders of magnitude faster at than any human is. They, and all the other hardware and software advancements made in the past decade, made this project finally affordable for me. LLMs make many mistakes, humans do too, and code reviews, automated tests, and regular benchmarks are as much needed as they were before, but also cheaper in some ways.

The Rust ecosystem is also so rich nowadays that I was very happy to discover great tools such as Miri and TSan. The former found 3 cases of undefined behaviour (UB) that native tests couldn't catch. TSan found an fd use-after-close that could have silently written into a journal segment. There also is a Rust implementation of Raft that enabled me to bring replica automatic promotion to primary. Its architecture isn't a good fit for Melin's data plane, but it's a reasonable solution for this specific use case in the control plane. This way, if the primary fails, the replica with the longest journal can take over in a matter of seconds. This recovery time could be greatly reduced in the future by moving this control plane to Melin's low latency transports.

Why not Aeron Cluster Premium instead?

There are a few similar systems that have already been commercialized for years, and anyone considering using Melin should take a look into these. The most famous one is Aeron Cluster Premium from Adaptive.

Unfortunately its license and price prevent me from being able to build a fair Aeron vs Melin benchmark myself, and the only figures I could find aren't comparable for multiple reasons: different workload, different durability guarantees, and the EBS storage that isn't a good fit for Melin (at least not today).

But of course, performance isn’t everything and Aeron Cluster Premium and Melin have notable differences in other aspects:

• Adaptive has been in this space for years and their product is much more mature.
• Aeron relies on UDP whereas Melin is TCP-based, and their ack policies differ. There are pros & cons to both aspects.
• Aeron Cluster requires a JVM, Melin is nearly pure Rust (DPDK involves a bit of C).
• Aeron Cluster is free but the Premium features (like kernel bypass support) come with a 6-figure license with SLA & support. Melin is free to evaluate and to run outside production. Commercial terms and support will be worked out with its first users.
• Company location and the nature of the license have regulatory repercussions. Melin's license is a BSL, and each release turns Apache 2.0 within four years.

So while one may solve the same problems with Aeron or Melin there are various reasons why one may prefer the former or the latter, whether these are technical, financial or regulatory.

The path ahead

Working solo on this so far with zero users allowed me to spend as little time as possible on communication and synchronization. I could hop from one topic to another without disrupting anyone else. While I'm quite happy with Melin's performance and feature set today there is room for improvement in determinism hardening, the DPDK and kernel TCP paths still differ in various places, and I'd love to spend some time on reducing the unsafe surface or making Melin work better on fewer threads. But I reached a point where the API, protocol and journal format are stabilizing and further work will greatly benefit from actual use.

Which is a big motivation behind this post. If you have a use for Melin, let’s get in touch!

contact@melin-engine.com

https://github.com/melin-engine/melin

(And if you don't have a use for Melin but enjoyed reading this, you may want to remotely attend the P99 conference, it starts today!)

I maintain Flux, a free MIT-licensed download manager. The Rust workspace separates the reusable transfer core, the Tauri desktop application, a CLI and a Native Messaging host used by the browser companion. The desktop UI is React; torrent support also includes a separately built native runtime.

The part I wanted to show is the browser-to-local-app boundary: the companion hands selected links and media to a dedicated Rust host, while the desktop queue owns the transfer state. Host registration and an active extension connection are separate states, so the setup UI needs to show which step is missing. Version 2.5 refreshed that flow and the popup’s media, page-link and queue views.

The queue supports HTTP(S) files, accessible media and torrents, with scheduling, bandwidth limits and source-supported resume. Release packages are Windows x64 installer/portable ZIP and a Linux x86_64 RPM tested on Fedora 43.

Source and workspace: https://github.com/Hactor00/Flux

Project site and setup: https://fluxdownload.org

Chrome companion: https://chromewebstore.google.com/detail/flux-download-manager/okimieponfbegjhmfdnnefnddofooipk

The images are the current desktop interface preview, browser popup with sample media and companion settings. The extension requires the desktop app and local bridge; Firefox ZIPs currently use temporary/developer loading. This is an AI-assisted project. The 2.5 validation record documents 130 Windows Rust tests, 128 Linux Rust tests, Clippy and packaged Windows/Fedora checks. Feedback on the core/host/application boundary is welcome.

Hello :)

This project is born from a major problem that I encountered when building Blur: theming.

I found a solution to that, which is Opaline, but I wondered: can I do this myself? Can I find a simpler solution to such a small aesthetic problem?

So I built Fenth, which currently has 11 built-in themes with 91 semantic roles, it's also available on crates.io/crates/fenth

My library relies on .theme custom plain files, which contain roles, and the big change from Opaline is that role variants are derived with mix() expression in the theme file itself, so a theme only needs about 17 base colors.

In the gif, I show a quick demo made with ratatui, that uses my library as theming.

Fenth was largely written with AI assistance, and I've read through and tested it.

Here's the repo: https://github.com/artemtsitronov/fenth

You can also download it on cargo: cargo add fenth

So what do you think? Would you use it? What should I improve?

Every agent action is signed and chained, so tampering breaks verification. Made in Rust, with a CLI and UI. In beta and I’m looking for testers and feedback.

https://tenbri.com/

https://github.com/tenbri/tenbri

Hey guys I have built a small project that's a ui framework for building desktop native apps in pure Rust with GPUI (from zed).

This is in early stage It would be helpful if I got some curious devs who could try and test this and raise some issues and maybe open a few PRs

repo :- https://github.com/yugaaank/clay

Thanks

https://github.com/boquila/egui_plot3d

I've been building Apex, a free download manager for Windows. The download engine is Rust (Tauri v2 for the UI shell), and the whole app is a 4 MB installer.

The part I'm proudest of is range re-splitting. A file is split into up to 32 byte ranges, all written into one preallocated file. When a connection finishes early, a monitor task takes the unfinished range with the most bytes left and hands its second half to the free connection, so a download doesn't crawl through its last few percent on one slow connection.

Each range's `end` is an `AtomicU64`. Workers never take a lock; they just re-read their `end` every chunk, so shrinking a range mid-download needs no coordination with the worker. Only the monitor splits, under the table's `Mutex`. Splits stop once remainders drop under 2x256 KB, and a download caps at 128 ranges.

Other bits:

- Resume after restarts, validated with ETag/If-Range so a file that changed on the server is never stitched together

- Browser extension that hands downloads to the app over 127.0.0.1 (it asks for no access to page content)

- No account, no ads, no telemetry. GPL-3.0

Windows only for now, and the installer isn't code-signed yet, so SmartScreen warns on first run.

Feedback on the re-splitting design is very welcome, especially the memory ordering.

Code: https://github.com/ThembaTman0/apex-download-manager

Re-splitting: https://github.com/ThembaTman0/apex-download-manager/blob/main/desktop-ui/src-tauri/src/engine.rs#L1670-L1760

I recently worked on Noema, an open-source, self-hosted productivity workspace designed to bring notes, documents, databases, and project management together in one place.

The idea is to create a flexible workspace where users can manage their work while maintaining control over their own data.

🔥 Some of its main features:

• 📝 Rich-text document editing with blocks, tables, equations, and more
• 🗃️ Databases with 7 views: Table, Board, List, Gallery, Calendar, Timeline, and Chart
• 📊 Project management with tickets, milestones, and sprint tracking
• 🤖 AI-powered writing, summarization, and workspace Q&A
• 🤝 Collaboration features, including comments, sharing, and permissions
• 🖥️ Web app and installable Windows desktop app
• 🔐 Self-hosting for greater control over your data

🛠️ Tech stack: Next.js, React, TypeScript, Tailwind CSS, Prisma, PostgreSQL, TipTap, and Tauri.

The project is open source under the MIT license, and it was built in just 4 days with the help of AI-assisted development using OpenCode.

🔗 GitHub: https://github.com/Guembri01/noema

This was an interesting experiment in rapid development and exploring how AI coding tools can help bring a project to life.

I'm sharing it here to get some honest feedback from the community.

What do you think about building full-featured applications with AI coding tools? And what would you build in 4 days?

I'd love to hear your thoughts! 🚀