Creators and multilingual organizations on PeerTube -- the federated, self-hostable YouTube alternative -- want selectable alternate audio tracks (e.g. dubbed languages) on a single video instead of uploading one copy per language. PeerTube supports multiple subtitle tracks but only one audio track, so today people duplicate uploads, wasting storage and splitting their view counts, comments, and audience. The long-open request is still drawing fresh interest from multilingual companies, filmmakers, and screen-reader users.
builder note Frame it as 'one upload, many languages' for dubbed and multilingual channels, not a generic player tweak; the duplicate-upload pain (storage plus split audience) is the real wedge, and since HLS already supports multiple audio renditions the hard part is the transcoding pipeline and a clean track-picker in the player, not the spec.
landscape (3 existing solutions)
Multilingual and dubbed-content channels on the federated, self-hostable YouTube alternative have no way to attach selectable audio tracks; HLS already carries multiple audio renditions, so the gap is PeerTube's transcoding pipeline and player UI, not a fundamental limitation.
PeerTube (current) Supports multiple subtitle/caption tracks but only a single audio track per video; the feature request (#939) is still open and unimplemented after years of demand. Duplicate-upload workaround Uploading one video per language wastes storage on the instance and fragments view counts, comments, and the audience across copies. YouTube multi-language audio The incumbent already offers selectable dubbed audio tracks, setting an expectation PeerTube can't meet -- a concrete reason multilingual creators stay on YouTube. sources (1)
peertubefediversevideoi18naccessibility
A self-hoster with ~30k photos in Immich wants to auto-surface the best shots from each trip/event to print albums, and the thread agrees nothing Immich-native/self-hosted does it. Immich browses, tags, face-recognizes, and de-dupes but does not hand back a best-in-album shortlist; PhotoPrism has automatic quality scoring, but it is a separate library and review queue rather than an Immich-integrated culling workflow. The gap is a local, Immich-integrated tool that groups near-duplicates, scores sharpness and eyes-open shots, and hands back the keepers.
builder note Resist building a general 'photo organizer' -- the entire job is one opinionated verb, 'pick the keepers from this trip,' so an Immich plugin/sidecar that groups near-dupes and scores sharpness/eyes-open and returns a shortlist beats a feature-sprawl app; on-device vision models make this a local-first feature, not a cloud one.
landscape (4 existing solutions)
Culling is partially solved in standalone photo managers and pro desktop workflows, but not for Immich-centered self-hosters who want a local service to score a trip or album in place and return a keeper shortlist.
Immich Does browsing, face recognition, semantic search, and duplicate detection, but does not rank or cull for 'best shot' within a burst, trip, or album. PhotoPrism Creates an automatic 1-5 quality score and review queue, but it is a separate photo library and low-quality review mechanism, not an Immich-sidecar workflow that selects best shots from a specific event and writes a shortlist back to Immich. czkawka Finds near-duplicates by hashing, which thins bursts, but doesn't judge quality (sharpness, eyes-open, composition) to pick the keeper. Aftershoot / Imagen Dedicated pro culling tools; Aftershoot runs locally/offline, but the workflow is still desktop/pro-shoot oriented and subscription-based, with no self-hosted service that plugs into an Immich library. sources (1)
self-hostedimmichphotoscullinglocal-ai
Self-hosters leaving GitHub want a lightweight forge they can run on a small VPS, but AI scrapers crawl every file, git-blame view, and per-commit archive and exhaust the server. Forgejo/Gitea aren't resilient by default -- operators must require sign-in for all access or front the forge with a separate anti-bot layer like Anubis or Iocaine. The unmet need is a forge that's scrape-resistant by default, without the ops burden of running and tuning extra infrastructure.
builder note The wedge is zero-config scrape resistance baked into the forge -- sensible per-route rate limits, archive/blame throttling, and bot heuristics on by default -- not 'go install Anubis'; the people asking are small self-hosters who will not stand up and tune a second reverse proxy just to publish a few public repos.
landscape (2 existing solutions)
There's no self-hosted forge that is simultaneously lightweight and scrape-resistant out of the box; today resilience means running and maintaining Anubis/Iocaine in front, which is the ops overhead that pushes hobbyist self-hosters away in the first place.
Forgejo / Gitea Lightweight forges, but not scrape-resistant: bots crawl every file, blame view, and commit archive and exhaust small-VPS resources, so maintainers must require sign-in or add a separate proxy. Anubis / Iocaine The de-facto fixes, but they're separate reverse-proxy / tarpit layers an operator has to deploy and tune -- exactly the extra moving part small self-hosters are trying to avoid. sources (1)
self-hostedgit-forgeai-scrapersforgejoanti-bot
Self-hosters running local RAG standardize on Ollama for LLM and embedding serving, then hit a wall: Ollama has no reranking endpoint, so pipelines must spin up a separate inference server (HuggingFace TEI, Infinity, or llama.cpp) just for the cross-encoder rerank step. The two-year-old request is one of Ollama's most-reacted issues and is still hot -- users are publishing hacky workarounds in June 2026 because it's 'not currently supported.' A native rerank endpoint would let an all-Ollama local-RAG stack run on one binary.
builder note The build isn't a model, it's the missing /rerank endpoint and library entries so Open WebUI / LangChain pipelines 'just work' against one Ollama; whoever lands the cross-encoder serving path (or a clean Ollama-compatible sidecar) inherits two years of pent-up local-RAG demand.
landscape (2 existing solutions)
Local-RAG builders standardize on Ollama for LLM + embeddings, then have to bolt on a separate reranker server; a native Ollama rerank endpoint plus model-library entries would close the last gap in an all-Ollama pipeline.
llama.cpp rerank endpoint Exposes a /rerank route for cross-encoders, but Ollama (built on llama.cpp) has not surfaced reranking through its own API or model library. HuggingFace TEI / Infinity / vLLM Can serve cross-encoder rerankers well, but running one means standing up and maintaining a second inference server next to Ollama, defeating its single-binary, local-first appeal. sources (1)
local-airagollamarerankingself-hosted
GrapheneOS and other de-Googled Android users want to record phone and VoIP calls, but every option forces a security compromise: BCR needs root (impossible with a locked bootloader), accessibility-service recorders demand a permanent broad permission and capture mic-only, and the built-in dialer records cellular calls only. They want an open-source recorder that captures VoIP (Signal/WhatsApp) and Bluetooth-headset calls without rooting or holding an accessibility permission forever. A fresh, multi-user Privacy Guides thread confirms no good solution exists.
builder note Don't ship another accessibility-service recorder -- this audience runs GrapheneOS precisely to avoid broad permissions; the wedge is a Shizuku/ADB-privileged capture that grabs VoIP and Bluetooth audio without root or an always-on a11y service, and being open-source is the price of entry, not a nice-to-have.
landscape (3 existing solutions)
Every working path on a locked-down GrapheneOS device forces a bad trade -- root, a permanent accessibility permission, or a proprietary app -- and none cleanly records VoIP or Bluetooth calls, which is precisely the combination users keep asking for.
BCR (Basic Call Recorder) FOSS and high-quality, but its own description reads 'for rooted Android devices'; locked-bootloader GrapheneOS users who keep verified boot cannot use it. Cube ACR Proprietary and closed-source, relies on an always-on accessibility service, and is exactly the kind of opaque app this privacy-focused audience is trying to avoid. GrapheneOS Dialer + OS-issue-tracker #7205 Built-in recording covers only cellular/SIM calls, not VoIP or Bluetooth-headset audio; the open OS-level feature request to improve this (#7205, last activity 2026-05-13) is still unresolved. sources (1)
privacygrapheneoscall-recordingfossandroid