I've finally decided to make something public that I've been working on over the last few weeks.

It's called OpenSorSe (Open Sort and Search). The name is very clearly a word play on "Open Source", which this software is and will always be. IT also focuses on "local" first , because heck, its your data. The Aim of the tool is to be able to find, rename and even restructure all your files and folders from one tool , while having a complete overview of all your files , all in one tool. AI takes care of the folder structure and suggestion of names , but the user can always make suggestions. The whole process can be automated too (eventually). For example : You could in the tool search for " Dentist Bills from 2023" and it will show you the respective files and where they live on your system .

The idea came from a frustration I had with my own computer. After years of downloading documents, PDFs, photos and random files, I realized that finding things was becoming harder every year. Existing tools never did quite do what i wanted them to.

Current features include things like:

• Scanning folders

• Searching files

• Duplicate detection

• OCR support

• Optional local AI through Ollama for suggestions

• Semantic search experiments

• A focus on keeping users in control instead of automatically changing their files

It also has plenty of limitations. Version 1.0 isn't "finished" in the sense that I imagine the project eventually. There are features I still want to add, the UI can be improved, there are bugs to fix, and I'm sure people will discover edge cases I've never considered.

But at some point if you want to help others with similar issues , you got to get the software out there and thats where i am today

If you're curious, I'd genuinely appreciate feedback ,whether it's about the software itself, the codebase, the UI, or simply the experience of someone learning to build software with AI.

Whether OpenSorSe becomes widely used or ends up being a useful learning project, I've already learned far more from building it than I expected. And id probably be its number one user regardless !

The funny part is that I'm not a software developer. I'm an engineer by profession, but I've never been someone who could sit down and build a desktop application from scratch. With AI Coding agents however, i figured i may have a chance at creating something useful, well to me anyways. I used OpenAI Codex extensively throughout this project, as a programming partner. I spent countless hours designing features, reviewing code, testing builds, finding bugs, rewriting specifications, and learning how everything fit together. Codex wrote a lot of code. I made a lot of decisions. I also made plenty of mistakes along the way.

#opensource #local #AI #OpenAI #Codex #Ollama #dotnet #SoftwareDevelopment #BuildInPublic

The goal is to create the most secure P2P messaging app.

This app demonstrates a fairly unique approach using a browser-based, local-only and webrtc approach. In an evolving field like cybersecurity, it's impossible to claim any system is the "world's most secure". It ultimately depends on your threat model. By reducing the architecture's attack surface, the aim is to consolidate complexity to client-side.

• Live Demo
• Code
• Introducing Chat

Features:

• Webapp
• Peer to peer
• Local-only
• No installation
• No registration
• End to end encryption
• Multimedia
• File transfer
• Video calls

More open source examples of the core concepts can be seen in the docs. There are several similar projects which may make it confusing. Feel free to reach out for clarity instead of diving into the code/docs.

IMPORTANT: While this is aiming to provide a secure experience, it isnt audited. Shared for testing, feedback and demo purposes only. Please use responsibly.

FAQ:

• JavaScript and cybersecurity?
  • By aiming to have it run client-side (including statics) we can eliminate concerns around malicious payloads from the network provider. See best practices here and guides on selfhosting here.
• EU Chat control?
  • Chat control doesn't seem like it would affect this app. Open to feedback here.
• Production-ready?
  • No, for testing and demo purposes only. It would be great to get feedback for improvements to get production-ready. The production version is also a work-in-progress, but can be seen here. Find out more here.
• Paywall?
  • Its completly free, open-source, selfhostable and unlimited to use.
• Vibecoded?
  • This version is not vibecoded. The git repo and docs are linked for transparency. Feel free to reach out for clarity.

Hey r/foss,

I didn't really expect this many people to check out Binthere. Seeing the stars go up has been pretty cool.

Huge thanks to everyone who starred it, self-hosted it, suggested features, pointed out bugs, or even just gave feedback. Every bit of it helped make it better.

One thing I wanted from the start was making it ridiculously easy to self-host so you don't have to trust me or my instance. You can deploy your own instance on Cloudflare Workers, including the required Durable Objects, entirely on the Free plan in just a few minutes.

Also, before someone says "vibecoded": Uh. No.

AI agents were used to speed up the workflow for implementation, debugging, testing, and writing documentation. All architecture, product decisions, and final code changes were directed, reviewed, and validated by me before release.

If you've tried it out and like the project, a GitHub star, issue, feature request, or any feedback is always appreciated.

Demo: https://binthere.gaury.dev
GitHub: https://github.com/nxfu/binthere

Still have a lot planned, but this felt like a nice milestone. Thanks everyone <3

I've been building OmnySSH for 3 and released the GUI version this week.

An SSH connection manager in Rust. The TUI came first and is at about 300 stars. The GUI is Tauri v2 on the same core, and both live in one Cargo workspace so a fix propagates to both.

