nekomimi.pet
+27
README.md
+27
README.md
···
1
+
# pds-lfs
2
+
3
+
git-lfs works in two ways. One is that it simply declares where files will be hosted. Its derived from the origin remote. For github as an example, it would be `https://github.com/foo/bar.git/info/lfs`. Then files, when commited to the repo, are tracked as pointers to how they're stored on the LFS remote.
4
+
5
+
Here is an example of the pointer
6
+
```
7
+
version https://git-lfs.github.com/spec/v1
8
+
oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393
9
+
size 12345678
10
+
```
11
+
12
+
This is what gets tracked in Git's history.
13
+
14
+
I propose a similar system for atproto records to use to define where blobs larger than 100MB are hosted. People can declare a `com.pds-lfs.host` record declaring a pds-lfs server (or alternatively just ipfs://). And then a `com.pds-lfs.pointer` with fields like
15
+
16
+
```
17
+
{
18
+
"$type": "com.lfs.pds.pointer",
19
+
"cid": "bafybeifzrx7dbmdrorwzye4f3w6slbm6a4pchoexwhfgbgqjh7fwkwvyyq",
20
+
"mime": "image/png",
21
+
"size": 206868,
22
+
"filename": "ljtw.png",
23
+
"updatedAt": "2025-08-17T19:49:10.154Z"
24
+
}
25
+
```
26
+
27
+
I initially wanted it to be IPFS first and only, but IPFS is a complete PITA to work with. An issue with centralized pds-lfs servers is that theyre truly not in control of the user, and I would have to figure out how to do cross user auth that a user can then attest that they own the blob uploaded to a pds-lfs server. Leaving this up to garner ideas.