Hacker Newsnew | past | comments | ask | show | jobs | submit | punkpeye's commentslogin

So funny how no one picked up on this.

I was expecting this to be the first comment.


Indeed, there are more mature solutions. The primary reason I made Pipenet is because I needed something that can be embedded in Node.js client.

You might need to define 'fast'.

This should not add more latency than your average VPN, since the overhead of websocket is minimal and roundtrip time is about the same.

At the moment, this is running on a single-instance with no load-balancing. The intended use case was to enable streaming of MCP SSE traffic, which is very lightweight. I would expect this to be able to handle a lot of traffic just like that, but if people start using the public instance for other use cases, I will need to think of ways to scale it.


I am keeping one eye on how this is scaling.

At the moment there are 5 active tunnels and CPU is at 2%.

I would therefore expect that this can scale quite a bit before it becomes some sort of bottleneck.

Who knows though – maybe I am underestimating the demand. Didn't expect this to get to the front page of HN.


The overhead of encryption is huge, comparatively speaking.

Simply using 4096 bit RSA instead of 2048 is enough to cause a denial of service attack.


Just plain HTML/CSS.

I did this morning in a rush. Didn't expect anyone to compliment it. Thank you!


The current implementation is HTTP-focused as that was the primary use case. TCP tunneling is possible architecturally but not something I've had in mind. I suggest start by raising an issue on GitHub and adding thumbs up. If it receives enough attention, I will prioritize it. I am less familiar with what would supporting UDP entail, so cannot answer that right now.

That list is where my research started! Was surprised not to find a pure node.js solution that's easy to self-host and has CLI/SDK.

Added https://github.com/anderspitman/awesome-tunneling/pull/214


Fascinating


There appears to be a lot of confusion in the comments around what the MCP is and how it is different API.

I've done a deep dive here before.

Hope this clears it up: https://glama.ai/blog/2025-06-06-mcp-vs-api


That "deep dive" is an apples-to-oranges comparison. MCP is also a "HTTP API" that you so criticize.

You also somehow consistently think LLM making tool calls against an OpenAPI spec would result in hallucination, while tool calls are somehow magically exempt from such.

All of this writing sounds like you picked a conclusion and then tried to justify it.

There's no reason an "Agentic OpenAPI" marked as such in a header wouldn't be just as good as MCP and it would save a ton of engineering effort.


Thanks.

The video link seems to be missing in the section: Bonus: MCP vs API video


Yes, the exact same conclusion I arrived to.

I did find writing about it therapeutical though.

The goal is to move past the thought lingering at the back of my head.


OpenRouter, Glama ( https://glama.ai/gateway/models/claude-sonnet-4-5-20250929 ), AWS Bedrock, all of them provide you access to all of the AI models via OpenAI compatible API.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: