DEV Community: Marius-Florin Cristian

Google Drive upload taking too long? Skip the upload

Marius-Florin Cristian — Mon, 02 Nov 2026 08:00:03 +0000

Uploading to Google Drive is slow because it runs at your upload speed, and a lot of home internet plans upload much slower than they download. The other person can't open anything until your upload finishes, and then they still have to download the whole file.
With KeibiDrop you skip the upload. The file goes straight from your computer to theirs, and they can open it right away while it's still coming in, in the app or in a browser tab. It's free, there's no account and there's no file size limit.

From the table on the original page:

10 GB sent, five times each way | About 5 to 6 minutes each (30 to 37 MB/s) | Servers in Singapore and Timisoara, Romania, about 200 ms round trip, 500 Mbps line, through our relay
Same test on Wi-Fi in Barcelona | About a tenth of a second (median) | 72 ms round trip, direct connection, July 2026
Reading a file that sits on the other computer | KeibiDrop 20 to 30 MB/s, 15 to 23 times faster than sshfs | Same link, 100 MB and 1 GB files, July 2026
Opening a small part in the middle of a 1 GB file | About 16 MB came over, out of 1 GB | Server in Timisoara to a Mac on home Wi-Fi in Bucharest, through our relay, September 2026

Full version, with the limits and the method: Google Drive upload taking too long? Skip the upload

Source, AGPL-3.0: github.com/KeibiSoft/KeibiDrop

Fast simulation code is slow to write, so generators write it

Marius-Florin Cristian — Sun, 01 Nov 2026 17:14:48 +0000

I want to talk about code generators, domain specific languages (DSL), and simulating interactions.

Me personally, I am a fan of games like Dwarf Fortress, Age of Empires and Might and Magic, and Role Playing Games in the broader sense. Now, no matter how you look at them, they all boil down to having a "state" (like a chess board), some "actors" (the little ants you interact with), and "the rules and relationship" they form to each other.

Initially this idea started being explored by looking into cache optimized Go data structures after reading a blog post by Serge Skoredin, and trying to encode them as annotations for generating code out of them. I like meta programming, not gonna lie.

Ecclesia is an isometric pilgrimage through a world of countries drawn as Orthodox icons. It is written as annotations on Go structs, about ten lines per entity. Seven code generators, stacked, turn those lines into cache-friendly memory pools, behaviour, the world, the drawings, the network frame, the screens and the rules. The simulation runs on one thread, at 0.21 ms per tick on an Intel i7-9750H.

Twenty frames from tick 60 to tick 2,340, rendered headless by the game's own tool, with the camera following the shepherd.

The goal

How many classic Reynolds boids can you run on 1 CPU at 60 FPS, without using any goroutines? I managed to get around 8192, using Serge Skoredin's approach from the blog post last year.

My goal for this experiment was to encode the optimal cache data structures into metaprogramming generators, such that Claude can write a high-level DSL and generate down to this level of simulations.

If I had to output the code myself, it would take around 8 hours of constant writing to get around 1k LoC of code. I treat the low-level tasks as building blocks. You need a grasp and understanding of what is possible with them, but you do not need to remember the exact byte order and syntax.

The stack

I went full meme, and stacked like 3 levels of generators on top of each other.

Level 1: A basic generator does the same stuff: raw structs to SoA + wire codecs + bitfields to not waste space. And runs benchmarks to see how many allocs/ops per entity there 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.

Level 2: Then on top of this one, I got a generator for relations between entities. Level 3: And on top of this one, one for "game" design and schema behavior. And then all this runs on the simulator engine that handles collision, flow fields, events, genetic algorithms, networking, etc.

Ecclesia added four more levels. Each generator reads its own annotations and writes Go that the level above calls.

Generator	Describes	Writes
gameframegen	Memory	Struct-of-arrays pools, wire codecs, bitfield accessors
simgen	Behaviour	Actants, relations, and the state machines that move each relation forward
gamegen	The world	Species, spawns, world rules
icongen	What a thing looks like	Each asset as a list of operations over parametric forms, plotted to an 8-bit indexed sprite by integer arithmetic. No image files.
netgen	What a client is told, and in what order	Which pool goes first into the 1,400-byte frame when the world is busy
shellgen	Everything around the game	Screens, render order, layout, typed settings, a versioned save format
rulegen	Who a person is, and how what they do turns out	Hidden dice. Every probability is computed by exact enumeration of the 216 outcomes of three dice.

Two checks sit outside the chain. simcheck emits nothing. It refuses a relation that nothing spawns, and an actant that nothing fills, because both generate valid code and never happen. netgen's budget check fails the build when a schema promises more than a frame holds, and it prints the arithmetic.

