Building MiniSwift. Write and run SwiftUI in any browser.
Istanbul
Joined June 2026
- Tweets383
- Following696
- Followers173
- Likes236
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
If you would like to develop your own model on your local machine, there is also an alternative like this ;-) llm.istanbul/
There are 2 career paths in AI right now:
The API Caller:
Knows how to build with LLMs.
The Architect:
Knows how LLM systems are built.
If you want to move toward the second, Stanford has one of the best free LLM engineering playlists on YouTube:
CS336: Language Modeling from Scratch.
The 2026 course has 18 lectures covering almost the entire LLM stack -
➡️ Build the model: Tokenization, Transformers, architectures, MoE
➡️ Understand the hardware: FLOPs, memory, GPUs, TPUs
➡️ Make it fast: Triton, GPU kernels, parallelism, distributed training
➡️ Train it: Scaling laws, data collection, filtering, deduplication
➡️ Run it: Inference, evaluation
➡️ Post-train it: SFT, RLHF, RLVR
Plus multimodality.
And you don’t only watch lectures.
> You implement the tokenizer, Transformer and optimizer.
> You write FlashAttention2 in Triton.
> You build memory-efficient distributed training.
> You turn raw Common Crawl dumps into pretraining data.
> You fit a scaling law.
> You use SFT + reinforcement learning to train a language model for mathematical reasoning.
Stanford says students write at least an order of magnitude more code than in most other AI classes.
Stanford CS336. Spring 2026. 18 lectures. Free on YouTube.
Choose your path.
(Playlist in the comments)
♻️ Repost to save someone $$$ and a lot of confusion.
We have reverted to the pre-2000s era in information security.
To buy stuff, you can just take a picture of your credit card, drop it in the chat and Grok @Bot will scour the Internet for the best deal on the item you want and order it
Readers added context they thought people might want to know
xAI explicitly warns users not to include personal information in prompts, yet credit card photos may contain such information.
Grok Bot's terms state that user data and credentials may be stored in its cloud environment and require human review for financial transactions.
x.ai/legal/privacy-…
x.ai/legal/grok-bot…
I’ve started separating MiniSwift’s toolchain into "miniswiftc". And none of this is known beforehand; you learn as you go. If AI is going to replace software developers, let it happen already 😄 it’s seriously exhausting...
The Kavak C compiler just reached a point where it can compile projects like SQLite, zlib, and lzr cleanly in one go.
This is a huge turning point for MiniSwift. Instead of relying on emcc, it’s switching over to Kavak’s own C compiler.
This is going to unlock a ton of advantages
We're donating $1.5 million in Grok tokens to the Omacom Foundation to support Omarchy.
Omarchy is built on the idea of a self-improving, personal operating system. Agents and inference make that vision even more powerful.
Most of us spend our days in an operating system, yet it's the most overlooked piece of personal software.
In fact, most operating systems are the opposite of personal. Omarchy is changing that.
Change starts with developers. If anyone knows developers, it's @dhh.
@spacexai is proud to be a company for developers, and we're thrilled to support the developers, builders, and creatives making the OS personal.
A bug I noticed while adding CoreGraphics support to MiniSwift.
Here, transform?.pointee should return exactly nil if transform is nil. Otherwise, it should copy ALL the fields of the struct the pointer points to and return a fully populated Optional(T(...)).
But MiniSwift was somehow producing a partially populated struct.
I think one of Apple's strategic mistakes when designing Swift was this whole Optional parameters.
Of course, when you're trying to access low-level stuff like CGAffineTransform through UnsafePointer in Swift, these lovely little bugs tend to show up.
The MiniSwift toolchain converts Swift code into C. At a certain point, you just have to stop writing C code. I couldn't write C code that well :D
I optimized my transformer algorithm I wrote using macOS Metal to predict the next pixel applying a similar logic to image generation. After 10,000 steps, it began producing interesting outputs.
