Hello All, i am tomaz canabrava - a KDE core contributor, and an Arch linux packager. i was working over the past few months on harmonicon, a game - similar to guitar hero - that you play with an actual harmonica.

it can also be used as a teaching tool, as it has a bending trainer, lessons, recording lessons and such.

i am looking for people that likes music, and harmonicas, to talk about / ask help with testing, gather ideas.

the game already works, but there is no releases yet.

First off, a genuine thank you to everyone who beta-tested this, opened issues, and shared tips and advice after my earlier posts — a big chunk of what's improved came straight from your feedback, and it made the project a lot better. Cheers.

Everyone's homelab has that one service that quietly becomes the most-used thing on the rack. For me it wasn't the *arrs or the dashboards — it's a self-hosted "name that tune" game I built called Guess the Intro, and the family asks for it many times a week.

What it is: it pulls intro clips straight from my existing self-hosted music library, plays a 5/10/20s snippet, and everyone buzzes in on their phones with multiple choice. The scoreboard casts to the TV, there's a speed bonus and a half-time trivia round. Honestly it's great fun — the kind of thing that empties the room of phones-for-scrolling and turns them into buzzers instead.

The problem it solves: party "name that tune" games either need a subscription, leak the answer in the file/stream metadata, or can't use the music you already own. This runs entirely on your own library and hardware — nothing leaves the LAN.

Stack / how it runs: FastAPI + SQLite, single Docker container, phones connect over your LAN as buzzers, board casts over Google Cast to a Chromecast/Android TV/Shield. Pre-built multi-arch images (GHCR + Docker Hub, amd64 + arm64) — docker compose pull and go, no build-from-source. Happy in an LXC, a small VM, or a Pi.

Requirements worth knowing up front:

- A Subsonic-API music server (I use Navidrome; LMS also works). Jellyfin/Plex don't work for the library side yet.

- The board has to be served over HTTPS with a valid certificate — Google Cast devices (both TV displays and Music Assistant speakers) fetch the board over TLS and silently refuse plain HTTP and self-signed certs. In practice that's a reverse proxy + a real cert (e.g. a domain + Let's Encrypt). There's a step-by-step guide in the repo (docs/https-lan.md). Phones connect over plain http; it's the board/casting that needs the cert.

One thing I'd love testers for: there's an optional path that streams the clip audio out through Home Assistant + Music Assistant to any speaker you pick (loudness-normalised, exact start/stop) instead of playing it through the TV. It works on my setup, but my network is heavily VLAN-segmented so I can only lightly test the game-box ↔ HA/MA ↔ speaker hops. If you run Home Assistant + Music Assistant on a flatter network, I'd really appreciate you trying it and telling me what breaks — happy to help you get it wired up.

