Since I have your attention for the moment, I'd like you to ask yourself a question: What is it that drives you in life? Do you yearn for the feeling of safety? By seeking power, status, wealth, and fame? Is it cravings for pleasure that motivate your actions? Does a sense of obligation to others, or even your past self, that informs your decisions?
@soatok In my experimental cryptography code, I often write long-ass comments trying to justify my design decisions. A bunch of those comments say things like "Soatok said do it like this" and link to your blog posts.
Thanks for making the effort to point out the many cryptography footguns in ways software engineers can understand! :blobcatheart:
Been switching to Codeberg because it's nice but increasingly looking like I soon will HAVE to abandon Github, because the entire interface will soon be just one giant maze where at each intersection one path leads to the feature you wanted and the other path is Copilot
@f09fa681
@mcc
@tedmielczarek Ooof, sorry that WebRTC didn't work out for you on mobile. I've been focusing on laptop/desktop use cases for now, since mobile dev isn't my strength, so I haven't run into those problems yet.
I feel like making WebRTC general enough in the first place for real P2P apps was maybe an oversight by big tech, if not a mistake entirely. So I'm not surprised to see those cos being completely uninterested in supporting P2P apps in the future. We're probably on our own here.
In the meantime, P2P apps actually work in popular browsers using WebRTC (at least on laptop/desktop) and it's basically the only option. So I'll keep pushing to see how far I can take it.
If anyone's interested, here's a demo of my P2P stuff loading a static website:
@f09fa681
@mcc
@tedmielczarek
@steely_glint Yeah, I'd love to see a more purpose-built tech for P2P apps in the browser, with proper ICE and NAT-punching. Like WebRTC, but without the expectation (or complication) of a real-time A/V stream.
And new support to load web content over WebRTC (or a new P2P standard) while still using the browser's native sandboxing, origin separation, caching, etc would be super great too!
@steely_glint Awesome, thanks for the details! That helps give me an idea of what's going on.
Your approach sounds nearly identical to mine, but you're using service workers to fill the iframe instead of something like the srcdoc attribute.
I always thought of service workers as a way to serve a web app out of an offline cache, but never thought the mechanism could be (ab)used to essentially launder origins.
I'll have to play around with service workers and see what they can do for me. Thanks for the idea!
@steely_glint When I get some time, I'll try to look into this again. Need to finish some other stuff first though. In the meantime, all my existing code is open source and on codeberg if anyone wants to poke around:
@steely_glint I got some time to experiment with service workers, and wow, you're right. They're super messy for this kind of thing.
Looks like the service worker context doesn't define a whole bunch of needed things, like the WebRTC APIs. Looks like I'll have to relay the whole request back through the host page to access WebRTC APIs? lol.
Letting the service worker do the actual work of pushing web content into the browser let me get rid of a huge pile of hacks that had to apply transformations to the HTML content and stuff it into an iframe the hard way. And now other resource types (like fonts) might be supported too without any more headaches on my side.
I'm still too scared to enable javascript on the guest pages, since they would share the origin of my own website and the guest code is toooootally untrusted. But overall, I still think the service worker approach is a big improvement.
@steely_glint
@aral awww, ok. I'll spin up my mac mini today and dig into that one. It's always Safari ... :blobcatgoogly:
And if I understand correctly, Kitten is a kind of HTTP app server? My SmolWeb toolbox includes a reverse proxy gateway component, so it should be possible to hook up your favorite app server to the p2p network without too much fuss. There's also a Rust library if you want your app server to have native support.
Improving Geographical Resilience For Distributed Open Source Teams with FREON
In a recent blog post, I laid out the argument that, if you have securely implemented end-to-end encryption in your software, then the jurisdiction where your ciphertext is stored is almost irrelevant. Where jurisdiction does come into play, unfortunately, is where your software is developed and whether or not the local government will employ rubber-hose cryptanalysis to backdoor your…
@soatok
@sarahjamielewis That is one of the things that super annoys me about VSCode. After spending many years in JetBrains' auto-saving IDEs, I've entirely lost my old habit of spamming the save button. And VS code still requires you to save manually, so I make sooo many mistakes with it. :blobcatcry:
Horrible idea: Use AI slop to devalue platforms directly instead of trying to extract revenue.
Play a game of Cards Against Humanity. Feed the winning combinations into the AI slop machines with the preamble: "Turn this into a cringey LinkedIn post." Flood LinkedIn and Meta properties with the output.