From a story to a running world

The flow is something like this. You ask Claude to read a story, a novel, whatever, and extract relations, entities, etc. Then it edits a Schema.go with the high-level DSL annotations, 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.

1. A story: "fairies that glow and heal deer".
2. Annotations on Go structs, about 10 lines per entity:
     simgen:actant  affordances=Flee,Graze        (the deer)
     simgen:relation Heal actors=Fairy,Creature   (the healing)
3. Seven generators write the Go code.
4. simcheck and the frame budget refuse what can never happen.
5. go build, and the world runs.

The page view and the eye view

The world is drawn from the page, isometric, as in the first animation. The same state can also be seen through the shepherd's eye.

There is also a first-person view, similar to the original Might and Magic.

Twenty-four frames at tick 600, the eye turning 360 degrees in steps of 15.

Threads

For all this + networking + disk I/O, it works on 4 cores (threads) only. But the simulation in itself is on 1 core, 1 thread. The networking is offloaded to 1 core (1 thread), disk I/O to a different core (thread), and the painting on screen to a different core (thread).

Measured per tick on an Intel i7-9750H, default world, 600 ticks, rendered headless: simulation 0.21 ms, culling 0.28 ms, ground 1.33 ms, sprites 1.14 ms, overlay 0.49 ms.

MMORPGs with a local agent

It is quite wild, as at some point you realize you can hot swap the views of a running program, and end up letting people create their own fantasy game by prompting on the same gamestate and rules shared by other people.

I think we will end up having MMORPGs that ship a small local agent, that allows you to fill in the gaps and build the world and game system tailored to you, but at the same time interact and be a live part of the other people's own game fantasy. I would love to play such games.

Limits. The per-tick numbers come from one machine and one world, over 600 ticks; a busier world costs more. The 8,192 boids figure is a separate experiment, one thread at 60 FPS. The engine and the game are not published.

Originally published on keibisoft.com: Fast simulation code is slow to write, so generators write it

One set of security records for customers, auditors and regulators

Marius-Florin Cristian — Sat, 31 Oct 2026 08:05:46 +0000

Customers, certification auditors, regulators, insurers and buyers each ask about a company's security in their own words. This chapter shows that they ask for the same small set of records, such as an access review or a signed software release. A company that produces these records as part of its normal work can answer each new request from what it already has.

Read it on keibisoft.com: One set of security records for customers, auditors and regulators

Part of the series Building a security program for a growing company.

Send a file from one browser to another, nothing to install

Marius-Florin Cristian — Fri, 30 Oct 2026 08:00:01 +0000

You both open web.keibidrop.com, connect with a code once, and drop the file onto the page. The other person presses Save. There's nothing to install, no account and no upload to a cloud.
The two tabs talk through our bridge, which passes along encrypted pieces it can't read, and the encryption is quantum-safe. It works on a work laptop where you can't install apps, or on a computer that isn't yours.

Full version, with the limits and the method: Send a file from one browser to another, nothing to install

Source, AGPL-3.0: github.com/KeibiSoft/KeibiDrop

ACME, the company this series follows

Marius-Florin Cristian — Thu, 29 Oct 2026 08:00:00 +0000

ACME is the small, made-up company that this series uses as its example. It starts in 2019 as a webshop for smart plugs, sells software to businesses from 2020, puts a gateway into buildings from 2022 and sells to the public sector from 2024. This chapter describes how it grows and how its risks change along the way. It also covers which rules reach it and how much room each one leaves, and who inside and outside the company cares about security at each stage.

Read it on keibisoft.com: ACME, the company this series follows

Part of the series Building a security program for a growing company.

Leading security at two startups in a row, both acquired about two years after I joined

Marius-Florin Cristian — Tue, 27 Oct 2026 08:00:01 +0000

I joined Krizo in 2019 as a 24-year-old software engineer, and Omnio in 2020 as its CISO. Dataminr acquired Krizo in early 2021 and IBM acquired Omnio in 2022, each about two years after I joined. This chapter tells what the security work was at each company, what customers asked for along the way, and what I learned about security as part of selling. It ends with what the series covers.

Read it on keibisoft.com: Leading security at two startups in a row, both acquired about two years after I joined

Part of the series Building a security program for a growing company.

Watch movies together long distance, while on a video call

Marius-Florin Cristian — Mon, 26 Oct 2026 09:13:53 +0000

Share the movie from your computer with KeibiDrop, or straight from a browser tab. Your partner opens web.keibidrop.com, presses Play, and it starts in a few seconds. Nothing gets uploaded and nothing gets downloaded: the movie plays straight from your computer while you're both on FaceTime or WhatsApp.
There's no account and no subscription, and nobody else can see what you're watching, because it's encrypted the whole way.

