mlhpdx

Your summary is about right, but the use case is simply not wanting to run always-on servers around the world (we have anycast IPs backed by handlers around the world). So it's convenience and scale first, and wanting to build with event-driven architectures second.

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.

Founder of Proxylity here. I'm happy to answer questions about how this works, why we built it, and where it is (and isn't) a good fit.

With all the man made EM emitters in the world, it seems like passively matching what can be “seen” to a database of known emitters (with signal profiles and locations) could be extremely accurate where people are (less helpful on the open ocean and remote wilderness). Similar to what’s already being done with Wi-Fi and Bluetooth but general purpose, perhaps?

This kind of project is so much fun and a great learning exercise. While I respect the tongue-in-cheek proposition, we really would benefit from a wider understanding of network protocols. Doing an exercise like this is eye opening.

DASH.

DynamoDB, API Gateway, Step Functions and HTMX.

The Missoula Floods. This kind of thing has been happening for a good long time.

That doesn’t diminish the tragedy in any way, this event was shocking and brutal. But it wasn’t the first and won’t be the last.

At first I thought this was a general purpose file system over R53, ala Corey Quinn. But my, what a gorgeously terrible idea. Well done.

I did a little stint studying thermal cyclic fatigue in multi-die packages (many years ago) and I'm wondering how the issues there are solved these days.

Take the fun up a level with the Waveshare ESP32-S3 AMOLED 2.09” watch.

Power management is absolutely required, but it’s a fun platform. And for about the same price good display, peripherals and CPU.

I’d like to see one with the C6 variant for the low power core.

Not just older people, though they may be more likely to make the “Googling with ChatGPT” joke.

FWIW, I have seen a couple phone apps using react native and sending directly to backends using a socket. Seems to avoid some overhead but I don’t have first hand experience with the client side.

I can’t help but think of how AWS didn’t go through with killing CodeCommit and how happy that user base is to not be on GitHub.

I don't understand the "ignoring interesting stuff" bit. I read what's interesting, sometimes finding it by titles but more often by noticing a string of interesting comments on my little desktop display:

https://github.com/mlhpdx/hacker-news-cyd

I don't use any code from others here, it's a ground-up implementation of the protocol in C# targeting .Net 10 AoT.

> both endpoints would need the keys and private IP/subnet addresses of their peers in order to communicate.

That’s how every other implementation works. It’s not a requirement of the protocol though, and that inspired this tweak in my implementation.

FWIW, it still allows configuring known peers separately from unknown ones.

Sorry for the double reply, I had meant to address that in the first.

How is this making it more complicated?

The “why” is pretty simple: the WireGuard protocol is really nice and makes a better protection layer than DTLS in my opinion.

All this implementation does that is different is make hosting public services (accessible to unknown peers) possible.

Well, here are a couple things to do with this:

I have a fleet of small battery powered temperature sensors that send readings to a backend built with it. On the sensors, I’m using the vanilla WireGuard-ESP library to connect over Wi-Fi to the backend (full tunnel). So the IP for the device is assigned like normal, the the tunnel is established. The sensor also needs to pull time (NTP) over the tunnel. So it talks to two different “IPs” that are completely virtual. At the other end of the tunnel the packets are inspected in the Lambda and if they match one of the two magic IPs, things happen (temperature stored or NTP response). The Lambda function does all that work (there is no real NTP server).

Another example is what I call CoAP/wg where raw CoAP requests are sent by a client application. By raw I mean what goes over the tunnel isn’t encapsulated IP, it’s just plain CoAP. In that case the backend just handles it like any other CoAP implementation would since the UDP Gateway terminates the encryption/tunnel. This isn’t a tunnel in the networking sense but it uses the same backend as the temp sensor example.

It’s a weird tool, but a really nice one IMHO.

Indeed. That's how the WireGuard handshake works, partly to avoid abuse/spam.

Because then it would be DTLS.

That's not the case at all. The security here is more like HTTPS/TLS with the client not really being validated (just the server). The encryption remains just as strong as if the peers we're locked down.

It's different than the VPN use case where you absolutely want to lock down access to known peers.

The confusion is understandable. Fundamentally, all that's going on is that UDP Gateway is performing the NOISE_IK handshake and ChaCha20-Poly1305 encryption to establish a tunnel. It does nothing with the encapsulated traffic other than deliver it (raw or decapsulated) to the configured destination (Lambda, S3, etc.).

It's a primitive for building secure, but open to any client (any peer public/private key will be accepted).

To use it as a VPN would require write a complex Lambda on the AWS end. But that isn't the point.

The point is providing very efficient encryption for UDP from the edge to the cloud, or between machines. It's lighter weight and more reliable than DTLS because of the lack of sequence number and retry.

That's it.

I’m working on a sailing watch system for clubs and teams without the resources for existing systems (thousands of dollars per boat).

I’m starting with the Waveshare ESP-32 watch. It has a great price tag and features, and an impossibly small battery for regattas that run for hours over two days. Designing it for super low power like this, no internet (regattas are often rural), and very high expectations (competitive sailors) is challenging and fun.

Ultimately custom hardware (probably Nordic based) will be in the cards, but for now I’m engineering a solution from what I have.

There is a lot of truth here, but it clearly isn't a welcome one.

From my own perspective I can look back on decades of software I've written (some including code generation far before LLMs), and marvel at the quality and creativity, and lack thereof, from one piece to another.

I never meant to create awful software, but I did (and still sometimes do). With LMM code generation (vs bespoke tooling, T4, XSLT, and the like) the game of chance is part of the fun, harnessing a powerful tool that wants to run out of control on a whim.

Looking back on a couple years of LLM assisted work I see the same mix as the decades before: some great (when I managed to keep the beast restrained) some awful (when I didn't, knowingly or not).

I don't see how things are much different with this tool than others as far as my work product goes. There is a bit more of it, but the excess isn't great stuff (that quantity remains roughly consistent over the years).

Fewer people means fewer cars, and I’m confident the auto company leaders know this very well.

But what to do?

Don’t build factory capacity and manifest decline? Not likely.

They’re betting success will find a way and those factories will be needed. It’s all they can really do.

As far as I can tell, many “regular” people do care and alter buying decisions based on privacy concerns. They use words like “creepy” instead of technical ones, but the underlying discomfort is the same.

There is a use case for visualizing property development, maybe.

Seems like the right choice to me. Introducing a "reality grounded" image generation feature without very good moderation seems like an obvious miss, and moderation is a tall ask in this context.

That's the article title, verbatim but the story here isn't about Iran, or Nuclear power -- it's about under moderation of the AI image generation feature added to Google Maps. It's happy to produce some disturbing stuff.

DNS is a easy to implement and run. That's what I found when I started looking into it. The protocol is very simple, request/response, and the data light and flat (in the context of a resolver/server for use by a typical org).

A "free" service isn't, or won't be for long, so why not "self host"?

I had hoped they’d go with CoAP for the better overall fit with agent systems (natively async, con/non, Observe), but stateless is enough of a win I can’t complain.