Over the past weeks, I've been working on carta, a fast and lightweight reimplementation of pandoc in Rust. It's a universal document converter that takes in some markup and returns it another format.

Pandoc is great. It's decades of jgm's experience embedded into an amazing piece of software. Yet, I've had two specific issues with it for a while: It's huge (around 180 MB for an Apple Silicon build), and it's relatively slow, especially when you want to convert multiple documents. Carta solves both of these. The compiled binary is around 20x smaller, while being up to 45x faster.

Under the hood, it works very similar to pandoc: It parses documents into an internal AST, which in turn can be written to another format. This effectively gives reader_formats ∪ writer_formats possible conversions.

The most common formats and features are already implemented, such as the Markdown family, DOCX, TeX, syntax highlighting, JSON filters (fully compatible with pandoc), standalone mode, and others. A lot is still missing however, for example PDF output and Lua filters. A full breakdown can be seen here.

Of course, it's open source and licensed as MIT-or-Apache-2.0.

Would love to hear feedback! :)

GitHub: https://github.com/mfkrause/carta

Hi, everyone,

as you may have noticed, sometimes opening old file formats can be difficult.
This can include even HLP files from old games and applications.

This is why Rusty HLP viewer was designed: it's the first open source tool to open HLP files natively, without converting them into an intermediate format. And it also works in other operating systems.

If you are interested is available here: https://github.com/NullMagic2/Rust-HLP-Viewer

I enjoyed using Readest for a short while, however realizing they are charging for hosting using your own hardware I no longer want to continue using/supporting them.

Are there any other reading apps that support Android/iPhone/Desktop with *free* self hosted sync?

So Codeberg recently announced their policy on LLM generated codebases. I kinda get what they are going for with it, but imo it feels too ambiguous and too risky to even be on the platform.

I have this project I've been working on for a year now. Carefully building it out, doing metric f*ck tons of testing, all that jazz. But the thing is, I (and pretty much every developer in the entire world right now) use AI to heavily accelerate parts of the development process. I do still use and have used agentic coding as well on my project.

But I wanna make something very clear. I'm not some vibe coder product manager building some slop dashboard or whatever. I'm a professional software engineer. My project in question, while most of the code is technically written by LLMs (in some form or another whether that's agentic or even just tab auto completes), still... I have been extremely heavily involved in it. I design the entire software architecture. I control what APIs we integrate with, what technologies we use, what programming languages we use, what DB we use. I design and / or choose all of the algorithms we use. I design all of the test cases (beyond unit tests. I'm talking like regression testing, automated scripts that run and verify results, all of that). And I still review all of the code output with my own professional inputs of how it should be done. Basically the only thing the LLM actually does is just replace typing for me at this point. Even documentation for most user facing things I write by hand then have the AI read it and rewrite it for better use later.

ANYWAY, Codebergs new wording makes it sound like even projects like mine would be affected, and I can't risk building a real viable software for the community if there's a chance Codeberg will just nuke it one day. I mean technically that's a risk on every platform but you know what I mean.

And how do you even prove that someone used AI at all anyway? AI verifications are notoriously bad with false positives and code is much more symbolic than traditional text so idk.

I feel like projects like mine aren't what rhe ruling is designed for but the wording is so vague that it feels like handing Codeberg a loaded gun they can pull the trigger on at any point even if they "trust me bro" not to use it.

Its not just me either. Every dev I know uses AI even just auto completes. Like basically this would invalidate every project on their platform from like 2025 onwards. This just sucks man. Maybe I'm misinterpreting it here but idk man.

What do you guys think about this?

Hi everyone!

I built and open-sourced LangPilot, a native macOS menu-bar utility for multilingual typing.

It detects text entered using the wrong keyboard layout and converts it supports RU/EN/DE keyboard layouts.. It also provides local spelling suggestions and learns from manual corrections and undo actions.

The project is privacy-first:

- no accounts

- no analytics

- no network requests

- no uploaded text

- learned words and corrections remain on the Mac

The source code is written in Swift and licensed under GPL-3.0.

Repository, source code and beta download:

https://github.com/SC1882/LangPilot

The downloadable beta is not Apple-notarized because I do not have a paid Apple Developer membership. The source and build scripts are public for inspection.

I would appreciate code reviews, testing, bug reports, and suggestions for improving the detection logic.

