git lfs

[gedw99]

I wonder if nostr can handle binary images ?

so it can handle git lfs...

[npub1zenn0]

Oh yeah, that's something I haven't thought of. Good thing you bring it up.

nostr-protocol/nips#337 and nostr-protocol/nips#417 seem relevant at glance. I think they're about to use bittorrent, not sure how well that will work out for a git patch, something that you'd normally just drive-by download.

[gedw99]

I just use the local FS or minio / S3.

works great with git and the golang git lfs plugin.

Why not just let the relay use s3 / minio and the end points can use local FS or minio too ?

Is there at architectural reason we have to use bit torrent ?

[npub1zenn0]

Most relays don't expose blob storage afaik. I assume most people don't have access to a global minio/S3 instance that they can push to. So if you're sending the text patch to nostr for free, there's nothing to push a file blob to.

[gedw99]

Right ..

So the relay is just a rendezvous point ??

So a binary / image / blob only needs to be there until everyone has synced and gotten it onto their local ?

It’s almost exactly how NATS obj sore works. Holds a binary for a while until all “ subscribers “ have gotten their binaries . Then automatically deletes the binary on the relay.

[npub1zenn0]

My knowledge is limited here so I may be wrong, but my understanding is that the relay does store text events, as in it stores "notes", but I'm guessing if you try to upload a big file/event then most relay implementations will reject or drop it very quick. So for text it's like a db but big blobs it's indeed a rendezvous point.

However, I didn't read the NIPs in question in detail yet, I would hope the relays will also host the blobs for at least some time. At a glance it isn't even talked about in the documents.

[gedw99]

Thank - I need to read more

[frbitten]

Hello
Just to help understanding NOSTR is a communication protocol, it does not define storage. Each relay is free to choose its way of storing events. Currently most use Postgree or SQLite.

For your doubts, the NIP-95 (nostr-protocol/nips#345) can be used, which is about sending blobs in base64 format.

[gedw99]

Thankyou @frbitten

[npub1zenn0]

Blobs in base64.. With git lfs I reckon ppl have quite big files, like sqlite dbs or photoshop files, so not sure if a full solution. But smaller files like images should work tho.

First thing I need to do is figure out how lfs objects are pulled in the patch workflow 😁

[npub1zenn0]

Some part of the chain needs to support git lfs https://github.com/git-lfs/git-lfs/blob/main/docs/spec.md

I'm not sure which part, probably need a git specific relay. In theory maybe could implement a new command to pull things, but that sounds like a rabbit hole I'd rather not go down.

[npub1zenn0]

I had some more time to think about this one, and I realize that fetching the blobs might not be that essential.

If this tool is used to push the files into nostr, then some existing git host app (e.g. gitea) can pull that from nostr and serve it to users via a regular git pull.

[gedw99]

https://github.com/icyphox/legit Will do it

it’s a git server and web gui without the baggage of gitea .

We can also have a nice ssh experience with it via:

charmbracelet/soft-serve#215

[gedw99]

There’s an issue to add git lfs to legit 👍

icyphox/legit#22

[npub1zenn0]

Yeah any frontend can be used, people can pick whatever service they want the commits to get pushed into from nostr. You could find mirrors of the same repo served on many frontends then. In theory.

[gedw99]

True .. just wanted to offer options for others. I have found legit to be great

legit does not require a git binary on the OS. It’s golang all the way down :)