Since last month hardened bidirectional edits such that people can work on video assets with Premier Pro, DaVinci, and such.
Got a pre-alpha release, where we managed to split congestion control over QUIC and bulk data transfers over TCP, and the lockless conflict resolution :D
Why did your group use the AI, how would you answer the Conclusion questions?
As an anectdote: I like low-fi punk music because of the energy, and low skill for entry level. So when I started playing music, I went for this genre. I used it as a hobby over 10 years as it brought me joy, and enjoyed the process, without the grind for leveling up the skill.
It's also fun to do low effort things that are good enough. Much more fun than being l33t.
Hi ogig, funilly enough I was also running this boids experiment a few months ago. Managed to get around 8k at 60 fps on 1 thread on my cpu, using golang.
My goal for this experiment was to encode the optimal cache data structures into meta programming generators such that claude can write high level DSL and generate down to this level of simulations. I am curious if you had such an approach also.
That's very interesting, thanks for commenting. Not my approach, I have a multithreaded Rust kernel (SoA, spatial hash, bounded-kNN, rayon on some passes). The agents sit on top of several diffuse fields, an econ layer and combat logic, all of it needing bit-determinism for the netcode.
I do use some metaprogramming, but as safety rather than generation: a declarative macro derives the modifier struct, defaults, parsing and wire order from a single list, and feeds hash/save/resync so I can add mechanics at a high level without being able to desync the sim. Also a set of probes help me test for correctness and speed after a change.
So seems like I'm taking an iteration speed approach with safeguards, checking after the fact, while yours is optimizing beforehand by trying to encode optimal structs. That's fascinating, it will probably occupy my head for a good portion of the day, thanks again.
I went full meme, and stacked like 3 level of generators on top of eachother.
Level 1: A basic generator does the same stuff: Raw Structs to SoA + Wire Codecs + Bitfields to not waste space.
Level 2: Then on top of this one, I got a generator for relation between entities.
Level 3: And on top of this one one for "game" design and schema behavior.
And then all this runs on the simluator engine that handles Collision, Flow Fields, Events, Genetic Algorithms, Networking, etc.
The flow is something like this:
You ask claude to read a story, novel, w/e and extract relations, entities, etc.
Then it edits a Schema.go with the High Level DSL adnotations, like 10 lines per entity.
Then I run the Level 2 Generator: That creates the primitives and a high level API.
Then it combines the high level API rules in main.go and just compiles it to the final gamestate.
And runs benchmarks to see how many allocs/ops per entity are.
And one more fun thing, it encodes the gamestate on 1400 bytes, in order to fit on a UDP datagram such that it can support networking, quite fun. Once you get the primitives correct.
For all this + networking + disk i/o; works on 4 cores (threds) only. But the simulation in itself is on 1 core 1 thread. The networking offloaded to 1 core (1 thread), and disk i/o to a different core (thread), and the painting on screen (to a different core (thread))
Two weeks ago presented current state of KEIBIDROP at Pass The SALT 2026, and now I am planning the push for the next version 0.4.0.
KEIBIDROP: Makes remote files appear as local (it hides the network latency in order to let you open and edit a peers file without downloading it upfront or re-uploading it fully back).
For version 0.4.0 I am planning multi-user support, using UDP (QUIC) instead of TCP as the networking layer, optimization of live-edit regions of files, and to test it even more for data heavy workflows.
I am curious if I got it right, but the business of the company is providing exit nodes for AI bots/ strangers via peoples residential IP's? This is my impression from accessing the website. I was interested at first, but now I got a bit of ethical doubts about it.
Yep, everyone comes out happy here. It's a win-win-win. Unlike other proxy businesses, we always get our providers' consent before adding them to our pool.
I think OPs mantra is "Scrape. Automate. Scale."
It feels like people who consent to this "passive" income, do not understand what they consent to.
The business model seems grey towards black. "Signup to be part of 3rd party bot farms exit node, you get paid, all will be good. Nothing bad happens, you consent"
I think you’re steering this conversation in a direction that isn’t really meaningful. We have security mechanism in place that prevents misuse and fraud.
I did not measure agents, but lets take the following example:
Assume you have a 10 GB blu ray movie that you want to watch without waiting for upload/ donwload time.
Maybe you host it on a server on another continent, where you got a 200ms RTT.
And your wire at home supports around 500Mbps - approx 62 MB/s.
Thus to Download it fully, would take around: 161 seconds if you use the full wire and on the happy case.
But to actually watch it and skim through it, you do not need to use the full wire, but around ~11 Mbps for a 2-hour 10 GB film, which is like 2% of the wire. The only hard part is random jumps, as each seek is a full RTT.
If you prefetch too aggresivelly you hide this RTT, but if the wire is saturated, and if you have a cache miss, then you will hang and wait until the request goes through. Might be upt to 1-2 seconds. The whole game is to pace yourself such that you stay ahead of the consumption rate, without saturating the wire.
I just had a talk (power-rushed a bit) yesterday at Pass The SALT 2026 talking about (my version of) latency hiding filesystems in userspace over the network. My benchmarks, setups, and how to make the magic wawaweewa work.
Basically it went the "sshfs over iroh" approach, and instead of OP's post, it has eager metadata file sharing, and on demand file access. It is still a work on progress, but you can use git juse fine over the fuse mount points without introducing a new tool (edit: but do note that I did not encounter problems with large worktrees, as I do not use them in my flow, and still has some quirks). And still have similar "cold path" access times.
I touch on some insights of hiding the latency, the direct Alice to Bob connection, and has some recorded demos. Goes the generic approach.
You can watch it here if you are interested, but its around 25 minutes.
The first part is about the Post Quantum Crypto, and making direct IPv6 connections work.
The second part is about the filesystems in userspace that hide the latency.
(The second part is around minute 12:00, and I think it is the relevant part to this discussion/ thread).
I see nothing wrong with something probabilistic. I think it is all about offsetting the risk and reducing the odds of bad outcomes. There is this concept of Defence in Depth, thus I assume some sort of binomial formula also applies here.
I am curious, how do you handle latency issues for on demand access? I saw you use FUSE (and FSKit), and from my experience it is pain to make filesystems in userspace work on-demand over WAN because a) latency, and variable RTT; and b) you can't saturate the wire and aggressively read ahead things, otherwise native apps will freeze, lag, or just make the UX unpleasant, especially if there are too many placeholder files, or large files with random jumps in them.
I think what makes FUSE/FSKit great here is that agents usually only need to see the file metadata + read a handful of actual files, rather than some applications needing read many things. If you're doing huge rewrites, this is a problem, but most tasks are usually somewhat small. Definitely is a problem that I've ran into though, we do cache aggressively to try to solve some of this, but it'll never be as fast as reading/writing directly to disk. We have benchmarks [1] if you want to take a look at how we're testing some of the performance there.
Couldn't run your benchmarks, as I did not create an account, and a bit of a different beast that I am comparing against (P2P distributed filesystem), but these are my numbers and setup, and the on-demand part lines up with what I have observed:
Setup: a Linux box on the other side of Romania (compared to where I am living) reading from a Windows box in Singapore (~200 ms RTT)
- reading 1 MiB of a 1 GB remote file pulls only 16 MiB (~98% avoided) - this is because of my fine tuning optimization choice
- first byte approx: 2.3s
- git-LFS repos also clone cold over the mount byte-perfect (separate Mac - Linux run on a ~20 ms RTT)
The thing that I do differently is that my metadata is eagerly pushed, as I optimized for content streaming.
And 100k-file tree mounts I did not test yet.
But my goal was to have instant file access for generic files between apps, and peer to peer, supports also Windows :D
That unfortunately doesn’t match my experience at all. My Claude often runs rg in the repo attempting to find things that need to be changed. And of course Claude still needs to invoke the build tool to ensure the change can be compiled, which necessarily involves reading almost every single file at least for a fresh checkout? Or did you envision the build tool being completely remote?
You can work on shared files instantly without uploading or downloading them.
1 minute video: https://www.youtube.com/watch?v=9Wt0NMx2_I8 Github repo: https://github.com/KeibiSoft/KeibiDrop
Since last month hardened bidirectional edits such that people can work on video assets with Premier Pro, DaVinci, and such.
Got a pre-alpha release, where we managed to split congestion control over QUIC and bulk data transfers over TCP, and the lockless conflict resolution :D