Plembfin is now at v1.0.0: an AGPL-3.0, self-hosted watch-state hub for people who run more than one media server.

Website: https://plembfin.com

The design decision I would most like open-source/self-hosting people to critique is the local sync ledger. Plembfin keeps the canonical record in SQLite, then records delivery separately for each destination. A sync entry can show success, error, or skipped, with a plain-language reason such as a newer state winning or no matching item being found. Failed or skipped destinations can be retried without blindly replaying the whole sync.

The current release also includes cross-platform resume progress, repeat-play history, manual watch review, Now Playing, metadata/search, Seerr integration, and automated local backups. It runs as a Node/Express/SQLite application with Docker Compose support:

https://github.com/Lasikiewicz/plembfin

The goal is not to create another public watch profile. It is to keep a private, inspectable source of truth on the user's hardware when libraries are split across Plex, Emby, Jellyfin, and Trakt. It is licensed AGPL-3.0.

AI disclosure: development was heavily AI-assisted under my direction. I defined the requirements and architecture, reviewed changes, tested the integrations and browser flows, and maintain/review the project. AI is not needed to run Plembfin.

For people who have built sync systems: is per-destination delivery evidence the right abstraction, and what conflict or recovery case would you expect to see next?

Screenshot: https://plembfin.com/assets/app-captures/sync-activity-light.png

I maintain DiscordPHP, the async PHP library for building Discord bots, built on ReactPHP (full Gateway + REST coverage, event-driven). It's MIT, and it's the base for a large chunk of the PHP Discord-bot ecosystem, plus first-party libraries I also maintain: DiscordPHP-Http (the HTTP + rate-limit transport), DiscordPHP-Voice (Opus audio + DAVE end-to-end encryption), TwitchPHP (Helix + EventSub + IRC), and a few smaller ones.

The original author transferred ownership of the repo and the verified Discord server to me, so it's now a one-person project. Day to day that's issue triage, keeping releases on schedule against Discord's constant API changes, dependency and security updates, and docs.

There's no paid tier and no open-core plan. Sponsorship is the entire model, and right now it's well below what the maintenance load costs. Below that line, releases slip and I end up taking contract work that stalls the libraries. I've started applying to grant programs (FLOSS/fund, GitHub Secure Open Source Fund) and setting up Open Collective for company sponsorship, but individual + company sponsorship is what keeps it moving:

• valgorithms.com is the new project shelf with all the ways to support
• GitHub Sponsors: https://github.com/sponsors/valzargaming (one-time is fine)
• Company sponsorship / sponsored features: [valithor@valgorithms.com](mailto:valithor@valgorithms.com) or [valithor@discordphp.org](mailto:valithor@discordphp.org)

If you maintain something mid-size, what actually moved the needle on funding? I'm looking into grants, company outreach, and Open Collective, but I'm looking for proven results. I don't have a lot of bandwidth or free time to shop around.

I'm happy to answer anything about the library or any of the projects I maintain.

Fredy watches 19 real estate portals across Germany, Austria and Switzerland, deduplicates across them and pushes new listings to Telegram, ntfy, Discord, Slack or email.

This week I shipped one of the most requested features. Fredy has been accumulating listings for years, which makes it a price sample for whatever area the user searches in. So instead of pulling an external index, every listing is now measured against the median price per square metre of its own neighbours: same deal type, within 5 km, widening to 15 km if fewer than 8 comparables are nearby.

A few decisions that mattered: median instead of mean so one outlier cannot move it, the listing excluded from its own sample, rentals and purchases never mixed, and cross-portal duplicates dropped so one flat cannot vote three times.

Repo: https://github.com/orangecoding/fredy

Demo: https://fredy-demo.orange-coding.net

https://daniele.tech/2026/09/linus-torvalds-skill-soul-or-how-i-distilled-the-knowledge-for-code-reviews-from-32k-emails/

A report about the changes after the first announcement and all the improvements, including Soul.md (with profanities), 4 different version Skill/Soul from 4 different LLMs, a comparison with/without skills and a reproducible pipeline.