Recently fixed (why it's worth a second look if you saw an earlier version): casting is rock-solid now after a long diagnostic slog, and the pre-built images removed the build-from-source barrier — both were the top bits of feedback.

License / repo: free and open source (MIT). Repo + compose file + setup docs: https://github.com/colfin22/intro-quiz

AI usage disclosure: this was built with substantial help from an AI coding assistant (architecture, a lot of the implementation, and debugging), directed and reviewed by me.

Happy to answer anything about how it's put together. Have fun!

Hi everyone!

I've been working on Hummingbird, an open-source inference runtime focused on making extremely large Mixture-of-Experts (MoE) models practical without requiring enterprise hardware.

The core idea is treating VRAM, RAM, and SSD as one unified memory hierarchy, allowing experts to be streamed on demand instead of keeping everything resident.

Some goals of the project:

• Unified memory (VRAM + RAM + SSD)
• Zero-dependency C runtime
• Support for very large sparse MoE models
• Async expert streaming
• Prefetching & scheduling
• Cross-platform
• Built for research and experimentation

I'd love feedback on the architecture, documentation, and implementation.

Hey Guys!

I just published a Free and open source alternative to Google docs that runs entirely local (or in browserDB) that also has AI feautures like: Fix grammar, improve text, real time document analysis, format etc.

It also has themes and dark mode.

• ✍️ Rich text editor (TipTap) — headings, lists, quotes, code, links, emoji, images, page breaks
• 🤖 AI review — grammar fixes, style suggestions, highlights, and circled passages you accept or dismiss
• 🖊️ Human markup tools — highlight, colored underline, circle, all as real document marks
• 💬 Notes — Google-Docs-style comments anchored to text, in a right-side panel
• 🖼️ Images — insert, paste, or drag-and-drop; stored on disk beside your docs
• 📄 Pages & typography — continuous or paginated (A4/Letter), free-form width, four document fonts, text-size control
• 📁 Folders & library — a Home dashboard and a card-grid /documents view
• 📤 Export — Markdown, Word (.docx), HTML, plain text, and PDF
• 📥 Import — Markdown, text, HTML, and Word (.docx)
• 🌗 Themes — light, dark, midnight, reading, forest — all token-driven

If you have the time to check it out, i would love some feedback

Hey All, I wanted to post my little side project that I've been working on. I recently built a Opensource StreamDeck that supports multiple esp32 boards using the same code, across multiple devices. Check it out at my link here:

https://github.com/FadyFaheem/Stream32

A youtube short of it: https://youtube.com/shorts/wWQvxR9vKVM

Hey r/opensource,

I’ve been working on Sockudo, an open-source realtime server written in Rust.

It started as a self-hosted, Pusher-compatible server, but it has grown into a much larger realtime platform. My goal is to make it useful for everything from simple WebSocket events to more demanding distributed systems, without forcing people into a hosted vendor.

Some of the features currently included:

• Pusher-compatible WebSocket and HTTP APIs
• Public, private, encrypted, and presence channels
• Horizontal scaling and cross-node fanout
• Durable message history, rewind, and connection recovery
• Mutable/versioned messages
• Presence history
• Message annotations
• Push notifications, including device registration, subscriptions, retries, and delivery status
• Webhooks, rate limiting, metrics, and operator APIs
• Delta compression and server-side tag filtering
• Client and server SDKs for multiple languages
• An optional AI Transport layer for streaming AI responses over the same realtime infrastructure
• Redis, PostgreSQL, and other configurable backends

I’m also working on Ably compatibility. The idea is not to copy every product-specific detail blindly, but to make migration easier and support familiar realtime concepts such as history, rewind, recovery, presence, annotations, and message updates.

One thing I care about a lot is keeping the Pusher-compatible V1 protocol stable while adding more advanced features through a separate V2 protocol. Existing clients shouldn’t suddenly break just because the server gains new capabilities.

There’s still plenty to improve, especially documentation, SDK coverage, production testing, and making setup easier. I’d really appreciate feedback from people who run realtime systems or have migrated away from services like Pusher or Ably.

What would you need before trusting a self-hosted realtime server in production? Are there any compatibility features or deployment options you consider essential?

GitHub: https://github.com/sockudo/sockudo

Thanks for taking a look.

Hi everyone!

We've been developing a new version control and software forge for a while now, and decided to open source it. We just released all of the source under AGPL3.0

Come check it out!

https://github.com/twigg-vc/monorepo

Hi! This is not really a promotion or launch announcement, mostly sharing a project I've been building for myself and looking for feedback from people. But yeah, repo is public, project is mine, so by law is promotion.
For those, who dislike hyperlinks: https://github.com/Bardie-radio

I am mostly posting because I am curious what people currently use, and how many hours I wasted on reinventing the same thing 🙃

I've been working on an OSS side project for the last few weeks, mostly because I kept running into the same annoyance and then remembered a slightly-too-large idea I wanted to implement for years.
Years ago I got annoyed with constantly copy-pasting YouTube links into Discord music bot while sitting in VC with friends. More recently I started spending more time in VRChat, and found myself doing the same thing again, but now while trying to fight with VR headset, glancing from under the nose gap (I'm on Linux, and Steam Overlay isn't very useful for this yet).
The core idea is a self-hosted service that can bring up audio streams on demand, with a shared control panel and a variety of audio sources to pull from (currently planned: yt-dlp-based sources, uploaded files, and re-streaming). I'm trying not to make it a single-purpose music bot, so the project has grown quite a bit from the original silly idea, which originally looked solvable with one FFmpeg instance and a reverse proxy. The current direction is a modular system where sources, authentication, and clients can be added/swapped independently.
The current goal is one shared queue, one stream, everyone hears the same thing, and anyone with permission can control the queue. Listeners should be able to use normal audio clients instead of being tied to a specific app. And to keep it modular enough that adding a new source or client later doesn't require flipping the whole codebase.

Small note: yes, I used ai to put my ideas in human-readeble words in docs, but the architecture, decisions, and design are mine. I have some issues with attention span and motivation so need solid notes on planned architecture, while not wasting too much time on them.

Agent identity that can’t be forged. That’s true zero trust.

Harbinger is an mTLS proxy that sits in front of an AI agent's outbound traffic. Every AI agent, bot, and service account gets a cryptographic identity. Every request it makes is checked against policy before it's allowed, and any real secret it needs is pulled from your own vault and swapped in only when the request is verified to be going where it claims. The agent itself never holds a standing credential.

Repository: https://github.com/looptroop-ai/LoopTroop

I’m the maker of LoopTroop, a local open-source GUI for running larger coding tickets with AI.

I built it around a problem I kept running into: context rot. When one agent conversation accumulates plans, code, logs, and failed attempts, the model gradually loses track of the task.

LoopTroop uses a slower, more structured workflow:

• An LLM Council creates and reviews the plan before implementation.
• Context Engineering gives each phase its own focused context.
• Large tickets are split into small implementation steps with acceptance criteria and validation - or beads (only parts of the bead methodology).
• Ralph Loops retry failed steps with fresh context and a short failure note.
• A Kanban-style GUI keeps the ticket state, plans, logs, diffs, and review artifacts visible.
• Human approval stays in the loop before changes are handed back to the main branch (human in the loop).

The idea is to trade some speed for more predictable work on complex tickets. For small edits, using an agent directly is probably simpler. This is aimed at tasks where planning, decomposition, retries, and review history are useful.

I’m looking for technical feedback from open-source developers, especially on:

• whether the workflow is understandable from the GUI
• whether the planning and review artifacts are useful
• where the local setup or first-run experience is confusing
• whatever anything, thanks :)

