The engine

Built on .lore, not .git.

Git shipped in 2005 for source code. 13 things change once a project is mostly not source code. Every number here is measured: ours on a 3.5 GiB corpus and the live vault, Epic’s from the engineering notes they open sourced with the engine.

2005 · .git2026 · .lore

At a glance

the argumentgit + lfs.lore

01the first wall100MB per fileterabyte-range targets 02the same edit, measured+1.50 GiB, again1.14 MB on the wire 03why: the chunkswhole files64 KiB chunks 04duplicatesevery version wholestored once, billed after dedup 05historyundo windows expireevery save kept, 320 B each 06the save loopadd, commit, pushsave; shared in 0.4 s 07renamesLFS re-uploads the file161 bytes 08press playvideo previews cap at 10MB free154MB plays in 757 ms 09who pays, and how much$81.49 per TB, the owner$59.90, 100GB included 10what a receiver downloadsthe full historythe save you opened 11what a receiver needsgit and an LFS configa browser 12deleting a mistakedelete the whole repoobliteration 13integrityadmin-run verify jobsblake3, always on

01 · the first wall

Files bigger than the rules

git + lfs100MB per file, 2GB per file through LFS on the free tier. Repos asked to stay under 5GB.

.loreNo 100MB wall: the design targets name individual files in the terabyte range.

GitHub rejects a file over 100MB outright, a push caps at 2GB, and previews die long before that: 2MB for most files, 10MB for video on the free plan. This is policy, not oversight: GitHub’s stated position is that repos are for source code. Lore’s design targets sit at the other end: millions of files, histories with millions of revisions, individual files in the terabyte range. It comes from Fortnite, where it ran for years as UEFN’s built-in version control.

receipt: caps: GitHub docs via SHARING_COMPETITION.md · targets: Epic system-design.md

git stops a file at 100MB. Lore's design targets name files in the terabyte range.

02 · the same edit, measured

One megabyte changes inside a 1.5 GiB video

git + lfsgit: +1.501 GiB, 49.1 s · LFS: +1.500 GiB, 12.3 s

.lore1,135,348 bytes on the wire, 3.2 s

Our bounded suite, 2026-08-07, on a 3.5 GiB corpus: one 1 MB patch in the middle of a 1.5 GiB video plus one line of code. Plain git re-stored the video whole. LFS stored it whole again. A tar.gz re-archived all 3.5 GiB in 75.9 seconds. Lore sent the changed chunks: 1,135,348 bytes, about 1,300 times less. The drives have the same disease: one edited layer in a 1GB Photoshop file and Dropbox re-syncs the whole gigabyte.

receipt: measured: RUN-LOG 2026-08-07, bounded suite · Dropbox: SHARING_COMPETITION.md

The same one-megabyte edit: LFS re-sends 1.50 GiB, Lore sends 1.14 MB.

03 · why: the chunks

Files are read as chunks, not as wholes

git + lfsWhole objects. LFS stores every version of a file whole.

.loreFastCDC chunks: 64 KiB average, 32 KiB floor, 256 KiB ceiling

Every file is cut into chunks whose borders are found in the bytes themselves, so an edit does not shift every chunk after it, and re-chunking reuses the old borders wherever bytes did not change. Epic picked FastCDC by saving the whole Unreal Engine 5 source tree into it and measuring; the chunk sizes were tuned afterward on an 8 GiB corpus of binaries. Saving an edit uploads only the chunks that changed: everything the store already holds stays home. The honest edge case: a re-exported PNG reuses nothing, recompression scrambles every byte, while a real insurance PDF put through a sign-style save still reused 82%.

receipt: Epic ADR-00001 and ADR-00010 · PDF and PNG measurement: SHARING_COMPETITION.md

Three chunks changed. Forty-one never moved.

04 · duplicates

Copies of your own files cost nothing

git + lfsLFS stores every version whole: $0.07 per GiB stored

