Not to mention many clients and relays have already blacklisted nip94/95 for the toxic way nip9x enthusiasts are pushing it and brigading unrelated NIP PRs (https://github.com/nostr-protocol/nips/pull/478) which is souring the NIP process for me. Damus will never implement nip94 due to this toxic behaviour of trying to force other clients to implement something that would be bad for nostr as a whole.
Discussion
If plebstr is as good on android as it is iOS I would be using that. I’m jealous at how good and fast it is.
It’s slick AF
Will I don't always see eye to eye with you, but Damus is honestly a work of art.
Nothing to be jealous of man, they're different approaches and suit different people and different primary activities.
It means a lot to hear this from you Will 💜
But there is nothing to be jealous about. Damus is amazing and we are just taking a different approach 🫂
The most important thing is that Nostr wins 🤙
Can’t see the source code and can’t see the network traffic tho. May as well use a centralized service than have so little insight as to who’s gathering info on you.
Thank you 🧡🫂
We have no tools to even moderate this content on relays, even if we did want to try and serve files from the same server that is supposedly going to serve events in a low-latency manner.
How am I supposed to police my relay for CSAM?
How am I supposed to afford running a relay when image uploads quickly get into 100's of GBs?
Nope.
P92 races ahead
If we take aside the nefarious way in which this was launched, and the toxicity of everything that followed, all I’d like to know is: are there better ways of obtaining the same result as what Vitor did, but in a more efficient way?
yes damus implements a backward compatible way to add metadata to images, but does not have full file sharing support yet:
And this would run more efficiently in any client that would implement it?
Its not a replacement. Nip94 can do much more than this hack.
But as of now, it doesn’t. Have you tried #[4] solution privately on your end to compare results? Damus has become lightning fast, not going to lie. This matters for the UX a whole lot.
Yep, I coded a similar solution before I tried NIP-94. It's not as robust, the performance improvements are minimal to non-existent, and it mainly doesn't allow the creation of all the new Nostr micro apps NIP-94 enables.
The only feature it has going for it is backward compatibility at the cost of being stuck in time.
This situation is similar to DMs. The current implementation is safe, but not the safest. We could make a better one, but it's going to break everything because it will have to use a new encryption protocol. So no one is even trying. We have been stuck with it for years. And the more we wait, the more clients implement it and the harder it gets to migrate to a better one because of "backward compatibility"
Nostr is a protocol, not an app. Welcome to protocol development, it's hard.
What I fail to understand is that the NIP was not intended to be used the way you did. I look at some of the authors of the NIP and what they have expressed after your implementation and my mind cannot compute your actions. Why not create another NIP, if this one was not intended to be used this way?
The NIP talks about shared files. File sharing clients. This is not file sharing. It becomes file sharing if I initiate the download. Here you want your users to have the right to force me to download the file being shared.
I am all for new ways of distributing content. But I think all players should be part of the discussion, cannot ask relays to handle a load they did not really agree with philosophically.
Tagging a note here, again, deals with content distribution, or how do we pay for all this.
New custom made NIP pls 🙏
nostr:note16vw58lshntsaf0pl35r67t350c6p052h8wrt4ux4x7429fdvn4dqgjsr7t
That wasn't there until this happened. The text was changed after we ship. The text said "Clients should use this NIP as they see fit".
> The NIP talks about shared files. File sharing clients. This is not file sharing. It becomes file sharing if I initiate the download.
Amethyst is a file-sharing client. It uploads and downloads multiple file types and I am constantly opening up new file types to share. We currently do images, videos, gifs and SVGs, and the next one will be PDFs.
But if you create this new NIP you talk about, I will code it as well.
This was written taking the current description into consideration. I did not see the previous one. So all I need to say about social vs file sharing is there in current description I guess.
NIPs shouldn't limit where they are used. They should simply define an agreed way to write something in Nostr so that Clients don't need to reverse-engineer what's out there.
Are you saying an implementation should not have an agreed upon purpose? My mind is bugging here
Purpose yes, of course. I explicitly said "limit where they are used"
yes. It is much more efficient and doesn’t break images in all nostr clients
I had to put it in my own repo for now due to the toxic brigading by nip94 people. But I plan to resubmit it once they find something better to do.
