I’m a product designer, and for a while now I’ve been building Tagdown, a notes editor for macOS. The core idea: every note is an ordinary Markdown file in a folder on your disk. No account, no proprietary database. Git, iCloud or Syncthing just work, because it’s just files.
On top of Markdown it adds:
callouts, tabs, KaTeX math and Mermaid diagrams, all as plain text
#tags, [[wikilinks]] with backlinks, and links to single blocks that you can embed in other notes
live queries like <query tag:project show:tasks /> that collect tasks from all your notes, or show notes as an editable table of their properties
a journal, version history, slides, HTML/PDF export, and publishing notes as a static website
a CLI and an MCP server, so Claude or other assistants can search and write your notes
It’s built with Tauri, Rust (Tantivy for search) and TypeScript, and it’s MIT licensed.
Honest state: it’s early. There’s no download yet, so you’ll have to build it from source (Node + Rust). There are rough edges, and I’d rather hear about them now than later.
Two things I’d really like your opinion on:
Does the syntax feel natural, or is it too much on top of Markdown?
What would stop you from switching from your current notes app?
I’m a senior SWE using AI coding tools daily. I analyzed my Claude Code transcripts and found 56% of API-equivalent costs went to rereading context. Cache expiry cost me $98.74 across 35 returns in 27 days, versus $2.95 with a warm cache.
That led me to build optimAIzr, which supports Claude Code, Codex and Opencode.
It analyzes usage, flags expensive patterns, helps you find optimization opportunities aaand much more.
Runs locally, with no account or prompt uploads.
On Mac there are shelf apps like Yoink and Dropover for parking files mid-task. I couldn't find one I liked on Windows, so I built Wedge.
How it works
- Start dragging a file (from File Explorer, the desktop or a browser) and colored shelf tabs slide out of the right edge of the screen. Drop it on one and keep working.
- Click a tab and the shelf opens as a drawer. Drag the file straight into any app: an email, a chat, an upload form.
- Files stay where they are on disk. Wedge only keeps a reference.
Also
- Real previews, and search inside PDF, Word, Excel and PowerPoint files
- A Pocket: gather files from different folders, then drag them all out at once
- Right-click > Add to Wedge in File Explorer, Ctrl+V, or send from your phone with a QR code
- Shared shelves backed by a Google Drive, OneDrive or Dropbox folder
- Temporary shelves that clear themselves, plus notes, tags and reminders
- Ctrl+Shift+Space opens a drawer from anywhere; the tabs hide for full-screen games and videos
Details
- Free and open source (MIT), Windows 10 and 11
- 5 MB installer (Tauri + Rust, uses the WebView2 that comes with Windows), no CPU use while idle
- No account, no telemetry; updates come from GitHub Releases and are signature-checked
- Not code-signed yet, so SmartScreen may warn the first time (More info > Run anyway)
I've been working on Cadence, a small, offline Linux app built around the idea of treating cognitive work like physical training.
At the gym, you track workouts, sets, and reps. I wanted something similar for work that requires concentration, whether that's programming, studying, reading, or writing.
The idea is pretty simple. A session represents a period of work, and within it you can log individual stints of focused effort. You can track how long you work, take breaks between stints, and look back at your activity over time.
The app has:
Count-up and countdown timers for individual stints
Sessions that group multiple stints together
A 12-week activity grid to see how consistently you've been working
A small floating timer that stays on top of other windows
Local storage with CSV/JSON exports and backups
It's fully offline, with no accounts, cloud syncing, or telemetry.
Built with Tauri, Rust, Svelte, and SQLite. Currently targeting Linux (primarily Ubuntu/Pop!_OS), with .deb and AppImage builds.
I'm interested in what people think about the concept of tracking cognitive work this way. Does treating focused work like training sessions make sense to you? I'd also appreciate feedback on the app itself.
OpenWave is an experimental, open-source Linux-based mobile operating system developed primarily in C++ with Qt Quick.
It features a custom launcher, native applications, system services, and a security architecture using SELinux, Bubblewrap, seccomp, and cgroups.
The project is under active development, and I'm looking for contributors interested in Linux systems programming, C++, Qt Quick, and mobile operating systems.
I wanted to share **AegisVault**, an open-source, zero-trust cryptographic workstation I built in Python for cold storage, air-gapped operations, and quantum-resistant communications.
### 🛡️ Why I built this:
I was tired of seeing "cloud password managers" get breached and wanted a truly local, sovereign offline workstation that doesn't rely on third-party servers or telemetry.
I got frustrated with the usual chat apps from major LLM providers so I built one for myself. I call it Gloss (Open source on GitHub: https://github.com/aayushch/gloss
Newsletter to Podcast is an open-source Python tool that turns newsletters and blogs into an RSS podcast feed! You can pick the sources, generate audio, and subscribe to the resulting feed in a podcast app that supports custom RSS (I use Castbox).
The project supports full article narration as well as spoken summaries. Full narration uses Edge TTS and needs no API key; summaries use Gemini and require your own key (though the free limit is quite generous)! You can set a maximum episode length and longer full readings split into numbered parts at natural text boundaries.
There’s a prerecorded sample on the demo page, and a simple command in the README that fetches an original sample article and generates fresh audio without an API key. The package can run locally or on a schedule in your own GitHub repository using GitHub Actions!
Deployment:
Run it locally with Python 3.12+ or use the included GitHub Actions workflow (recommended, and setup instructions are in the GitHub README). You host the generated MP3s and RSS feed wherever your podcast app can reach them.
Speech generation uses Microsoft’s online Edge TTS service (which is unofficial and can break or be throttled sporadically...) Optional summaries send article text to Gemini to be summarized. GitHub Pages publishing is available, but makes the generated feed and audio public (I use this since it's free hosting)!
AI Involvement:
I painstakingly steered AI to help creating this tool! In the application itself, article summaries use AI (Gemini) but are optional. Full narration skips the summarization step and uses text-to-speech directly.
Motivation:
I wanted to turn some of my favorite newsletters into podcasts (like Seth’s Blog and A Learning A Day) and couldn’t find a free and simple solution that already existed. Let me know what you think!
Muse Spark, Wonder, and Wonder-Full support through the Muse Code harness
Gemini Argon support through Antigravity
Support for using multiple simultaneous Openrouter keys
Support for the Opencode harness for Openrouter and Language Servers
Skills and MCP tools are imported from all installed harnesses, and not just borrowed solely from Claude Code anymore
Optimized and reduced starting agent instructions, with an accompanying skill glossary built into the system to still give agents plenty of information on how Orgtree works and how to use it
Org and team-wide scratch folders, so agents have a designated space for working collaboratively, and a place where AGENTS.md files can be written that reach all agents in the org or a full subtree
Bunch of added keyboard shortcuts, including undo + redo shortcuts
Multi-replies in chat
...and a secret hidden setting
Whether you use orgtree yourself, like to see updates so you can borrow concepts for your own orchestrator, or just find it interesting to follow progress, I'm happy to hear any feedback you have :)
A few months back I built a throwaway tool at a hackathon: pipe an error into it, get an explanation back. Half an hour of vibe-coding, genuinely rough, and I mostly forgot about it afterward.
Except I kept thinking: what if it didn't wait for you to notice something broke? What if it just watched, all the time, and told you the moment something did?
So I rebuilt it from scratch in Go and called it Watcher. It tails your logs in the background, groups repeated crashes into one incident instead of spamming you per occurrence, and explains the root cause using a small LLM that runs entirely on your own machine — nothing sent anywhere.
First real test, on a small VM: the crash got detected in under a minute, but the explanation took twelve minutes to come back. Spent days chasing that down; turned out I'd been running a model three times the size I meant to, the whole time. Fixed now, down to about two minutes, still not satisfied with even that.
The part that mattered more than any of that, honestly: when it's unsure, it says so. One crash, it named the right cause but flagged its own confidence as low, because some of what it cited didn't actually hold up in the excerpt. That's the whole point for me — not a tool that's always confident, one that knows when it isn't.
It's early and rough in real places. Posting it here specifically because I'd rather have people from this community poke holes in it or send a PR than polish it alone until it's "ready"; MIT licensed, a few issues are tagged for first-time contributors if you want somewhere to start.
I'm a personal trainer and gym manager who's become increasingly frustrated with the state of fitness and coaching software. Expensive subscriptions, half-baked applications, unnecessary cloud dependencies and questionable data privacy practices.
So I started building True Grit, a premium, entirely offline workout tracking and coaching application written in Flutter.
It's a massive undertaking, nowhere near finished, and probably more feature-packed than most people will ever need. But what I've built so far works incredibly well, and I've put an enormous amount of time and effort into getting it where it is today.
Some of its current functionality and ongoing development:
Workout tracking: The centrepiece of the application. Fast, intuitive logging with an overview mode displaying individual exercises in dedicated containers, alongside a guided, full-screen experience that takes you through your workout in sequence.
Media library and editing: A functional photo library and non-destructive editor using custom multi-stage shaders, with an interface inspired by premium photography applications. Performance optimisation is still ongoing, with video support planned.
Social exports: The goal is to produce beautiful, customisable workout summaries, progress photographs and comparison exports, complete with personal branding and optional overlays of linked training or client metrics. Parts of this are still in development.
Advanced analytics: Ambitious progression and comparison functionality, eventually allowing different training and performance metrics to be overlaid on the same graphs to explore relationships between them.
Bespoke training decay modelling: Inspired by Banister's impulse-response model, incorporating three separate streams of training data to help estimate training adaptations and recovery.
Custom interface: A bespoke calendar, dialogs, navigation and components built around the Liquid Glass widgets package for Flutter.
Cross-platform architecture: Built in Flutter, with plans for a dedicated desktop coaching interface offering a more spacious experience for client management and programme creation.
Much more to this too but i'd be here all day...
And perhaps the most important part? Everything is entirely local.
No mandatory accounts. No subscriptions. No cloud dependency. No vendor lock-in.
Your database, photographs and training history belong to you. Back them up wherever you want, migrate between devices and continue training regardless of your internet connection.
The longer-term vision is to allow coaches to create programmes and distribute them to clients through portable packages, with clients returning their completed training data just as easily.
I want the software to support the relationship between coaches and athletes, not replace it or make either party dependent on an expensive third-party platform.
But here's my dilemma.
I originally intended to sell True Grit. However, seeing the extraordinary pace of AI-assisted development, reverse engineering and feature-by-feature software reimplementation has made me reconsider the future of proprietary software.
I'm now seriously considering releasing True Grit completely free, publishing its source code and inviting community contributions.
Not because I think the work I've put into it is worthless, but because I genuinely believe the project could become something much more meaningful if other people were able to contribute to its development.
I'd love to see developers, coaches, athletes and researchers collectively improve it. Perhaps even establish open standards for exchanging training data that other applications could eventually adopt.
My biggest reservation is commercial exploitation.
I have absolutely no interest in companies taking the code, repackaging it and charging people for software intended to be freely accessible.
I want independent personal trainers, gyms and athletes to use it without restrictions, including coaches who earn their living training clients. What I don't want is another software company turning it into an expensive subscription service.
That makes licensing complicated, potentially requiring a source-available licence rather than a traditional open-source one.
And I appreciate that restricting commercial use could discourage some contributors, which is part of why I'm looking for advice.
There's also a more personal reason I'm considering this.
I'm completely new to Reddit, so apologies if this isn't quite the right place for this discussion!
Throughout my life, I've frequently chosen open-source software over proprietary alternatives. I've benefited enormously from the work of developers who've dedicated their time and expertise to creating incredible tools that anyone can use.
I've always had a tremendous amount of respect for that.
In many ways, I feel like this could finally be my opportunity to give something back to a community that's given me so much.
I'm under no illusion that I've built something perfect. I'm sure there are developers, designers and researchers far more knowledgeable than me in their respective fields who could take parts of what I've created and improve them considerably.
Honestly, that excites me.
Ultimately, my motivation is simple.
I believe independent coaches and athletes deserve better.
Personal trainers should be spending more time on gym floors, interacting with clients and actually coaching, rather than being held hostage by expensive platforms and unreliable cloud infrastructure.
And nobody should have to surrender their personal information just to track their workouts.
I'd be far prouder to see True Grit become a respected, freely accessible platform that genuinely helps people, and perhaps even influences how other fitness applications are developed, than to make money selling another fitness subscription.
Even if it never achieves that kind of recognition, knowing I've contributed something useful would mean a great deal to me.
So I'd genuinely appreciate some honest perspectives, particularly from developers, open-source maintainers and personal trainers.
Would you open a project like this to community development, keep it proprietary or take a different approach entirely?
And how would you handle licensing if allowing professional use and community contributions, while preventing commercial repackaging, was one of your fundamental goals?
It's an enormous vision, I know. But I genuinely believe the community deserves better.
Its an Alt+Tab style switcher for Chrome. Get previews across tabs and windows with quick actions and support for tab groups and bookmarks.
Manifest V3, no dependencies, no network access (CSP connect-src 'none'). Previews are cached on disk by URL. New in 1.3.5: group by, a window list, first-run preview capture, and a fix for pages with dark-mode filters. Video below, store link
I built this because I follow a lot of founder channels and couldn't keep up. You write a short file about what you're building, run it once a day, and it reads every new video from your channels and gives you a digest: which ones matter for you, and what to try from each.
A few things I cared about:
- Your own rules are checked in code. If you've decided "no paid ads", a video that says "run ads" gets demoted, and the digest tells you why.
- No made-up quotes. A quote has to match one stretch of the transcript, or it loses its quote marks. Someone on Reddit found a hole in my first version of this check, and it's fixed now with tests.
- Free brains first: your own AI agent, a local model with Ollama, or Gemini's free tier. It also works with Claude Code and Codex, and has an MCP server.
- Polite to YouTube: captions by default, small daily limits, and it stops when YouTube says stop.
Status: between beta and 1.0.0. Core is stable and usable end to end, but I'm still working through some transport edge cases, console polish, native commands, and doc gaps. Will tag 1.0.0 when those are closed.
I'm posting because I made specific choices about how a C2 should work, and I'd like criticism from people who've actually run C2 in the field. If any of those choices are wrong, I'd rather hear it now.
Three things worth reading about
1. Fully Malleable profiles that shape the whole response, not just its envelope. Where most tools shape the wrapper around a fixed payload model, TornadoC2's profile system controls what the response actually looks like, and it does so with one JSON file per profile. A profile declares the three request paths (check-in, tasks, results), the User-Agent with a separate Linux override, extra request headers and per-role request headers, the session cookie name, additional response headers a real server would send, and per-role HTTP status codes for check-in, tasks, results, and error paths. The shaping block then controls the structure of each body independently: an arbitrary JSON template with {{payload}}, {{ts}}, and {{nonce}} placeholders; an extract path that supports array indexing (data.items[0].envelope.b64); a selectable encoding (base64, base64url, hex, or NetBIOS-style lowercase letters); and a selectable placement (body, a named response header, or a Set-Cookie value). Three shapes per profile, each one independent — a check-in can return 201 with the payload in an X-Request-ID header, a task poll can nest a base64url blob three levels deep in a JSON envelope, and a result upload can return 204 with the payload in a Set-Cookie, all on one profile, each matching what a different endpoint of the mimicked service actually does. DNS and DoH profiles carry a separate dns_label block that renames the three verb characters and changes the per-chunk payload length, and a stager.path block can move the payload fetch to whatever URL the mimicked service actually uses. The profile applies to every transport that carries HTTP-shaped bodies — HTTP, QUIC, WebSocket, WireGuard, and the three pivot transports — while DNS and DoH read the label block and ignore the HTTP-specific fields. Every profile is validated at two gates: the handler refuses a profile with colliding paths or malformed shaping at startup, and the agent build runs a round-trip probe through every template — it renders a payload, walks the extract path, verifies the payload comes back unchanged before any binary is emitted.
2. Concurrent multi-profile handling on one listener. Every other framework binds one profile per team server. TornadoC2 serves every profile under profiles/c2/ at once — same port, same certificate, same process. The request path is the profile selector. A Chrome-profile beacon and a Slack-profile beacon hit the same handler and each gets the response shape its own profile declared. No restart to rotate profiles, no second server on a second port, no "active profile" state.
3. A team server designed for teams, not a single-user console with collaboration bolted on. Every other C2 I've used treats the operator side as a coordination layer added after the agent works. TornadoC2 treats the team as the point:
RBAC with a distinctguardianrole. Admins manage everything that keeps the engagement running. The guardian alone decides when it ends. A request to /deadman/arm or /deadman/halt from an admin credential is refused with a 403 and audited.
Hash-chained tamper-evident audit log. Every operator action writes to a chain where each entry carries the SHA-256 of the previous entry, anchored by an HMAC at the tail. Every mutating API response carries an X-Audit-Id header so a scripted caller can cross-reference the entry.
Credential vault with beacon-side validation. The check runs on the target, not on the team server, because a bind attempt from the wrong network either fails silently or succeeds against a system the engagement isn't authorized to touch. Values are never written to the audit chain.
Owner-restricted task cancel. An operator can cancel a task they queued before the beacon picks it up. System-queued tasks can only be cancelled by an admin. A refused cancellation is audited with outcome=denied.
Session viewers. Every beacons poll carries the caller's attached beacon ID, and the table gains a VIEWERS column showing who else is on the same beacon.
Content-addressed loot store with per-operator ownership, admin override with an audit marker, chunked upload up to 128 GiB per file.
Team chat with file sharing, DM filtering, pinned topic, and forensic preservation — when the sanitizer modifies a message body, the audit chain carries the SHA-256 and base64 of the raw input.
Per-operator webhooks to Slack, Discord, or Telegram with an SSRF guard that refuses loopback, private, link-local, and cloud-metadata destinations at registration time and again on every dispatch.
Beacon aliases, tags, notes, session graph. Keyed on beacon ID so they survive a stale-and-reconnect cycle.
Dead-man's switch with eleven secure-deletion modes, held by the guardian role only. It runs on a wall-clock deadline, not on an idle timer — operator activity does not reset it. When it fires it stops every listener, wipes the entire repository tree with the configured deletion mode (eight pattern modes like dod, nist, gutmann, schneier, plus three structural modes: trim for TRIM/discard on SSDs, scrub for prealloc + O_DIRECT + TRIM, and crypto for LUKS header destruction), and can optionally power off or reboot the host. The remote API requires confirm: true for crypto mode on every request, because destroying the LUKS header makes every byte on that volume unrecoverable — including data outside the TornadoC2 tree.
Two frontends over one client library. Terminal REPL as the reference implementation, PySide6/Qt GUI as a presentation layer over the same Client methods.
Transports
Ten native transports, split across three roles.
Direct transports. HTTPS, QUIC/HTTP-3, WebSocket, DNS TXT, DNS-over-HTTPS, ICMP echo, and WireGuard. HTTP, DNS, and DoH can be combined in one binary with automatic failover after N transport-level failures — a network that permits HTTP/3 but blocks TCP/443, or permits DoH but filters UDP/53, is reachable without rebuilding the agent for a different carriage. QUIC, WebSocket, and WireGuard are single-transport in this version. Each of the ten carries the same C2 protocol over a different carriage.
Pivot transports. SMB named-pipe pivot, TCP bind pivot, and TCP reverse pivot. All three solve the same problem: a child beacon that cannot reach the team server directly, carried by a parent that can. Every frame between the parent and the child is encrypted end to end with an AEAD session keyed off a fresh ECDH exchange — the parent forwards the child's C2 envelope verbatim and never inspects or modifies it. The child's own wire encryption to the team server is preserved independently of the pivot session. All three pivot transports share the same wire format, the same handshake, and the same per-direction keys; the only difference is which side dials.
Cryptography
Task, result, and identity signing. Every task is signed with the handler's ECDSA P-256 key over canonical JSON ({id, verb, args, timeout}, sorted keys, no whitespace) and refused by the agent if the signature fails. Every result is signed with the agent's own build-time ECDSA key and pinned at first check-in. Every check-in carries a separate signature over machine_id|hostname|username|os|identity_ts, verified before the session is pinned — a valid signature presenting a different public key for a known fingerprint is refused and fires beacon-identity-mismatch.
Wire encryption. Every request and response body is an AES-256-GCM envelope keyed off a P-256 ECDH exchange. The server's ECDH public key is embedded at build time; the agent's ephemeral keypair is fresh per check-in. The task signature covers the plaintext, not the envelope, so a MITM who terminates TLS and unwraps the wire encryption still cannot forge a task.
Pivot session. One ECDSA P-256 pivot keypair per engagement. Parent proves possession of the private half, child proves possession of its own identity key, both handshake payloads carry a role-specific domain separator. Fresh ECDH per handshake, HKDF-SHA256 to per-direction AES-256-GCM keys, parent's ack bound to the child's ephemeral so a captured ack can't replay against a fresh hello. Every frame after that is length-prefixed AEAD with a monotonic per-direction sequence number in the additional data — a gap or repeat is a fatal protocol error and the session is torn down.
On forward secrecy: the pivot tunnel doesn't have it. The parent reuses the same long-term pivot key in every handshake, so if that key is stolen later, an attacker who recorded a past parent-to-child session can decrypt it. Because the key is reused, this applies to every recorded session, not just one. Having both sides use a fresh throwaway key per handshake would fix it — it's on the list.
The child's encryption to the team server is a separate layer and doesn't have this issue. It's keyed off the server's ECDH key, which the parent never holds, so a parent compromise gives the attacker the tunnel, not the child's C2 content. On the other side, the child's contribution to the pivot handshake is a throwaway key that's discarded after the exchange, so a child compromise doesn't break past pivot sessions either. Treat the pivot key as an engagement-lifetime secret and rotate it between engagements.
Rest of the stack
Go implant for Linux + Windows, compile-time configured
Four compile-time OPSEC profiles (default, stealth, opsec, paranoid), bundling progressively more aggressive combinations of:
Anti-analysis heuristics. Anti-VM checks that detect common hypervisor artefacts (VMware, VirtualBox, Hyper-V, QEMU, Xen — registry keys, device names, MAC OUI prefixes, firmware strings), anti-sandbox checks that look for sandbox-typical process names, file paths, and hooking artefacts (Cuckoo, Joe Sandbox, ANY.RUN, CAPE, and the tools that ship with them), anti-debug checks against both userland and kernel-level debuggers (IsDebuggerPresent, CheckRemoteDebuggerPresent, NtQueryInformationProcess for the DebugPort/DebugObjectHandle/DebugFlags classes, PEB BeingDebugged, hardware breakpoint register inspection, and timing checks against rdtsc and QueryPerformanceCounter drift).
Runtime patching. AMSI bypass via in-process AmsiScanBuffer patch, ETW patching to blind the EtwEventWrite path that feeds script-block and .NET telemetry, and indirect syscalls on Windows where the agent reads the system service number out of the ntdll stub without executing it, then jumps directly to the syscall instruction inside ntdll.
Sleep masking. Four modes: rc4 and aes-ctr on Linux and Windows via a native sleep stub that encrypts the executable segment, cronos (fiber-based, Windows amd64 only) and hwbp (hardware-breakpoint + VEH handler, Windows amd64 only), both of which encrypt the same segment without running any Go code inside the encrypt/decrypt window. Every mode generates a fresh key on every sleep cycle, so two consecutive sleeps never produce the same ciphertext.
Binary shaping. String obfuscation, garble for control-flow obfuscation, and UPX packing in the paranoid profile.
Execution discipline. Shell history suppression for any child shell, jittered first check-in (2–17 s after launch) and jittered subsequent check-ins, working-hours window that suppresses outbound traffic outside a configured schedule.
Injection backends. Two for migrate <pid> — CreateRemoteThread on Windows and ptrace on Linux as the default, remote APC injection via NtQueueApcThread as the alternative on Windows.
What I'm not claiming
I'm not claiming full EDR evasion. I'm not claiming this defeats modern EDR, AMSI beyond the in-process patch, ScriptBlock logging, memory forensics, or behavioral detection. What I am doing is adding evasion techniques as aggressively as I can and continuing to add new methods as I find them and this is an active area of the project, not a finished one. If you know a technique that works against current EDR and would fit the framework, I want to hear about it.
The README has a full "what this tool does not claim" section. Short version on the specific limits: the hwbp sleep mask writes DR0/DR7 which is itself observable, APC injection removes CreateRemoteThread but NtQueueApcThread is instrumented by every major EDR, and lsassdump is the highest-signal verb by construction. The sleep mask encrypts the executable segment during the wait but does not encrypt the goroutine stack, so the call chain and locals remain readable between check-ins.
The limits section isn't hedging. It's what a defender looks for and what the tool doesn't do about it.
On the timeline and the AI assistance
I built this in 2–3 weeks with AI assistance. I'm saying that up front because it's relevant to how you read the post.
What that means in practice: I designed the protocol, the threat model, the role model, the profile system, the transport abstraction, and the pivot handshake. I made the decisions about what runs in-process vs. as a child, what's compile-time vs. runtime, what the audit chain records and what it doesn't, and why the guardian role is separate from admin. I understand every part of the codebase and can answer questions about why any specific piece works the way it does.
The AI assistance was for the mechanical volume — the ~70 native verb implementations, the transport boilerplate, the docs. The design is mine. The choices that determine whether the framework is useful or not are mine.
I'm noting this because a lot of people are curious about what you can build quickly with modern tooling when you actually know what you're doing, and a lot of people are (rightfully) skeptical of AI-generated security tooling. I'd rather be in the first conversation than the second.
Criticism on the design is what I'm after. If the abstraction is wrong, I'd rather hear it now than after 1.0.0.
Hello, awhile back I had an idea of making a mini app platform where you could quickly make a little app or document that lives as a file that you or your ai agent can edit. My initial motivation started as I was constantly using a invoice generator website to put together invoices to send. I didn't really like the style and also wanted to be able to have an agent create or edit them, while also letting me update them as well and have all data sync bidirectionally. From there it kinda spiraled into much more.
I've explored a bunch of options of how to have developers be able to make them. I started exploring swiftui like DSL and explored react, but wasn't really happy with anything.
I had never used Svelte before this, but when I stumbled upon it, it was exactly what I was looking for for my way of making slops! So I committed to svelte and am super happy with it so far. The app comes with about 50 or so prebuilt ones, but it's super simple to make your own.
It's all completely free, no accounts, no hosting anything. Literally everything is just a .slop file (which behind the scenes is a SQLite file).
I have lots of things i'm going to keep adding, but I think it's ready for some feedback.
Has now:
- bidirectional sync (essentially each slop gets a CLI your agent can edit the data / themes with)
- Ability to define custom icons and create widgets that live on your desktop
- PDF & PNG export
- Integrated theme builder to customize the look
Coming later:
- Share and live collaboration with friends
- iOS, Android, Windows, Linux
- Join the Discord or make a PR!
I'm sure there is some bugs I havn't caught, so i'd love if you are intrigued to try and create your own and let me know what you think of the flow (confusing?): https://hitslop.com/docs/getting-started/
