Comments URL: https://news.ycombinator.com/item?id=49918200

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49847924

Points: 2

# Comments: 1

I earned an MSME without ever learning to actually make things, so once I could afford it I bought a Sherline CNC mill and taught myself to use it. I made many mistakes but got there. I used it just last week to make a wind gauge mounting bracket for a 70 year old sailboat.

I liked that it was made in the USA and (at the time, pre mainstream internet) had a great community to learn from.

I know there are other options still, but Sherline has a fond place in my heart for how easy they made it to get started.

I don’t understand how that could be the takeaway. The service is just what it says on the homepage: a way to make datagram transports compatible with event driven architecture and serverless. I don’t think the word “overlay” appears anywhere. I get your point, but thats not at all the positioning. The SDLC and operations are what it’s about.

> End-Encryption with DTLS is possible by using SNI inspection on the Client Hello

Sure. In simple cases even that’s not necessary if a listener is tied to a single endpoint, right? But again, this service probably isn’t ideal for such cases — it would work, but I, for one, don’t see why it would be useful.

I think that’s exactly it; an engineering decision based on the constraints at hand.

For the most part the technology (and society) we have it built on that resolving in favor of trusting 3rd parties to some degree.

FWIW, Proxylity supports plain UDP as well as DTLS so it’s possible to build a paas-through proxy for DTLS to Lambda, for example. But then you’ll need to implement DTLS in Lambda. People have done it, but it’s a heavy lift.

The idea with the DTLS support is protecting content in traffic, and the handling it in your own AWS account. For some cases it isn’t acceptable to have Proxylity or AWS to have any chance to seeing the data. But for the most it’s not a problem and the convenience of what the service provides is worth it.

But I hear the concern. I guess I just expect folks will make good decisions for their use cases.

> ...lossy UDP

All networks are lossy, and all transports. The difference between UDP and TCP based transports is who decides how to handle it. With UDP the application developer decides; with TCP (and QUIC) the protocol decides. More and more projects are taking-on the reliability decision, for a lot of reasons that trace back to this difference.

> ..some random guys on the Internet

Essentially; and that's how everything starts. We've been in production since early last year and have maintained >99.99% availability. We're a certified partner with AWS, and have "qualified software" (it passed their security review), and our security posture report is available from AWS Marketplace. We aren't SOC-2 audited yet because we want to do it right rather than pay for a rubber-stamp report, and that takes time and a lot of money.

Yes, your point on security is correct. Since our service terminates the DTLS connection we could see the cleartext (just as any gateway service does, like AWS API Gateway, etc.). We don't touch it except as strictly needed to pass it to the configured integrations.

EDIT: FWIW, using a plain UDP handler you could implement DTLS handling that runs in your control, in which case payloads would be opaque to us. That's a bit of an effort, though. We were asked for this, so we built it.

Comments URL: https://news.ycombinator.com/item?id=49645804

Points: 13

# Comments: 25

Comments URL: https://news.ycombinator.com/item?id=49527431

Points: 4

# Comments: 0