TLS terminates at your CDN, load balancer, or WAF. After that point, request and response bodies are plaintexts. Cloudflare, AWS ALB, GCP -- they can all read your API payloads. For most production APIs, this is the reality.
hpke-http adds RFC 9180 HPKE encryption on top of TLS. It's a drop-in middleware for FastAPI (server) and aiohttp/httpx (client). Zero application code changes:
That's it. Your existing routes, request.json(), return values -- all unchanged. Bodies are encrypted end-to-end between client and origin server.
What it does: encrypts/decrypts request and response bodies using X25519 + HKDF-SHA256 + ChaCha20-Poly1305. PSK mode binds each request to an API key. Counter-based nonces prevent replay attacks. SSE streaming and file uploads work with O(chunk_size) memory. Optional zstd compression before encryption.
What it does NOT do: encrypt URLs, headers, query params, or status codes. Those remain visible to intermediaries. This is not a replacement for TLS -- it's a layer on top.
Cipher suite is a single opinionated choice (no algorithm negotiation), validated against official CFRG test vectors and Wycheproof. 10K lines of library, 14K lines of tests including property-based fuzzing and statistical randomness verification.
We looked for an open-source, standards-based HTTP body encryption middleware and couldn't find one, so we built it. Apache-2.0.
I built exec-sandbox because I wanted VM-level isolation for AI-generated code on my Mac without running Linux in a VM first.
Most sandboxes (E2B, Hopx) use https://firecracker-microvm.github.io/, on macOS, you need nested virtualization. exec-sandbox uses QEMU with Apple's Hypervisor.framework (HVF) and runs natively on macOS, including Apple Silicon.
What makes it different:
- Native macOS + Linux, no Docker, no nested VMs, just brew install qemu
- 1-2ms warm start, pre-started VM pool beats E2B's 150ms cold start
- Port forwarding without network, expose localhost:8080 while blocking all outbound (DNS + IP)
- Domain allowlisting, allowed_domains=["api.github.com"] for granular control
- CLI for automation, sbx run *.py -j 10 --json with concurrency control
- Package validation, blocks typosquatting against PyPI/npm top 10k
- Self-hosted, no session limits, unlike E2B's 24-hour cap
NATS is a fantastic piece of software. But doc’s unpractical and half backed. That’s a shame to be required to retro engineer the software from GitHub to know the auth schemes.
Project creator there. The biggest challenge in marketing this project to potential customers is not the fact that it does not work well, but the unions and human problems. It really marked me.
Indeed. I’m the project creator. That’s standard legal notice we must add to these kind of “large” repos. If not a dev team should maintain it full time with security incidents response managed within a SLA, which is not the case there. The same project is working in production for a few customers.
Probably related to AWS outage. Are they infra not reliable enough? Do you think this kind of critical communication service should be deployed cross-provider?
I built this after getting frustrated switching between AI platforms and losing
conversation context. It analyzes your ChatGPT/Claude exports and creates
markdown files with comprehensive context that you can paste into any AI to
continue exactly where you left off.
Key features:
- Extracts your actual implementation status vs what was just discussed
- Tracks decision journeys and what you've already ruled out
- Groups ChatGPT Project conversations into organized folders
- Smart caching saves API calls on re-runs (100% cache hit rate after first run)
- Works with any AI - paste the context into ChatGPT, Claude, Gemini, etc.
The context extraction goes way beyond simple summaries. It identifies critical
unknowns, user expertise level, what's blocking you, and provides specific
continuation advice for the next AI.
Perfect for when you want to switch from ChatGPT to Claude mid-project, or resume
an old conversation months later with full context intact.
Built with Python + Claude API, requires your conversation exports from
ChatGPT/Claude settings.
My primary objective is to build a LLM chat tool based on open-source documentations. The project owner (and even more if it is OSS) is I think not responsible for that, the one using it is.
You are welcome to push a PR to add other backends (including OSS)!
I’m developing that in my free time because I think there is a need inside the community for that. I’m not motivated in any way by my company.
In the meantime, if you have other technologies achieving the features (blob, queue, search), feel free to push a PR. Someone already did that for AWS: https://github.com/clemlesne/scrape-it-now/issues/8.
Well it solve basics problems like queuing and blob storage. For example, to achieve the same features as Queue Storage, you should use RabbitMQ or similar: in enterprise environment, it means multiple instances in high availability, maintenance, people to deploy it reproductibly…
Private GPT is a local version of ChatGPT, using Azure OpenAI. It is an enterprise grade platform to deploy a ChatGPT-like interface for your employees.
hpke-http adds RFC 9180 HPKE encryption on top of TLS. It's a drop-in middleware for FastAPI (server) and aiohttp/httpx (client). Zero application code changes:
That's it. Your existing routes, request.json(), return values -- all unchanged. Bodies are encrypted end-to-end between client and origin server.
What it does: encrypts/decrypts request and response bodies using X25519 + HKDF-SHA256 + ChaCha20-Poly1305. PSK mode binds each request to an API key. Counter-based nonces prevent replay attacks. SSE streaming and file uploads work with O(chunk_size) memory. Optional zstd compression before encryption.
What it does NOT do: encrypt URLs, headers, query params, or status codes. Those remain visible to intermediaries. This is not a replacement for TLS -- it's a layer on top.
Cipher suite is a single opinionated choice (no algorithm negotiation), validated against official CFRG test vectors and Wycheproof. 10K lines of library, 14K lines of tests including property-based fuzzing and statistical randomness verification.
We looked for an open-source, standards-based HTTP body encryption middleware and couldn't find one, so we built it. Apache-2.0.
https://github.com/dualeai/hpke-http