The first paragraph was added in the past 30mins... Literally changing the spec without anyone looking at it.. :(
Discussion
#[5] what happened to that decentralized GitHub replacement cuz this situation^ doesn’t seem great
#[6] that was very Vitalik of you. You know best eh? Should let the market, aka this ongoing argument, sort it out. Makes me respect Samourai team for disparaging the BIP paradigm more when asked to make a formal Stowaway BIP, it is not bottom up.
still no takers as far as I know
back in january I started working on a github replacement.... until I saw the bounty get posted;
I thought it would immediately get filled so I moved on to other stuff
can't believe it's April and it's still not ready
My team and I are working on it daily. Adding large file support in a secure manner is not easy. NIP-94 will not working for large files like repos due to delay attacks. Great things take time.
Awesome! Thoughts on this protocol for file transfers? nostr:note1es4674ajsdp3n5w8asyhdt3d7qkcdw4rpalkhkuglj74nljh8pvsn0nlhm seems like a new approach at the very least
I saw this the other day. Looks overly complicated. We’ve evolved Merkle DAGs significantly. Excited to share when it’s ready. You’ll see! I promise it’ll be worth the wait.
I agree
I don't think a github replacement should be a bounty itself: it's too large a project imo
are you planning on keeping the repo itself on relays???
I disagree. It’s the only way I was able to motivate a few other coders to help me with the project. Robin at ZeroSync even cracked Sats4File — a way to atomically swap files for coins off-chain over Lightning.
Yes, repos are stored on relays — but it isn’t quite that simple. We’re creating a layered architecture. It will take a few more months, but I’m hoping an open-source beta will be ready by November.
Can you link the repo? Would love to see the building process and everything you and your team have already come up with.
It’s too much of a mess right now. We’ll open-source everything when it’s ready. Satoshi released a solid paper, then functional code. We’re following the same style.
Thought it would not be open source yet or I would have found it by now. So does that mean you're communicating with the team privately also?
Satoshi posted super shitty code too; he didn’t wait to make it all nice, and pretty and functional
I don’t understand the approach of building it in stealth mode, honestly;
don’t you think your approach/designs/implementations might benefit from people who are not exclusively in your team?
Super shitty code that worked, though. Everyone can critique our alpha/beta when it’s ready. I’ve chatted with Naval, Robin from ZeroSync, and other people I respect/trust about the fundamentals already.
ok, so sounds like you consider that you've discussed this with enough experts to not benefit from opening the designs
ok, sure, let me ask you this, then:
do you not feel like opening the architecture/design might help inspire building some other stuff?
I honestly don't understand what's the reticence to opening it up, is it that you want to prevent others from copying it or something like that?
What are you talking about? I’ve opened up a ton about it. I wrote about it on Twitter before the bounty even began.
We’re not releasing code until it works, that doesn’t mean we’re being secretive about how it works. Just read the paper: https://medium.com/@colbyserpa/nostr-2-0-layer-2-off-chain-data-storage-b7d299078c60
Wait is not open source now?
Did you take a peek at Fossil ?
Why isn’t docker a good alternative to GitHub as it supports open source and the code can run in clean environment too?
That's not changing, it is clarifying.
What happens if void.cat, nostrimg.com and nostr.build suddenly goes dark in one's country?
Use a client that caches the images. (Most of the popular ones do - at least to some extent). That way you’re retrieving the image from the server you can’t get to.
Or use a VPN.
This is why we need NIP 95: Decentralized storage of these datasets.
Oh please no!
Files do not belong on relays! Find some other solution and have Nostr support it. But no files on relays!
Nostr doesn’t need to go absolutely everything.
Everything will be on relays. It's just a matter of time and enough scale.
Hopefully not nostr relays which are not designed for binary data.
Specialized relays will appear. But in the meantime, everything goes into the regular relays.
Regarding text files, which is 99% of git repositories: Has there been any discussion about tokenizing the files and then storing the token “chains” separately from the token values? It would help with compression and redundancy. Might be shit for performance though.
I don’t agree with this at all. It’s way better to just put file metadata on relays and have file data hosted elsewhere. Not only for performance/scalability reasons, but also to minimize legal liability for relay operators.
Well, that's the beauty of nostr. Anyone can start doing it and there is very little we can do to stop it.
Indeed :)
After sleeping on it I’ve kinda changed my mind. I’m now favoring #[2]‘s approach. It gives accessibility options and if the file is changed or goes missing (404) then the relays can be queried for another URL for the same file. That’s kinda major. That to me is backwards compatibility and worth the hassle of the change.
Still, if we have the file data hosted elsewhere, shouldn't we at least have integrity hashes embedded within the metadata of kind:1 note?
Not funny if everyone's past notes start showing porn.
So for this exact reason, NIP-94 includes metadata allowing clients to load files from peers via BitTorrent if all hosts go offline.
Oh… Hmmm… So yeah, if that wasn't there yesterday when you deployed NIP-94 support, then it changes things a bit.
I'm kinda in the middle of the debate. I get where you just did an embed in a Kind 1 event (a pretty reasonable way to implement it). But I get where others are saying "don't mess with images" (because they're such an important part of the interface).
And I get your accessibility arguments, though I wonder how often people will include enough detail to help with accessibility (people are lazy). Still, there's the ADA and sites can be fined for not handling accessibility issues - so you at least letting the blame fall on the users rather than the apps seems like a good approach.
And I get where knowing if a file/image changed is important - but how often is that an issue - especially for a casual pic in a social media post?