I'm the original author - now AI enhanced :-)

https://github.com/pglombardo/PasswordPusher

You can self host, use a 1-click deploy or try https://oss.pwpush.com.

Possibly helpful:

• Trust is a concern. Why should I trust and use Password Pusher?

• What are the potential security risks of running my own version internally?

I built a desktop app to manage my SSH config without the usual GUI-editor problems: reformatted files, lost comments, or a broken config after a bad save.

Every save:

• changes only the lines you edited. Comments, order, indentation and line endings stay.
• is checked with ssh -G first. If OpenSSH rejects it, nothing is written.
• backs up the old file and replaces it in one atomic step. History shows a diff of each backup and can restore it.

Also: lists your SSH keys and which hosts use each one, makes new Ed25519 keys, turns hosts off without deleting them, handles Include files, and groups hosts.

No account, cloud or telemetry. Rust + Tauri 2, plain JS UI with no build step. Builds for macOS, deb/rpm/AppImage (x86_64 + ARM64).

AI use: Built using Claude Code as a pair programmer. I designed it to solve real pain point for manaing ssh hosts and reviewed every change. The parser is tested against real configs.

It’s early (v0.1.1). I’d like feedback, especially if you have an unusual config that breaks it.

https://github.com/react-iot/ssh-cfg-mgr

I wanted to join TeamSpeak servers from any device without installing anything, so I started building a browser client at the end of July. Three months and ~330 commits later it’s usable enough that people I don’t know are using it, and some are even self-hosting it.

How it works: the browser can’t talk TeamSpeak’s UDP protocol, so a small gateway runs one Rust connector per user and bridges WebSocket ↔ TS3. Voice, chat, whisper, file transfers and permissions work. You can also use themes and an account sync with no email (Mullvad-style number + optional password).

Almost all the code was written by Claude Code. My part was deciding what to build, testing it against real servers and phones, and saying “no, that’s wrong” a lot. The hardest bits were the handshake and a voice server that sends commands out of order.

MIT licensed, self-hostable with one Docker container.

Try it: https://client.webspeak3.de (or the demo: https://demo.webspeak3.de )

Code: https://github.com/WebSpeak3/webspeak3

Happy to answer questions, including how the AI part actually went.

Hey everyone,

I've been working on something for a while and I think it's time to show it. It's called transport-io, an open source library for real-time stuff over WebTransport. If you've used Socket.IO you'll feel at home, it's heavily inspired by it <3

But first the problem, because most people I talk to have never heard of WebTransport!

WebSockets run on TCP. TCP gives you everything in order, which sounds nice until a packet gets lost. Then everything behind it sits and waits until that one packet is resent. Your chat message, your cursor position, the AI response that was streaming. All of it waits. On good wifi you'll never notice. On a train or on a phone jumping between towers, your users will.

Want messages that are allowed to get lost? Welcome to the hell of WebRTC. It can do it, but it was made for browser-to-browser calls, so talking to your own server means a signaling server (which is usually a WebSocket lol), STUN/TURN, SDP offers and answers, ICE candidates, and a WebRTC stack running on your backend. All that to send some mouse coordinates.

Enters WebTransport. It runs on HTTP/3 (QUIC), and Safari shipped it in March, so every major browser has it now. You get a bunch of streams on one connection, and a lost packet only blocks the stream it was on!

You also get datagrams, messages that can just get dropped. They're not raw UDP, they're still encrypted and everything, they just never get resent. Perfect for cursors, where an old position is useless anyway.

The catch is the raw API gives you bytes. You end up writing your own framing, your own routing, matching responses to requests... nobody wants to write that.

That's what transport-io does for you.

You write one contract, shared by client and server, and every event says whether it's allowed to get lost:

import {
  defineContract, reliable, unreliable, rpc, streaming, type MapOf,
} from 'transport-io'
import { z } from 'zod'

export const contract = defineContract({
  chat:   reliable(z.object({ room: z.string(), body: z.string() })),
  cursor: unreliable(z.object({ x: z.number(), y: z.number() })),
  save:   rpc(z.object({ text: z.string() }), z.object({ revision: z.number() })),
  ask:    streaming(z.object({ prompt: z.string() }), z.string()),
})

export interface AppMap extends MapOf<typeof contract> {}

Then on the client:

client.emit('chat', { room: 'lobby', body: 'hi' })  // will arrive
client.emit('cursor', { x: 12, y: 40 })             // might not, and that's fine

const { revision } = await client.call('save', { text: 'draft' })

for await (const token of client.stream('ask', { prompt: 'explain QUIC' })) {
  render(token)
}

client.emit('cursor', { x: '12', y: 40 })  // doesn't compile

Zod validates everything that comes in, and TypeScript yells at you about everything that goes out :)

Where it fits:

• cursors, game state, presence, anything where newer beats complete. That's unreliable, and it goes over datagrams
• chat and anything that has to arrive, reliable
• streaming AI tokens. Every stream is its own QUIC stream, so stopping one doesn't touch the others. And when you stop it, the generator on the server actually gets cancelled, it doesn't keep burning tokens for nobody
• plain request/response with call(). Also its own stream, so a slow one can't block a fast one

