eIDAS 2.0 forces EU relying parties to accept EU Digital Identity Wallet logins (OID4VP) by January 2027, and developers are now asking for it in the tools they actually run. Keycloak, the default self-hosted identity server, has no native support, and the alternatives are enterprise identity platforms. The opening is a Clerk/Auth0-style, low-friction 'accept an EU wallet credential' drop-in for small teams.
builder note
Do not try to out-walt.id on the full credential lifecycle. The wedge is purely the verifier/relying-party side ('accept an EU wallet login') packaged for people who currently use Clerk/Auth0/Keycloak, with the regulatory deadline as your built-in urgency.
landscape (3 existing solutions)
The protocol layer exists and the big vendors sell it, but everything is pitched at banks and governments. The gap is a cheap, maintained, indie-friendly verifier (especially a first-class Keycloak path) so a two-person EU SaaS can become wallet-ready before the 2027 deadline without buying an identity platform.
walt.id Community Stack / SDK Full OID4VP/OID4VCI SDK, but it is an infrastructure stack you adopt and operate, aimed at organizations, not a five-minute 'add a login button' for a side project. sources (1)
eidas2eudi-walletoid4vpidentitykeycloak
Volkswagen hardened its WeConnect/Connect API with client assertion, cryptographic proof that a request came from the official, reviewed app on a non-rooted phone, which broke the popular open-source Home Assistant integration owners used to read charge state, climate, and location and to automate cabin preconditioning. People who already pay roughly 100 dollars a year for WeConnect want programmatic access to their own car and are openly weighing a brand switch. The ask is a maintained, cross-brand (VW, Skoda, Seat, Cupra) bridge that keeps working as VW, in their words, keeps tightening the screws.
builder note
Do not sell a 'permanent' fix, because attestation will eventually win on the native-app path and a fire-and-forget HACS add-on will be dead within a quarter. The durable wedge is a hosted, fast-updating relay across all VW-group brands funded by a small subscription (which also pays for the cat-and-mouse), with an honest public changelog every time VW breaks it. The willingness to switch brands over this is the real signal of how much owners value local control.
landscape (3 existing solutions)
The open VW integrations are caught in an authentication arms race. Browser login via TLS fingerprinting still works today, but VW is signalling it will keep clamping down with full client attestation, so every community fix is provisional and there is no sanctioned local API to build on.
homeassistant-volkswagencarnet (robinostlund) The de facto community integration. Authentication keeps breaking against VW's changes (issues #924, #744) and it depends on the WeConnect-python library that is being retired this year. Each fix is temporary. CarConnectivity (WeConnect-python successor) The multi-brand rebuild (VW/Skoda/Seat/Cupra) that replaces the dying library. It restores functionality for now but is subject to the exact same attestation arms race, so it does not solve the durability problem. Official VW / WeConnect app + subscription The only sanctioned client and it works, but it is a closed phone app with no open or local API. Owners cannot automate against it from Home Assistant, which is the entire point. sources (1)
home-assistantevvolkswagenapi-lockoutsmart-home
Browser-controlling AI agents need long-lived sticky sessions that hold for several minutes and load hundreds of MB of content. They're being forced onto residential proxy services priced per-GB for short scrape jobs, where the proxy bill rivals the LLM token bill. The access pattern is fundamentally different from scraping but no proxy provider has packaged for it yet.
builder note
Don't build another residential pool. License capacity from existing pools and resell with sessions-based pricing and agent-aware features (auto-rotate-on-block, captcha-solving credits bundled, per-session debug recording). The arbitrage is the pricing model, not the IPs.
landscape (4 existing solutions)
The proxy industry monetizes scraping. Agent traffic looks like a fast-growing customer with the wrong-shaped pricing. A sessions-based plan (priced per concurrent sticky session per minute, not per GB) would land instantly with browser-agent builders.
sources (1)
proxiesbrowser-agentsai-agentsinfrastructurepricing
Five years after UnifiedPush launched, only about 20 apps support it and Android still has no native mechanism for custom notification servers. Users on HN and privacy forums explicitly wish Android supported specifying self-hosted notification servers. ntfy works well as infrastructure but the ecosystem adoption is stuck because app developers have no incentive to support an alternative protocol when Firebase is free and easy.
builder note
Don't build another push server. Build the adoption layer. A drop-in Android library that detects UnifiedPush distributors and falls back to Firebase transparently would let app developers support both with zero effort. The bottleneck is developer friction, not infrastructure.
landscape (3 existing solutions)
The infrastructure works (ntfy is solid). The protocol exists (UnifiedPush). What's missing is the adoption flywheel. App developers won't support UP without users demanding it, and users can't demand it without apps supporting it. A library that makes UP integration a one-line addition to Android apps could break this chicken-and-egg problem.
ntfy Excellent self-hosted notification server but requires manual setup and each app must explicitly integrate it UnifiedPush Good protocol standard but only ~20 apps support it after 5 years. No mainstream app adoption. NextPush Clever Nextcloud integration for self-hosted push but requires Nextcloud, limiting audience sources (3)
push-notificationsdegoogleandroidprivacyunifiedpush
Self-hosting email in 2026 is still described as pain despite Mailcow and Mail-in-a-Box automating the technical setup. The unsolved problem is deliverability: new IPs start with zero reputation, major providers penalize inactivity, and self-hosters lack the postmaster relationships that professional services maintain. Multiple 2026 articles confirm that email deliverability is no longer a technical problem but a reputation and relationship problem that no self-hosted tool addresses.
builder note
Don't build another mail server. Build the deliverability layer that wraps around existing servers. Think of it as a reputation management sidecar for Mailcow/MiaB that handles IP warming, blocklist monitoring, postmaster request automation, and sender score dashboards. That's the product nobody is making.
landscape (3 existing solutions)
Every self-hosted email solution solves the same problem (setting up Postfix/Dovecot correctly) while ignoring the actual hard problem (IP reputation management). The tool that automates IP warming schedules, monitors blocklists proactively, and provides deliverability dashboards for low-volume senders doesn't exist.
Mail-in-a-Box Automates DNS/SPF/DKIM setup perfectly but does nothing for IP warming, reputation monitoring, or blocklist management Mailcow More configurable than MiaB with Rspamd spam filtering but still no automated reputation management or deliverability monitoring Stalwart Mail Server Modern Rust-based server with excellent protocol support but same deliverability blind spot as all self-hosted options sources (3)
self-hosted-emaildeliverabilityreputationprivacyanti-surveillance