RequestHunt is a community-driven platform that collects and curates feature requests from X (Twitter), Reddit, and GitHub. We help product teams discover what features real users are asking for, making it easier to validate product ideas and prioritize feature development based on actual user demand.

How does RequestHunt collect feature requests?

RequestHunt uses AI-powered extraction to automatically collect feature requests from social media platforms including X, Reddit, and GitHub. The platform monitors discussions, issues, and posts to identify genuine user feature requests, extracting key information like the requested feature, product mentioned, and user sentiment.

Who uses RequestHunt?

RequestHunt is used by product managers, founders, developers, and product teams who want to discover what features real users are requesting. It's particularly valuable for startups looking to validate ideas, established companies prioritizing their roadmap, and developers building products that solve real user problems.

Is RequestHunt free to use?

Yes, browsing and searching feature requests on RequestHunt is completely free. We also offer API access for developers who want to integrate feature request data into their own applications. Check our pricing page for API plan details.

How often is RequestHunt data updated?

RequestHunt continuously collects feature requests from Reddit, X (Twitter), GitHub, YouTube, LinkedIn, and Amazon. You can also trigger on-demand scraping via the API or web interface to get the freshest data for any topic.

[protocol] Implement collaborative threshold CA for mesh

Design and implement a collaborative threshold CA for mesh via DKG + ZKP to address the single point of trust issue with CA private keys, ensuring genesis-managed CA lifecycle (key generation, storage, signing, rotation) and delegation of `launch mesh init` to genesis CLI.

Original Source

@@disentangle-network | 0 pts | 3/8/2026

## Problem `launch mesh init` generates the ML-DSA-87 CA private key as a flat file on the operator's local disk. Single point of trust, architecturally inconsistent with the decentralized design. The CA key holder can mint arbitrary mesh identities. ## Requirements ### Core: genesis-managed CA lifecycle - Genesis manages CA key generation, storage (envelope-encrypted), signing, rotation - Raw CA private key never leaves genesis's trust boundary - `launch mesh init` delegates to genesis CLI instead of running `nebula-cert` directly - `launch mesh add` requests cert signing from genesis (signing happens internally) ### Target: threshold CA via Distributed Key Generation (DKG) - Multiple genesis instances across clusters collaboratively generate a threshold CA key - No single genesis instance ever holds the complete CA private key - k-of-n genesis instances must cooperate to sign a node certificate - Each partial signing verified via zero-knowledge proof (correct key share usage with

Discussion

Loading comments...