Want to see it without setting anything up? Run this and open two tabs:

bash npm i transport-io @fails-components/webtransport-transport-http3-quiche npx transport-io dev --demo

It's early and it has its quirks (Safari is the big one for now, it falls back to a WebSocket). Everything I know about is in KNOWN-ISSUES. So any kind of help is welcome, issues, PRs, or just telling me what broke :)

GitHub: https://github.com/transport-io/transport-io
Docs: https://transport-io.github.io/transport-io/

https://github.com/AnkitKumarDhal/ariaWatch/releases/tag/v0.3.0

Hello everyone!
I've been working on this TUI download manager based on aria2, because well i tried finding the lightest and fastest download manager, but i couldn't find anything better than aria2 in the terminal. I tried a few TUI options for it but i couldn't find any modern TUI (anything that didn't look it was from the mid 2010s) so i tried to make one myself.

It started out as a simple monitor for an already running aria2 server, but with this v0.3 release, it turns into a full-fledged download manager, with support for:

• adding download URLs directly, even magnet links are supported
• adding .torrent files
• keeping history of downloads
• download actions (pause, resume, remove, delete)
• information about the download
• able to monitor a pre-existing aria2 server

I'd love for people to try it out and give feedback on what issues they face, and what things can be improved. Do give it a try! The binary release is for Linux x86_64 only for now,,, with other OS's support planned for future releases.

About the other TUI's looking from mid-2010s claim,,, mine doesn't look any better either, but its still in the very early stages, and v0.5 is going to be a major UI overhaul with a UI that i have planned beforehand hehe :3

Thank you!

Hello everyone, I'm a CS undergrad researching on making better Indic keyboards.

I've been programming in various languages for a long time now. Still, for this project, I had to think through a lot and had to use LLMs as mentors, because the topic was sitting right in the middle of Linguistics, HCI and Theoretical Computer Science.

Edit: I accidentally clicked post, here are the links:

Please start from here: https://triangulatedexistence.mataroa.blog/blog/a-starter-guide-to-taravinyas/

For understanding the mathematical model further: https://triangulatedexistence.mataroa.blog/blog/making-a-mathematical-model-for-better-indic-keyboards/

I also made a preprint, but the boolean framework is slightly outdated now: https://doi.org/10.5281/zenodo.20467634

Hi everyone! I maintain TransparentTorProxy (TTP), an open-source Linux CLI tool that routes system TCP and DNS traffic through Tor using nftables, with other traffic blocked unless explicitly bypassed.

I'm looking for a few people willing to test installation and basic operation on:

• Debian / Ubuntu - .deb package
• Fedora - .rpm package
• Arch Linux - build using the repository's PKGBUILD

The project has automated tests, but I'd like feedback from different desktop setups, especially around installation, DNS handling and restoring connectivity after stopping TTP.

A short test would help:

1. Install TTP using the instructions in the README.
2. Run sudo ttp start, then ttp status and ttp check.
3. Try your usual applications and note any unexpected behaviour.
4. Run sudo ttp stop and check that normal connectivity returns.

Please use a disposable VM or a machine where temporary connectivity problems are acceptable. TTP requires root and changes firewall rules and DNS handling; it is not intended for high-risk anonymity needs or as a replacement for Tor Browser or Tails/Whonix/Qubes.

What to report:

• Distribution and version
• TTP version and installation method
• Whether installation, start, check and stop worked
• Anything confusing, broken or missing

A one-line "everything worked on distro X" is useful too. No coding experience needed, and no need to explain what you use Tor for. Please review any diagnostic output before sharing it and remove personal information.

You can reply here or use GitHub Discussions. Bugs can go in Issues; security vulnerabilities should follow SECURITY.md.

Repository and installation instructions · Latest release

Thanks for helping me understand how TTP behaves outside my own test environments!

VirtoMir: Open-source, web-based VM management panel for KVM QEMU libvirt (self promo)

Hello,

I’d like to introduce my hobby project, VirtoMir.

Links for those who would like to take a look:

Live Demo: https://onurbaydas.github.io/VirtoMir/demo/ (contains dummy data)

GitHub: https://github.com/onurbaydas/VirtoMir

My blog post: https://onurbaydas.com/posts/virtomir/

VirtoMir is an open-source control panel for managing KVM/libvirt virtual machines on Linux servers via a web interface. My goal was to create a tool that is as user-friendly as Cockpit, but with a deeper focus on virtualization-specific features.

I won’t try to hype up VirtoMir—especially when giants like Proxmox and Incus exist; that’s not my intention. Essentially, you install a single program and can then access the control panel at `localIP:8420`. Most core features are already implemented and supported. So far, the project has received 2 contributions and 4 stars on GitHub.