.loreIdentical bytes store once, and billing happens after dedup

Content addressing makes copies free: identical bytes produce the same address and one stored payload. At our 64 GB scale test, 16 GiB of duplicated files and 8 GiB of repeated-block renders deduplicated to about zero in the store. Billing happens after dedup, so pasting a copy of your own asset folder costs bytes of references, not gigabytes. A zip pays full price every time: zipping is what destroys the savings.

receipt: dedup: Epic system-design.md · 64 GB session: ihub/README.md · billing: SHARING_COMPETITION.md

Identical bytes, one stored payload, billed after dedup.

05 · history

Every save kept, because a version is 320 bytes

git + lfsLFS: whole copies. The drives: undo windows that expire.

.loreA version is a 320-byte record of hashes. Keep them all.

A version here is literally a 320-byte record of hashes pointing at the whole snapshot, and unchanged parts are shared by hash, so keeping every save is nearly free: step back to Tuesday’s render, or open any past version straight from the link. The rest of the market caps history because whole copies cost them: Google keeps 30 days or 100 versions, Dropbox 30 to 365 days with a paid ten-year add-on, Box sells the version count as a pricing row, and SharePoint advertises intelligent thinning that cuts your version storage by 94 to 96%. The drives sell undo. Nobody sells history.

receipt: 320 bytes: Epic system-design.md · retention table: SHARING_COMPETITION.md · any version on the link: PRODUCTION-STATUS.md

Every save kept, because a version is a 320-byte record.

06 · the save loop

The folder versions itself

git + lfsadd, commit, push, remembered by a human

.loreSave in your tool. Live on the link in under half a second of work.

The app watches the project and rides the filesystem journal: no directory walk, no re-hash. Measured, edit to shared: 0.38 to 0.42 seconds of work per cycle. And interrupted transfers resume: the other side is asked what it already has, and only the rest is sent.

receipt: watcher lane: RUN-LOG 2026-08-07 · resume: Epic system-design.md

Edit to shared: about four tenths of a second of work.

Measured

1.14 MB

what a one-megabyte edit inside a 1.5 GiB video costs on the wire

161 bytes

renaming that video and moving a whole renders folder

757 ms

to the first frame of a 154MB video, played straight from a link

07 · renames

Rename a 1.5 GiB file: 161 bytes

git + lfsgit: cheap, the blob is reused · LFS: uploads the full copy

.lore161 bytes on the wire

Fair is fair: plain git renames cheaply too. LFS uploads the file again in full. Lore gives every file a stable identity at creation, so the name is just metadata: renaming a 1.5 GiB video and moving a whole renders folder crossed the wire as 161 bytes. And the share link does not change: the address names the project, not a path, so it survives your v2_FINAL phase.

receipt: measured: RUN-LOG 2026-08-07, rename drill · file identity: Epic system-design.md

Rename a 1.5 GiB file and 161 bytes cross the wire.

08 · press play

A video plays from the link. Nobody downloads it first.

git + lfsPreviews die at 2MB. Video at 10MB on the free plan.

.loreA 154MB video played on a public link in 757 ms

Reading a byte range fetches only the fragments that overlap it, never the whole file. So the link can stream: a real Chrome video element on a public share played a 154MB file in 757 ms, survived a deep seek, and the page’s hover thumbnail rides the same range reads. Nobody downloads all 154MB to check the walkthrough.

receipt: range mechanism: Epic system-design.md · measured on production: the one-bucket build log

A read fetches only the fragments it overlaps: 757 ms to the first frame.

09 · who pays, and how much

The same terabyte, two bills

git + lfs$0.0875 per GiB downloaded, billed to the repo owner, past a 10GiB free quota

.lore$5.99 per 100GB block, 100GB a month included

