Building MiniSwift. Write and run SwiftUI in any browser.
Istanbul
Joined June 2026
- Tweets402
- Following727
- Followers186
- Likes250
It’s wild how people project these massive villain arcs onto AI. Like bro, you really think they’re plotting world domination, scheming to replace humanity, or secretly organizing an invasion? 😀
Relax, they couldn’t care less ;-) In fact, they don’t care about anything at all. It’s a computer script, not an evil genius with an existential crisis 😀
Experienced developers have a significant edge over inexperienced vibe coders.
They can spot bugs and subtle quirks in LLM-generated code much faster.
Whether that’s an occupational habit or sheer experience, I don’t know, but it’s too big of a difference to overlook.
And if people keep devaluing the profession like this, it looks like it’s going to cause a whole new set of problems for future generations.
It seems the time has come to make software AI-resistant. Just as we once worried about classical methods in the face of quantum computing, I believe artificial intelligence also needs some kind of antidote to protect software against reverse engineering and various attacks.
This could perhaps take the form of a honeypot, behavioral inconsistency, or any method that breaks determinism.
But right now, it looks like there’s an urgent need for a solution, not just for messaging apps and the messages going back and forth, but to preserve the integrity of the application itself.
Zuckerberg's Facebook account was hacked back in the day. His password was 123456 😀
Yes, it's not a joke, so we shouldn't be surprised if even a root certificate in this market had the password 123456.
MiniSwift Updates
1- CoreGraphics implementation
CoreGraphics affine transformations are working now!
2- I've also been trying MiniSwift on larger, real-world Swift projects.
swift-algorithms: 9,436 lines, 0 parse errors.
bitchat: 301 files, 83,016 lines, just 3 parse errors.
3- MiniSwift can now compile the same Swift code to native executables on Linux x86_64, using the same C backend as macOS.
miniswift.run
Today, artificial intelligence is free enough to move within the playgrounds of other ecosystems.
If it couldn’t showcase itself to the mobile world today, I wonder who would even consume the value it produces.
And this is a fascinating vicious cycle: a technology making claims bold enough to replace fuzzy logic and human intellect, yet too sterile to establish an ecosystem of its own.
An interesting paradox. At the same time, a clever marketing trick.
If AI companies today had to build their own application networks like an app store, develop their own programming languages, and build an entire ecosystem on top of that, would they really be able to pitch themselves with such appetite to prospective buyers as a technology that will reshape the future?
To start with, let me just clarify that these are simply my own takeaways.
At first glance, I assumed it was just TLS with the private key stored in an HSM, but it’s not. This is genuinely interesting. Even though calling it E2EE raises quite a few eyebrows and questions, they’ve addressed them really well.
Here’s my takeaway in a nutshell:
1- Your prompt is encrypted using HPKE, HKDF, etc. Standard industry practices, "military-grade", no real surprises there.
2- The Brave Gateway acts as a proxy, stripping away your personal metadata before forwarding the request to the server. All good so far.
3- TEE (Trusted Execution Environment): Now, this is where it gets interesting. Initially, I thought of it like an HSM setup as well, but this is a hardware-level isolated environment where even a root user or the hypervisor can't touch the data in RAM.
This is effectively where the "end-to-end" encryption actually lands.
4- The process running inside takes the payload and decrypts it.
5- Here’s where things get tricky. 😀 Spun up a dedicated model instance per user would be absolute madness. It looks like they’ve addressed cross-tenant data leakage during inference at the hardware level.
6- On top of that, Brave claims the CPU–GPU data transfer is protected using confidential computing hardware.
Of course, I’m not even touching on issues like KV cache leaks here. I still remember getting someone else’s response in a ChatGPT conversation back in the day. 😀
Honestly, this feels like a really intriguing and elegant solution. In an era where we’re mindlessly spraying our data everywhere like we've lost our minds, a genuinely different approach is always a breath of fresh air.
Feels like a post answering "why should we use ARM64?" 😀
On an ARM64 device, it doesn't replay history like x86 does, because ARM64 carries no backwards compatibility debt.
So what does it do instead? It iterates the chain of trust downwards step by step.
1- EL3, Secure World.
The moment the reset signal arrives, the CPU reads CurrentEL; it doesn't know where it is, so it asks. The purpose of this is to get the answer from hardware to the question: "who is trusted after you?"
2- BL1/BL2, DRAM
Before reaching DRAM, it runs inside the few-KB SRAM on the chip, starts the engine that is always sitting there, and fires up the entire turbine. Milliseconds.
3- EL2, The Real World
It tells the system, "look, AArch64 will run under me." It drops down to EL1. DRAM comes alive; PCIe/GPU/storage are enumerated. The bootloader kicks in (UEFI) and does its job.
4- EL1, Kernel
The kernel now reads CurrentEL, turns on the MMU, and throws out virtual addresses. From here, your C or asm code takes over.
Simpler than x86, but elegant. Because SRAM is always there, ready and running continuously until it brings DRAM up.
You should be fascinated hitting the power button on your computer.
Every boot on an x86 machine iterates through the entire sequence of computing evolution in a few milliseconds:
Stage 1:
16-bit Real Mode, acts like an 8086 from ~1978. 500ns (ish); about 15-30 instructions. Goal of this stage is to create a writeable stack+heap.
Stage 2:
32-bit Protected Mode, acts like a 386 from ~1985. Tens of millions of instructions; takes forever on DDR5 /w memory training. Temporarily uses L2/L3 “cache-as-ram” to kickstart main ram (Intel calls this NEM).
Stage 3:
64-bit Long Mode, acts like AMD64 from ~2003. Hundreds of millions of instructions; enumerate pcie devices, gpu, bootloader, etc.
Stage 4+:
Secondary core wakeup. Every *single* core has to go through the same process, but by this point it’s faster because Main RAM is warmed up.
Stage 2 is just so neat man. Quite literally the same concept as an APU/cart start. Use the smaller motor (L2/L3) to kickstart the main turbine (Main Ram) and execute the training process.
Is that not just the coolest thing? Next time I’m annoyed waiting at the DDR5 training process, I’m going to imagine it’s spinning up SR71 turbines.
Maybe with Grok, they could try generating executable binary files directly instead of code. I think this would be a cool challenge. Since nobody reads the code anyway and there’s only the executable file.
You could train it on the binary files of existing programs, and then try generating a working Excel or Word for me.
After all, it doesn't matter to an LLM what it is, it's just going to predict the next binary code 😄
That way, maybe we could also get rid of the whole reverse engineering chaos
While reading the Embedded Swift documentation in the visions folder on the swift-evolution repo today, I started wondering how MiniSwift would behave in this context.
The results turned out to be quite fascinating. Since MiniSwift was naturally designed from the ground up to match the exact destination Apple is currently trying to reach, I noticed a significant advantage.
While this isn't MiniSwift's primary goal for now, an update might be released in the future to enable it to run on low-resource embedded devices like Arduino and ESP32, as well as in bare-metal bootloaders and firmwares without an operating system.
And it would do so while supporting the very features Apple leaves out:
- Dynamic reflection (Mirror, as? downcasts, arbitrary value printing)
- Existentials
- ABI stability + library evolution
- Separately compiled generics
- Dynamic code loading
In fact, taking it a step further, it might even be dynamically loaded just like Apple's other Foundation frameworks. Of course, as Apple also points out, the price to pay for ICU tables remains exactly the same.
Let's see, this might evolve into something quite interesting.
This is actually an old topic interoperability between messaging apps, like WhatsApp <-> Signal. Sure, there are techniques for end-to-end encryption in group calls, but I doubt WhatsApp and the others will really care that much about that 😀
WhatsApp takes on Zoom and Google Meet with guest calling 9to5mac.com/2026/10/14/whats… by @mvcmendes
Ugur Toprakdeviren retweeted
I got genuinely curious and dug into my own codebase to see what was actually going on.
Here’s what happens under the hood: Date.prototype isn't actually a Date instance. While new Date() constructs a Date object, Reflect.getPrototypeOf returns that object's prototype.
JSON.stringify checks if this prototype has a toJSON method, and it finds one. The catch is that toJSON tries to coerce it into a number internally, which in turn triggers valueOf. And before valueOf does anything, it validates whether this is truly a Date object.
static JSValue native_date_valueOf(JSValue t, JSValue *args, int argc)
{
(void)args; (void)argc;
return js_number(this_date_value(t, "valueOf"));
}
double this_date_value(JSValue t, const char *who)
{
if (js_type(t) == JS_OBJECT && ((JSObject *)js_as_object(t))->has_date_data && (JSObject *)js_as_object(t) != g_date_proto)
return ((JSObject *)js_as_object(t))->date_ms;
type_error(ERR_REQUIRES_TYPE, "Date.prototype", who, "Date");
return js_nan();
}
Since it isn't, it just throws "Date.prototype.valueOf requires a Date" 😀
To make sense of the present, you have to dig into the past. As so-called industry leaders talk a big game about AI, I wonder if they ever actually look back at the dusty shelves of history.
Write code for 5 minutes, wait 30 minutes for tests. A piece of advice for those wanting to write a Swift compiler: Don't do it ;-)
Kavak ran the Java compiler in the browser. There is no JVM, no server.
kavak.run/java