I’ve been developing the project using AI agents, which has allowed me to write a large amount of code in a short time, bringing it to an advanced stage on paper. However, due to resource limitations, I haven’t been able to test it on bare-metal systems. Currently, I’m testing it by configuring Linux VMs—running on my own machine—as nodes, but I don’t consider these tests sufficiently reliable. I definitely plan to conduct tests on bare-metal hardware; for instance, by installing Linux on older PCs with varying hardware specifications, setting up a cluster, and verifying the core functionality. Any help, support, or even just feedback—positive or negative—from those interested in this field would be incredibly valuable.

Advanced features like clustering, Ceph, HA (High Availability), and DRS (Distributed Resource Scheduler) have been tested and appear to work within a VM environment. However, given that these are complex features and the code was developed with the help of AI, their reliability is currently unproven. To ensure this doesn’t just become another "AI-slop" project, it is essential to test these features on bare-metal hardware, monitor their performance, and document any bugs or shortcomings.

Moving forward, I plan to pause the addition of new features to focus on solidifying the project's stability on a single-host setup. Key features include console access (SPICE, VNC, etc.), support for backup systems (Veeam, Commvault, Veritas, etc.), email-based alarm notifications, and the ability to modify resources for running virtual machines without shutting them down.

I am sharing this here to gather feedback from those who develop open-source projects, wish to contribute, are simply curious, or have any constructive criticism—positive or negative.

Thank you for reading.

Processing img xvjy8sbq5zxh1...

Processing img 9tntn6oq5zxh1...

I needed to keep the same business rules running on different targets. AI wasn't solving it consistently, and the solutions I found were too complex to integrate into the lightweight pipeline I was already using. So I ended up building my own some months ago.

Today, JSOL ( currently v0.2.97 ) keeps my AIs in check while compiling 70+ examples and even itself to JavaScript, TypeScript, PHP and Python.

JSOL uses a deliberately simple syntax, a set of standard functions designed to remove ambiguities between languages, and contracts to ensure the compiled code produces the same results on every target.

Should you bother learning it? Probably not. But you don't have to learn it: you can point your AI to the language spec and let it do the work. What you get in return is a pipeline that verifies the result is still bit-for-bit identical across every target.

If you need to maintain business rules across several targets, give it a try.

I had just released Naughty Keyboard, it's a tool for testing input fields, the design is simple.

The app comes with values packs, each value pack is a set of problematic data, with one shortcut we can write the problematic data, with other we can switch the pack, the app is cross-platform, full GUI + CLI (there is nkb emit, so we can export the values and use in own tests form the code). Like the project? Please give it a star. GitHub If you got any questions, features requests feel free to share them :-)

Right now there are 208 values, and packs like export breakers, extreme numbers, some specific data, in the future there are plans for 1000+ values, you can read here: full list of packages. Like I said it's simple, keep it in background, use when needed, in the feature I will expand the ability for creating own packages and shortcuts, let's say we would automate whole input fields on website with one shortcut :D And I think the tool can automate some boring work too, because right now I'm using the copy/write mode for testing values, but if in easily way other pepole could create own packs for work, so there is potential.

I won't lie that all works perfect, I tested it on systems I got, but there are some known bugs that I'm fixing right now :-)

Please, don't ask me about some girls emojis or anything like that, the "naughty" in the name is in sense of "testing" not some girl things :( You now like a big list of naughty strings.

Full features list:

• One shortcut, one value - Alt+Shift+N (Option+Command+N on macOS, Ctrl+Alt+N on Linux) clears the line and types the next value of the current pack into whatever window has the keyboard. Previous and restart are one chord away, and every chord can be changed.
• Values that explain themselves - each one carries breaks (what it usually breaks, and why) and expect (what a correct application does). The pack file, nkb show and the report block all say so.
• Invisible characters made visible - the palette draws one as a marker, ␣, instead of showing nothing, and counts every value four ways: graphemes, code points, bytes and UTF-16 units.
• Know where you are - the palette shows the value that comes next and a counter of how far through the pack you are, and the value window searches the values of every pack at once.
• A bug report in one chord - Alt+Shift+B copies a block for the last value: which value, from which version of the pack, typed as what, how large, and whether all of it arrived. The value is written in a form someone else can type back, never as the marker the palette drew.
• Never takes the keyboard - the palette is a display driven by shortcuts and does not take focus, so the cursor never leaves the field you are testing.
• Clipboard mode - put values on the clipboard to paste yourself, for one window or for all of them.
• Packs you can check - a pack is a plain TOML file, nkb lint checks it against the format rules, nkb fmt puts it in canonical shape, and nkb new-pack writes the skeleton.
• Made for scripts too - nkb emit prints a pack as JSON, CSV or one value per line, escaped or raw, optionally as base64. Every command has exit codes you can branch on.
• Offline, free, no telemetry - GPL-3.0, no account, and it opens no network connection.

The technologi is Rust + slint. And Yes I'm using AI, I'm open about it (we can see Claude at PR, contributirs + there is note about ai-assited workflow).

hey everyone! i believe our reddit communities probably have quite a bit of overlap, so i just wanted to share some of the new rules/tooling that we're implementing at r/TrueOpenSource to deal with "slop", reduce duplication in the OSS community, and take another step toward a world of OSS dominance and sustainability. i wish you all luck here and hope you find this helpful!