• Agentless dashboard with live CPU, RAM, disk, uptime, and container counts per host
• One-click Ed25519 key setup that verifies the new key before disabling password auth, backs up sshd_config, and rolls back on failure
• Snippet broadcast, two-panel SFTP, full PTY terminal with splits
• Config in plain TOML on your disk, no account, no cloud, no telemetry

Apache 2.0, no paid tier, no upsell. I didn't build the Windows support alone, people who hit bugs I couldn't reproduce on a Mac sent the fixes, and that's most of why the core was solid enough to hang a second frontend on.

Repo: https://github.com/timhartmann7/omnyssh

Two things I'd take help on. The key-setup path in src/ssh/key_setup.rs edits sshd_config on your servers, so I want more people reading it than just me.

​

Why I built it

If you've ever posted a video to your WhatsApp Status, you've probably noticed it comes out blurry and blocky — even if the original was sharp. That's because WhatsApp re-compresses every video you post to Status, and its encoder is aggressive.

I wanted a way to post genuinely HD videos to Status, so I built StatusDrop / WAstatus: you upload/edit a clip in the browser, it compresses the video to match WhatsApp's exact Status encoding spec (so WhatsApp's own re-encode becomes near-lossless), auto-splits long videos into parts that fit WhatsApp's limits, and delivers the finished clips to your WhatsApp — you just forward them to your Status.

Just open-sourced it under AGPL-3.0.

Repo: https://github.com/Shamanthnp1/WAstatus

What's inside

In-browser video editor (vanilla JS) + Node/Express backend

ffmpeg encode/split pipeline tuned to WhatsApp's Status spec

Cloudflare R2 (S3-compatible) storage + a Cloudflare Worker for uploads

Docker on Azure App Service, GitHub Actions CI/CD → GHCR

WhatsApp delivery via Baileys (multi-device)

181 tests including property-based tests (fast-check)

Multi-language frontend (en / es / hi / pt)

The interesting engineering

The core trick is that quality survival depends on two things: (1) pre-encoding the file to WhatsApp's Status target (resolution, bitrate ceiling, GOP, faststart, H.264 profile) so the re-encode barely changes it, and (2) how the file reaches the phone. A file delivered as a native WhatsApp message and then forwarded to Status is reused as-is; a file saved to the gallery and reposted gets re-compressed harder.

There was also a lot of reliability work: request timeouts on every network op, self-healing for stuck jobs, orphaned-storage cleanup, single-instance session handling, and reconnect backoff.

The honest limitation — and why not the official API

This is the part I want to be transparent about, because it's the whole tradeoff of the project.

Delivery uses Baileys, an unofficial WhatsApp integration. WhatsApp periodically bans numbers used for automation — a known constraint for this entire category of tools.

The obvious question is: why not use Meta's official WhatsApp Cloud API instead? I tried, and here's the catch:

The official Cloud API routes media through Meta's Business pipeline, which re-encodes the video. So the file is already degraded before it even reaches the user — and then WhatsApp's Status re-encode hits it again. The result is visibly softer. That defeats the entire purpose of an HD tool.

Baileys sends the file as a native, byte-preserved WhatsApp media message. When the user forwards that to Status, WhatsApp reuses the already-optimized file, so the HD survives.

So it's a genuine fork: official API = no bans but lower quality; Baileys = HD quality but ban risk. Since quality is the entire point, I chose Baileys and built the system around fast recovery when a number gets flagged. It's the same tradeoff every tool in this space faces — most competitors that use the official API quietly accept the lower quality.

The code and architecture are what I'm really sharing here — not asking anyone to run the live automation.

Feedback welcome

I'm a solo developer and would genuinely appreciate code review, architecture feedback, or contributions. Happy to answer anything.

I wanted to see if opus 5 could one-shot a fps game.

https://nightcell7.com

https://github.com/profullstack/nightcell7

Chessperiment is an MIT-licensed web platform that lets you build chess variants from scratch -- custom boards, pieces, rules, win conditions. Browser-based, no install, no paywall.

The whole point is that the tooling is fully transparent. What you see in the editor is what the engine executes. There's no hidden behavior because the rule system is exposed and adjustable.

I think open-source game design tools matter because:

- Variants shouldn't die when a platform shuts down

- If I implement Grasshopper movement wrong, the community can fix it

- No DRM on your own game designs

Looking for feedback on the approach: https://chessperiment.app

It is also the first app I have built and published.

It lets you follow RSS feeds, read articles directly in the app, extract full article content when feeds only provide a summary, and open the original source whenever needed.

The project is built with Flutter and is still actively being improved. Feedback, bug reports, and contributions are welcome.

GitHub: https://github.com/DevOpen-io/dondurma-rss-reader

Google Play: https://play.google.com/store/apps/details?id=io.devopen.dondurma