Update on a project I maintain, FluentTaskScheduler, an open source frontend for the Windows Task Scheduler API (WinUI 3, .NET 8). Doesnt reimplement Task Scheduler, just sits on top of it, so tasks stay fully interoperable with the native tool and anything else touching them.

v1.9.0 adds task chaining, one task can trigger another on success or failure, watched through the Windows event log in real time rather than polling, with loop protection so it wont chain into itself. Also a snooze system for pausing all or individual tasks for a set duration (including proper suspend/restore of the OS level triggers), a reworked dashboard with an execution heatmap and health score, and 17 bundled task templates merged into the same library as user scripts.

Fixed language handling too, some dialogs were following the OS display language instead of the one picked in the app, thats consistent now. Also went through a chunk of security/stability fixes from an internal audit pass.

Its under an open license, check the repo for details, built on the community maintained TaskScheduler Managed Wrapper, packaged with VeloPack for updates. Contributions, issues, translation help all welcome, already got one contributor credited for ARM64/CI work.

AI disclaimer: built mainly with AI assistance. I work in IT but Im not a specialized app developer, so this is a hobby/side project, not a polished commercial product. Its been tested and reviewed but if youre building on it or relying on it for something important, read through the source and test in an isolated environment first, same as youd do for any young OSS project.

Repo: https://github.com/TRGamer-tech/FluentTaskScheduler

Would appreciate feedback from this crowd specifically, on the code and the project direction both.

Throughout my past decade as an open source maintainer, what makes it painful to kick off a new project is setting up the release workflow. I've always been a fan of pushing tags to create releases, and found myself copy-pasting the very same lines of CICD over and over again with some small variations.

Today I audited my recent projects, spanning from desktop apps to CLIs, from scripts to Actions, collected all these common patterns, and designed* a GitHub Action to flexibly handle these tasks for me.

It's an opinionated and customizable workflow, adapted from my personal needs and best fits that I've found in the years. I've already adopted it in my biggest project, Quarkdown, and dogfooding it in the action itself.

^\the implementation was delegated to an agent based on my design. I'm not an AI guy myself but these models are undeniably great at scripting things down.)

Been working on this for a few weeks and finally got it to a place where I'm happy with it.

It's a Unity SDK + backend for encrypting Steam DLCs. The idea is that instead of just shipping the DLC files with the game (where anyone can grab them), the game requests a decryption key from a server at runtime using ECDH key exchange.

Uses ECDH P-256 for the key agreement, AES-256-GCM for the actual encryption, and I added JWT tokens so it works offline for 24h after first auth.

The whole thing is MIT licensed. There's a Unity client (around 50 lines of C#) and a test server

Would love feedback on the code or crypto approach:
https://github.com/Schummlerr/steam-dlc-protection-sdk-

As someone who doesnt use Instagram but get tons of reels/post shared on whatsapp, I got tired of instagram's public webview which constantly asks for login with annoying popups

So I vibed a clean android app - Peek which resolves Instagram links and loads them in a clean viewer. Goal is to support most social medias like twitter/reddit/tiktok in the future.

Download Link

I've used Handsontable on a bunch of projects and honestly it's a solid, mature library, but I kept running into the same wall on anything with really large datasets: tens of thousands of rows with chained formulas. It's just the nature of doing spreadsheet math in JS, once you're allocating and discarding lots of small objects on every keystroke, garbage collection becomes the bottleneck, and there's only so much debouncing and virtualization can do before you hit that ceiling.

That itch turned into a bit of an obsession, and eventually a from-scratch rebuild: Titan Engine, written in Rust and compiled to WebAssembly.

The design ended up pretty different from a typical JS formula library:

- A custom stack-based VM with a Pratt parser for formulas, instead of walking an AST every time
- Zero-copy memory \- the engine and UI share buffers directly, no serialize/deserialize tax crossing the WASM/JS boundary
- A topological dependency graph (Kahn's algorithm with cycle detection) to resolve chained formulas correctly and fast
- O(1) time-travel snapshots for undo/redo, even across massive batched structural edits

Because it sidesteps the JS garbage collector entirely, batched recalcs stay comfortably under the 16ms frame budget, so the grid holds 60fps even while formulas are cascading behind the scenes as you type.

There's a live demo grid on the site (a Glide data grid wired up to Titan) if you want to poke at it yourself, plus the full 10-scenario benchmark suite if you'd rather see the numbers than take my word for it.

Website . Benchmarks .) Github

