The answer to the NIP-94 debate is in the first paragraph of NIP-94…
> NIP-94 support is not expected to be implemented by "social" clients that deal with kind:1 notes or by longform clients that deal with kind:30023 articles.
I get #[0] 's point…
Discussion
NIP-94 is not the first time NIPs have been implemented weirdly.
For example on something as basic as relays - pretty much all clients say they have support for NIP-05 - but do any of them really properly handle the list of relays that's part of that NIP? It's as if those relays are ignored and the only relay list any client looks at are the NIP-65 relays. IMHO, that's wrong.
I get how NIP-65 is important, but IMHO NIP-05 relays should be the ones that are hard coded and NIP-65 should be presented as optional/editable add-ons (if not redundant with the NIP-05 relays). The client can't set the NIP-05 relays - they're set by the website authenticating the user, so they should always be used and never deleted from the user's relay list. But what client does that?
For example NIP-05 validators should be able to enforce the use of things like #[3]'s #[4] - or ensure that their own relay is used by the user. (When corporations start using Nostr they're gonna wanna make sure all their employees' Nostr messages go through their relay).
#[5] #[6] #[7]
The first paragraph was added in the past 30mins... Literally changing the spec without anyone looking at it.. :(
#[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?
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?
I still don't get why Web SRI was not part of notes. Any href references outside of nostr benefits from an integrity check.
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
Does anyone use that in real life for images or is it just for script/css files?
Just for scripts and for good cause.
The use of the SRI integrity attribute is due to the rise of CDN services such as https://cdnjs.com which OS trusted by over 12.5% of all websites, serving over 200 billion requests each month.
Some IPFS sites which are supposedly decentralized, import resources from CDNs, exposing them to risks.