From the table on the original page:

2 GB | About 2.2 Mbps
4 GB | About 4.5 Mbps
8 GB | About 9 Mbps

Full version, with the limits and the method: Watch movies together long distance, while on a video call

Source, AGPL-3.0: github.com/KeibiSoft/KeibiDrop

Building a security program for a growing company

Marius-Florin Cristian — Sun, 25 Oct 2026 08:09:11 +0000

This series explains how a company builds a security program and keeps it working as it grows from a webshop to a supplier of public institutions. It follows ACME, a made-up energy monitoring company, through four stages, and at each stage it shows which security work is needed and who asks for it, with its cost. Each chapter is written in plain language, and most have a companion post for engineers.

Chapters so far:

The series index, with the chapters still to come: Building a security program for a growing company

Fastest way to send large files: only send what they open

Marius-Florin Cristian — Fri, 23 Oct 2026 09:53:30 +0000

The fastest way to send a large file is to not send all of it. With KeibiDrop the other person opens your file or folder in place, and only the parts they open cross the internet. If they need 2 GB out of a 50 GB folder, about 2 GB moves, and only those 2 GB land on their disk.
That saves hours of uploading and downloading, and the disk space of a full copy. It works with every app, because the shared folder looks like a normal folder, and in a browser tab a video plays the same way.

Measured, with the conditions on the original page:

2 GB of files from a 50 GB folder | 50 GB moves, about 2 hours 15 minutes, 50 GB on their disk | About 2 GB moves, about 5 minutes, about 2 GB on their disk
10 minutes of a 4 GB, two-hour video | 4 GB moves, about 11 minutes before it plays | About 330 MB moves, and it starts right away

Full version, with the limits and the method: Fastest way to send large files: only send what they open

Source, AGPL-3.0: github.com/KeibiSoft/KeibiDrop

Teleport a folder and nobody in the middle sees what's in it

Marius-Florin Cristian — Fri, 23 Oct 2026 09:53:16 +0000

When you teleport a folder with KeibiDrop, anyone in the middle sees two devices exchanging encrypted data, and that's all. File names, contents, the folder layout and the size of each file stay inside the encryption.
Only the parts someone opens move, so even the amount of data shows how much was opened, and says nothing about how big your files are. Your internet provider, the Wi-Fi owner and our relay all see the same thing: two devices, when they talk, and how much encrypted data went between them.

Full version, with the limits and the method: Teleport a folder and nobody in the middle sees what's in it

Source, AGPL-3.0: github.com/KeibiSoft/KeibiDrop

KeibiDrop 0.5.0, a new website and 1,000 downloads

Marius-Florin Cristian — Fri, 16 Oct 2026 16:21:07 +0000

KeibiDrop 0.5.0 is out, and keibidrop.com has a new home page.

Ever needed a file that’s on another computer? That’s why we built KeibiDrop. Connect your computers and open files as if they were on the one you’re using. You can share files directly, no cloud uploads or accounts needed.

KeibiDrop connects your computers directly: you open a file on the other machine as if it were on this one, or you send it over, with no cloud upload and no account. 0.5.0 brings a new desktop design, better connections and file sharing on Mac, Windows and Linux, and the AGPL-3.0 license. This week the downloads on GitHub passed 1,000.

Full version, with the limits and the method: KeibiDrop 0.5.0, a new website and 1,000 downloads

Source, AGPL-3.0: github.com/KeibiSoft/KeibiDrop

sshfs is slow over a WAN: 1.33 MB/s at every file size

Marius-Florin Cristian — Fri, 25 Sep 2026 20:38:26 +0000

Why is sshfs so slow over a long link? We mounted a Singapore server on a Timisoara server with sshfs, about 200 ms apart, and read files with dd. A 100 MB file came in at 1.32 to 1.34 MB/s over ten trials. A 1 GB file came in at 1.33 MB/s over five. When the rate stays the same at every file size, the round trip sets the speed: each trip carries a fixed amount of data, and a bigger file only adds more trips. KeibiDrop read the same pairing on demand at 20 to 30 MB/s, because it keeps several blocks in flight at once. This post has the setup, the arithmetic, and the one variable we did not capture.

Measured, with the conditions on the original page:

sshfs, 100 MB file | n=10 | 1.32 to 1.34 MB/s, median 1.33
sshfs, 1 GB file | n=5 | 1.33 MB/s, flat
KeibiDrop on demand, same pairing | n=5 | 20 to 30 MB/s

Full version, with the limits and the method: sshfs is slow over a WAN: 1.33 MB/s at every file size

Source, MPL-2.0: github.com/KeibiSoft/KeibiDrop