Every LFS download past a 10GiB free quota bills the repository owner at $0.0875 per GiB, which is $81.49 a terabyte. Downloads count against the owner’s allowance here too, honestly stated, but the shape is different: 100GB a month included, then $5.99 per 100GB block, $59.90 a terabyte. The person on the other end of the link pays nothing either way, and our pricing has no seats anywhere.

receipt: LFS pricing: GitHub docs via SHARING_COMPETITION.md · ours: the pricing doc

$81.49 a terabyte, billed to the repository owner, against $59.90 with 100GB included.

10 · what a receiver downloads

The archive, or the save you asked for

git + lfs“A Git clone fetches the full repository history and tree by default.”

.lore“Only what the user’s view requests, with the rest fetched lazily.”

Both of those cells are Epic’s words, from the design doc, consecutive sentences in the original. Their next line grants git its due: partial clone plus sparse checkout approaches this, “but is opt-in and has sharp edges”. The link is the extreme case of the right cell: the browser fetches the file tree, then the files you actually look at, at the version you asked for. Opening an old version fetches that version. On our corpus the tree itself arrived in 0.1 seconds.

receipt: both quotes: Epic system-design.md, the Git comparison section · tree fetch: bounded suite

A clone takes the whole history. A link takes the save you opened.

11 · what a receiver needs

Their side of the link

git + lfsGit and an LFS config, and an account for anything private

.loreA browser

GitHub has no casual receive lane: there is no way to download a folder from the web UI, and even filing an issue needs an account. The link is a page: they just open it in the browser, verified against production, where the files serve to a stranger and a write without credentials is refused. A 128MB project opened whole in 5.6 seconds, and an anonymous mirror of a 154MB public project came back byte-perfect.

receipt: no folder download: SHARING_COMPETITION.md · production checks: RUN-LOG 2026-08-12

Their side of the link needs no account and no install.

12 · deleting a mistake

The one-way door, and the verb for it

git + lfsLFS quota survives a history rewrite. The only purge is deleting the repo.

.loreObliteration: the payload goes, the address and history stay valid

The one-way door is real: rewrite history all you want, LFS objects keep counting against quota until the repository dies. Lore ships the opposite verb: obliteration removes a fragment’s payload while its address stays in the index, so past versions stay structurally valid and a read returns a typed absence, not corruption. The cost is proportional to the file, not to the history. Honest state: the engine has the verb, the app has no button for it yet, and on our hosted store the freed bytes wait on a cross-repository sweep.

receipt: one-way door: SHARING_COMPETITION.md · obliteration: Epic system-design.md

Obliteration drops the payload; the address and the history stay valid.

13 · integrity

Every fragment is hash-verified, always on

git + lfsPerforce verifies in admin-run jobs, after the fact

.loreblake3 on every fragment, checked on arrival

Every fragment is addressed by the blake3 hash of its own bytes, checked when stored and when read back, and every uploaded chunk is re-hashed server-side before it becomes reachable. History is hash-chained: changing any byte of a past version breaks the chain visibly. In our corruption drill, 16 flipped bytes were caught on arrival, the damaged file was withheld, and 245 of 247 files arrived clean. No silent corruption.

receipt: hashing and chain: Epic system-design.md · drill: RUN-LOG 2026-08-07 · server re-hash: INTERLINKED_2026.md

blake3 on every fragment, checked on arrival.

Not our theory

This is not our theory. Hugging Face hit the same wall and replaced Git LFS entirely, moving 500,000 repositories and 20 petabytes onto content-defined chunking at a ~64KB grain, measuring 30 to 85% reuse across checkpoints. That is the grain Lore uses, and the reason a 1MB edit inside a 3.5GB project crosses the wire as about 1.1MB.

Lore, formerly Unreal Revision Control, versions Fortnite islands in UEFN today · Epic open sourced it · we host it

Try it on your own files. Free forever.

The desktop app versions a folder as you save it and shares it behind one link. Hosting is the only thing that costs anything, and the free plan hosts two projects with no card.

Download for Windows See the pricing