Replying to Avatar Niel Liesmons

I don't know exactly what it is yet, but I'm betting on #Blossom 🌸 (by nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr) to be the most exciting announcement of the #SovEng cohort in #atlantis

Can't wait for tomorrow πŸš€

Here are the slides https://cdn.hzrd149.com/a2d853721eca1c874019c851ae35bd6a3131c950f9028c179890c31bb2561f80.pdf

The app is pretty buggy now and wont really work until there are "blossom servers" running. but hopefully that will be fixed shortly

And here is the github for the spec https://github.com/hzrd149/blossom

Reply to this note

Please Login to reply.

Discussion

How does this differ/improve on IPFS? Is it a better/alt solution for the same problem, or a new solution for a different problem?

Am just getting my head around this.

It only defines a nostr authenticated HTTP API for file storage, I.e. it’s not concerned about synchronization or storage (that could be solved by a number of technologies).

Thanks πŸ‘

exactly what nostr:npub1klr0dy2ul2dx9llk58czvpx73rprcmrvd5dc7ck8esg8f8es06qs427gxc said. This spec only covers three things

1. Identifying files by their sha256

2. Uploading and retrieving files via http

3. Using nostr keys as identities

Everything else should still be compatible with it and could be used to make the servers more censorship resistant

I'm trying to wrap my head around how hypercores (holepunching) fits in or contrasts with this πŸ€”

As in, how would you pull off the file storage of a 3D printable gun in the end?

I don't know as much as I'd like to about hypercores. But from my understanding they are based around a single key pair. Which means if you wanted to reuse your nostr nsec you would have to store all your files in a single hypercore.

Probably could work but I'm not sure how well it would scale.

Blossom on the other hand doesn't have any requirements for all your blobs to be in the same place. So it might be easier for clients or servers to implement.

Thanks πŸ‘