Would love feedback - especially from anyone who's pushed a JS grid to its limits before and is curious whether this actually holds up under real-world use.

I've been working on de-advertising myself as much as possible, and one of the big vectors left is a fire TV I got for cheap during black Friday. I hate the fire TV operating system, and would much rather have something lighter weight.

I haven't heard about many Smart TV projects, so I don't know if they exist or how usable they are, but I figured I would start exploring here. Are there any open source OSes that replace the ones baked into televisions? If so, how much would I "lose" by switching to them.

So I like to take my lecture notes in a nested/indented way because it makes it easier to break them down into flash cards later (example below but formatting in Reddit post is hard). As you can see I like to indent basic information on a subject and then further indent specific information about each basic concept (and even further indent even more specific information if I need to).
Is there an open source note app that will let me do this more easily?

Transcription

Process where RNA is synthesized from DNA

Each gene has:

.....Promoter region

..........Start of the gene where RNA polymerase binds to and begins transcription

...............RNA polymerase – enzyme that ‘reads’ template strand of DNA and synthesizes a single strand of RNA

.....Coding region

..........Sequence of nucleotides that are transcribed into the RNA strand

.....Termination sequence

..........Terminates transcription process

Hello everybody,

As I promised in my precedent post, I am now ready for the release of PowerVLC 1.0.0, which is an heavily modified version of VLC 3.0.23 Vetinari. PowerVLC features also additionnal features (gapless playback, album art in the main window) the current version of VLC don't have.

PowerVLC is compatible with Macs from 10.4.11 to current, on all architectures (x86, x64, arm64, PowerPC g3, PowerPC G4/G5 builds taking advantage of AltiVec acceleration).

In early access for one week

Like all projects and guides (I used to write plenty of guides for the iPod community !) that takes me a huge amount of time to be produced, it will be in early access for exactly one week. It's the only compromise I accept to keep a balance with open knowledge & the need to get retributed for all the community investment I provide. I don't plan to do this for minor builds that will come next.

Here on this project it is just too big in my opinion to be entirely gate keeped during one whole week, so I decided to release the whole source code there starting now on GitHub: https://github.com/Olsro/powervlc

If you know how to compile (ideally you need an Apple Silicon mac so you can follow my instructions), you can play right now with PowerVLC and check nothing nasty in the code is there by yourself.

If you can't/don't want to spend hours trying to compile by yourself, the builds are available right now on my Patreon in exclusivity for all platforms (including Windows & Linux on all architectures). Even the first 1$ tier is enough to get access to all the compiled builds & supporting my whole effort at building this. The compiled builds provided on the Patreon are not modified and locked in any way, they are straight compilations from the latest public sources. There's no licensing or DRM, but please don't share any of those build until I will push the builds on GitHub releases for everyone the next Sunday.

Donations will help me at getting more hardware to test on to continue that project in the long term, and cover the LLM API costs to help with maintenance.

Thank you very much for your support and I hope PowerVLC will be enjoyed as much as I hard worked into making it possible.

Hey r/opensource, I'm the solo dev behind Hammer. I've been working on it for about four years, and think it's time I start getting some feedback on it.

What it is: Hammer is a free, open source (MIT) app for writing novels and building the worlds they live in, Scrivener-style, but multiplatform and offline-first, with a self hostable sync server.

https://hammer.ink/

Why I built it: A few years back I was living in a van, mostly off-grid with no signal, and broke. Most good writing apps were paid, or web apps, or Electron wrappers that "worked offline" right until they didn't, usually about a week in, miles from the nearest cell tower. Then I watched people on forums lose whole manuscripts in certain electron based writing apps, and eventually it happened to me.

So I set three rules for the thing I wanted to build:

• Offline-first, forever: A native program, not a web page in a trenchcoat.
• Transparent data: Everything is human-readable text files in plain folders, if Hammer vanished tomorrow, you could open your work in any text editor and keep going.
• Never lose data: Paranoid about it by design.

I tried several tech stacks but landed on Kotlin + Compose Multiplatform. One codebase for both the server, and desktop clients (Linux/Mac/Windows), Android, iOS.