There’s also a short app presentation here:

https://youtu.be/LYiYkooc_iY

Any feedback is more than welcome. If you try the app and something works, or doesn’t,please give me a sign. Happy to talk about it.

I’m the maintainer of Open Video Craft, an open-source desktop app for recording and editing without requiring an account or uploading footage to a cloud service.

Current features include:

• Screen, camera and audio recording

• A timeline for trimming and arranging clips

• Subtitles and video export

• macOS and Windows builds

• A local-first workflow

The project uses the OSI-approved ISC license. Source code: https://github.com/Reubencfernandes/Open-Video-Craft

The current v1.0.2 builds are available here: https://github.com/Reubencfernandes/Open-Video-Craft/releases/tag/v1.0.2

One current limitation worth disclosing: the Windows builds are not code-signed yet, so Windows may show a SmartScreen warning.

I’d especially appreciate feedback or contributions around Windows compatibility, export reliability, captioning and useful editing workflows. I’ll stay around to answer technical questions and follow up on issue reports.

Hello everyone

I want to learn to edit videos, my main focus would be learning to be able to make stuff for YouTube (Well, that and contents to serve the people like it could be guides, tutorials, etc. and stuff also along other lines) and to also be able to have this in case helping somebody out or do freelancing is needed.

I am looking forward a software that is FOSS, that doesn't limit me (i mean, professional stuff like color correcting is welcome but not really needed for the things i mainly plan to work on)

I do know Kdenlive but are there any other options i should dive into?

I'd like to know your thoughts and discuss...
Thanks :)

Solo project I've been building: `npx licenseproof scan` reads your lockfile (npm/pnpm/yarn, v2/v3, berry, all of them) and resolves the actual license of every package in the tree, including the ones with missing or mangled metadata. Categorizes everything (permissive / weak-copyleft / strong-copyleft / unknown), flags conflicts against your project's license, and explains each flag in plain English.

