mlhpdx

3 ms·

1.
by mlhpdx 6d ago
Wow, what a disappointment. I’ve found it funny over the years when people are shocked to hear me talking about machining, when they themselves have woodworking tools. Cutting metal, cutting wood, even cutting paper - all useful for making
2.
by mlhpdx 10d ago
I hope that’s the case but I’d feel a lot better to see it in print.
3.
by mlhpdx 10d ago
Impressive technical work and authorship. My quibble, which seems significant in context, is what happened with AoT?
4.
by mlhpdx 12d ago
> so basically your service is to be treated as an Internet overlay 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 archi
5.
by mlhpdx 13d ago
> … must be something you actively think about, then making a decision. 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 resolvin
6.
by mlhpdx 13d ago
While small devices can technically do TLS, it’s a significant battery drain because of the acknowledgements (keeping the radio on while waiting). Anything battery powered is likely to eschew TLS for DTLS 1.2 + CID or TLS 1.3 with early dat
7.
by mlhpdx 16d ago
DTLS is TLS encrypted, so I think you're talking about plain UDP as the transport? There are use cases for that, for sure, but more for protected content over WireGuard or DTLS (we support both 1.2 and 1.3).
8.
by mlhpdx 16d ago
I understand the concern. It can be a great convenience to not run the servers yourself, as people have been doing for decades with respect to websites, apps and APIs. That's essentially the same model, with the host terminating HTTPS
9.
by mlhpdx 16d ago
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 eve
10.
by mlhpdx 16d ago
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.
11.
Serverless DTLS(proxylity.com)
13 points by mlhpdx 16d ago|25 comments
12.
Moon Trees(nasa.gov)
4 points by mlhpdx 25d ago|0 comments
13.
by mlhpdx 26d ago
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
14.
by mlhpdx 27d ago
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.
15.
by mlhpdx 28d ago
DASH. DynamoDB, API Gateway, Step Functions and HTMX.
16.
by mlhpdx 29d ago
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.
17.
by mlhpdx 1mo ago
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.
18.
Serverless Game Servers/Back Ends on Proxylity(proxylity.com)
1 points by mlhpdx 1mo ago|0 comments
19.
by mlhpdx 1mo ago
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.
20.
by mlhpdx 1mo ago
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 varian
21.
by mlhpdx 1mo ago
Not just older people, though they may be more likely to make the “Googling with ChatGPT” joke.
22.
by mlhpdx 1mo ago
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.
23.
by mlhpdx 1mo ago
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.
24.
by mlhpdx 1mo ago
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:/&#
25.
by mlhpdx 1mo ago
I don't use any code from others here, it's a ground-up implementation of the protocol in C# targeting .Net 10 AoT.
26.
by mlhpdx 1mo ago
> 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
27.
by mlhpdx 1mo ago
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 ser
28.
by mlhpdx 1mo ago
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
29.
by mlhpdx 1mo ago
Indeed. That's how the WireGuard handshake works, partly to avoid abuse/spam.
30.
by mlhpdx 1mo ago
Because then it would be DTLS.

More ›