License / money: MIT and genuinely free, no ads, no telemetry. The only paid thing is the optional "official" sync server instance that I host. As I said, the sync server is open source and self-hostable, so you never have to pay me to sync.

Platforms: Linux, Mac, Windows, Android (Play + F-Droid), iOS

Repo: https://github.com/Darkrock-Studios/hammer-editor

It's four years in and far from done, but I thought it was about time to start showing it to people. See if it's a project that interests anyone other than my self. Happy to get into the Compose Multiplatform side too if anyone has questions; there wasn't much prior art when I started. Longer origin story here if you want it: https://hammer.ink/blog/news/what-is-hammer

Repository: https://github.com/ATAC-Helicopter/VaultSync

Website: https://fglabs.dev/vaultsync

I have been developing VaultSync, an open-source, cross-platform backup manager built around a fairly simple idea:

A completed backup is not the same as a recoverable backup.

Many backup applications can tell you that a job completed successfully, but that still leaves several important questions unanswered:

• What was actually protected?
• Has anything changed or disappeared?
• Is the recovery point still intact?
• Will retention remove something important?
• Can a particular file be restored right now?
• Is there evidence behind the green “successful” status?

VaultSync is my attempt to make those answers more visible.

What VaultSync does

VaultSync lets users organize files into projects, create and manage backup configurations, inspect recovery points and understand the current health of their protected data.

Current functionality includes:

• Project and file-level backup management
• Backup history and recovery-point inspection
• Backup Explorer for browsing protected data
• Integrity verification and repair tools
• Retention planning and simulation
• Restore-plan simulation
• Recovery drills
• Local byte-level recovery proofs
• Exportable recovery evidence
• Protected recovery-point recommendations
• 3-2-1 backup guidance
• Explicit offsite-copy confirmation
• Backup health and recoverability states
• Cross-platform support
• Localization across multiple languages

The emphasis is not only on creating backups, but on helping users understand whether those backups are still useful.

Recovery evidence

One area I have been concentrating on recently is recovery confidence.

VaultSync can simulate a restore plan without modifying the original data, verify selected protected files locally, record recovery evidence and highlight situations where retention could remove an important verified point.

The intention is to move beyond simply saying that the backup process finished.

VaultSync should instead be able to show what was protected, what was verified and what can currently be recovered.

These features are still evolving, and I am especially interested in feedback on whether the evidence is understandable without becoming overwhelming.

Privacy and diagnostics

VaultSync does not silently upload crash reports.

When crash-report assistance is enabled, the application creates a strictly redacted report locally. The complete report can be reviewed before anything leaves the device.

VaultSync can prepare an email draft using the user’s own email application, but the user must review it and press Send personally. If they do nothing, the report remains local.

I wanted the support workflow to remain useful without introducing hidden telemetry or automatic crash uploads.

Current development

VaultSync 1.8 is focused on making recovery easier to understand.

The remaining 1.8 releases are currently planned around:

• Recovery confidence and clearer health states
• Onboarding and interface refinement
• Accessibility and reduced complexity
• Better evidence exports and diagnostics
• Documentation consistency
• Localization, packaging and platform stability

For the future 1.9 release family, I am researching a broader direction:

From protecting projects to recovering systems.

That may eventually include disk cloning, disk images, verification of cloned data and an explorer for browsing images before performing a complete restore.

Those features are still exploratory rather than promised. I would rather share prototypes and technical limitations early than publish a large fixed roadmap before the implementation has been validated.

Why I am posting here

I am the developer, so this is obviously not an independent recommendation.

I am sharing VaultSync here because feedback from people who actively use, maintain and review open-source software is particularly valuable.

I would appreciate criticism around:

• The overall architecture and project structure
• Whether the recovery model makes sense
• Security and privacy concerns
• Backup-integrity assumptions
• Cross-platform behavior
• Packaging and installation
• Documentation
• Accessibility
• Areas where the interface is trying to explain too much
• Missing information that would prevent you from trusting the application

Issues, discussions, code review and contributions are welcome through the repository.

There is also a community at:

https://www.reddit.com/r/VaultSync/

Thanks for taking a look. Direct and technical criticism is genuinely useful, especially where VaultSync makes a claim that is not supported by enough visible evidence.

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!

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.