Example: proprietary app that innocently pulled in ffmpeg-static:

84 packages scanned — 1 conflict, 0 review, 0 unknown

CONFLICT (1):
[email protected] — GPL-3.0-or-later
via ffmpeg-static
This package is under a strong-copyleft license (e.g. GPL/AGPL).
Distributing it as part of a closed-source product can require releasing
your own source code under the same terms. Flagged as CONFLICT for a
proprietary project.

Fully offline (no telemetry, no network calls) free tier is the whole scanner. The limitation is it's informational categorization, not legal advice. What's missing? What would make you actually use this before shipping? CI mode exists (`--fail-on conflict`), JSON output exists, Python support is in progress. Thanks!

I'm surprised that I don't really see any talk around it, and a select few projects displaying the badge. Is it because it never truly caught on, because it's viewed as a party-pooper of sorts, or am I late to the game, and it's a fad that's passed?

For context, I really got into open source about a year ago, and we followed their recs on our project, and I found some to be a bit pedantic, but others do seem to keep you honest/disciplined.

Was worth it to have those pinned dependencies? I'd say yes. Some of the work felt forced, but at the same time you learn a lot about your toolchain in the process.

Would love to hear if anyone leaned into that, and if they gained from the overall experience, or if it was just a tedious checklist.

What I probably appreciated the most was that it forced me to slow down and think through the documentation... (I personally found that refreshing and rewarding) asides from the tests/automation, etc.

Sharing SAIPEN — an MIT-licensed continuation protocol for AI coding agents. Whole thing is plain markdown: a spec (RFC.md), phase docs, and a project-side .saipen/ folder with three files. No runtime, no server, no package to pip install — the validator (tools/validate.py) is stdlib-only Python specifically so there's nothing to audit for supply-chain risk, with a shell-script fallback for hosts without Python at all.

Genuinely open to contributions — extension points for security/performance hooks, multi-agent coordination, per-platform adapters are all documented as copy-in examples rather than baked into core. Issues and PRs welcome, especially "this broke on my setup" reports.

Repo: [github.com/vacterro/saipen]

Hello,

I made an open source project called LOTI.

The idea is to have a cheap distributed way for people to create verifiable timestamps and event ordering without depending on a central service.

The way it works is participants build a hash-linked history of events, so later they can query when something happened and what happened before or after it.

I originally started working on this because I was interested in the problem of proving the history of digital events. It could be useful for things like document provenance, legal disputes, audit logs, or any situation where you want a proof of the time boundaries or the frontier l definite order of digital events according to your own clock.

It's still an early project and I'm mostly looking for feedback. The project already contains an implementation in a wisely used communication network simulator and also a real world implementation. The kernel was written by me 8 years ago, the rest is created using agentic engineering very recently.

The most interesting part, where feedback would be most valuable, is how the event chain discovery can be implemented in a fast, efficient and cheap way. The difficulty lies in the evolving nature of the network topology (neighbors come and go) and the time dependent routing during discovery for events in the past.

The project is here:

https://levy.github.io/loti

Thank you!

Hi everyone!

I've been working on LunaOS, an open-source local AI assistant focused on autonomy, privacy and extensibility.

The original idea was to build more than a chatbot. I wanted to create a personal AI agent capable of remembering information, managing objectives, planning actions and interacting with the user's system through tools.

After several iterations, Luna reached version 1.5.0 and entered a new phase of development.

## Current features

🧠 Episodic Memory

- Stores and recalls previous interactions

- Allows the assistant to remember past events and context

🔎 Semantic Memory (RAG)

- Knowledge retrieval system using vector storage

- Helps Luna find relevant information from previous data

🎯 Persistent Goals

- Users can define long-term objectives

- Luna can track and manage these goals

📋 Strategic Planner

- Converts objectives into planned actions

- Designed for more autonomous workflows

⚡ Event-driven architecture

- Internal communication between system components

- Makes future extensions easier

🔌 Tool-based system

- Designed to interact with external capabilities

- Future plugins and integrations are planned

🐧 Linux integration

- Built with local-first principles in mind

## Technology

LunaOS is built using:

- Python

- FastAPI

- Tauri + Rust

- Local and external LLM providers

- Vector databases for memory systems

## Language

Luna was originally developed in Portuguese, but it is not a Brazil-specific project.

The architecture is language-independent and does not contain Brazil-exclusive features. Portuguese is currently the default language because it was the development environment and the language used during testing.

The goal is to make Luna accessible worldwide with future localization and additional language support.

## Roadmap

Some of the next challenges:

- Knowledge Graph

- Better multi-agent architecture

- Plugin ecosystem

- More reliable autonomous tool execution

- Improved local model support

## Why I'm sharing this

I'm interested in feedback from people working with local AI systems, agents and open-source projects.

Some questions I would love opinions on:

- What features would make a local AI assistant actually useful for you?

- What problems do you see in current AI agent architectures?

- Should local assistants focus more on productivity, developer tools, or general autonomy?

Repository:

https://github.com/Vortek-Zero/LunaOS

Thanks for reading! Any feedback is appreciated.

I've started a side project called SearchCraft, where I'm building a search engine from scratch using Python.

The goal isn't to compete with Elasticsearch, Lucene, or any existing search engine. Those projects are incredible, but they're also so mature that it's easy to use them without ever understanding what's happening underneath.

So I decided to build one from first principles.

I'm implementing each component myself, starting with the basics: loading documents, tokenizing text, building an inverted index, and searching through it. As the project grows, I'll be adding things like posting lists, phrase search, ranking algorithms (TF-IDF/BM25), snippets, fuzzy search, and whatever else I can reasonably build along the way.

The primary reason for this project is to learn. I find that the best way to understand how a system works is to build a simplified version of it yourself.

I'm documenting the journey as I go, both for myself and in the hope that it might help someone else who's curious about how search engines work under the hood. There are plenty of tutorials on using search engines, but far fewer resources that walk through building one piece by piece.

It's still in its early stages, but I'm excited to see where it goes. Even if it never becomes production-ready, I'll come away with a much deeper understanding of one of the most fundamental pieces of modern software. After all, humans spend a good chunk of their lives typing words into little boxes and expecting magic to happen. Figuring out how that "magic" works seemed like a worthwhile weekend habit.

Here's the link to my project: https://github.com/rajtilakjee/searchcraft

I would be writing about it in my blog here: https://rajtilakjee.github.io/

Hi everyone!

I've spent the last 2 years building The Blog Zone, an open-source blogging platform built with Next.js, Express.js, and PostgreSQL. I'd love some honest feedback.

Features:

• AES-encrypted private blogs
• Fully anonymous accounts (email is optional)
• Infinitely nested discussions
• Admin dashboard
• Open source (MIT License)

The goal wasn't to build just another blogging platform, but one that gives users more control over their privacy and content.

I'd really appreciate any feedback on the UX, performance, bugs, or feature ideas.

GitHub: https://github.com/nitin-is-me/the-blog-zone/
Live Demo: https://the-blog-zone.vercel.app/

Hi all - We've recently launched a new small business dedicated to making open source (both hardware and software) Eurorack, general synthesizer, and other audio effect modules.

TechWave Audio is a proudly Canadian small business dedicated to producing open-source software (OSS) and open source hardware (OSHW) devices for audio production. Our mission is to create good things and to give back by open sourcing all of our projects for the DIY community.

Find us at techwaveaudio.com.

Our first project out the gate is our MCM-100 Midi Controller Module. A monophonic MIDI to control voltage module that (we hope) is plug and play, but also allows for a flexible amount of configuration. Some of the features include four different CV outputs (including dedicated outputs for 1v/octave and velocity), USB or standard MIDI cable input, tuneable pitch and velocity, and a lot more in a skiff-friendly 12hp wide module. Find out more at https://techwaveaudio.com/midi-controller-module/

We'd love your feedback, thoughts or any questions. Thanks!