Thread
Quick thoughts on NIP-95 in no particular order:
- There isn’t anything anyone can do to prevent someone from putting files on a nostr relay. It doesn’t matter what you think of the idea.
- NIP-95 does not belong on the majority of relays (perhaps all) that exist today. If it is ever adopted it will be by specialized relays (likely operated by existing http image hosts) who are willing to give up efficiency for some interoperability gain. I think it is naive to write off the entire spec because it doesn’t fit in to our idea of nostr today.
- Relay operators deserve notice before something like this is released in a major client. I know that won’t be possible forever, but while our ecosystem is still small it wouldn’t take much to get the word out. I think a lot of the reason for the controversy (client rendering aside) is that files were “forced” upon relay operators before most of them even knew NIP-95 had been proposed.
- Open source relay implementations should probably be a bit more selective about the type of events they accept with how quickly nostr is evolving. There may be plenty of other event kinds in the future that you also do not want to store for one reason or another.
Replies (6)
If binary data is stored on relays I wonder how this would play with copyright content and take down notices lawfully speaking. Relay operators would then need management tools to find and filter such content and have them removed if needed.
I also read from the NIP that it could be implemented to store in a NoSQL DB for large documents or on disk for files.
For sure, and all big public file hosts are already using these tools. They are definitely best suited to operate these special purpose relays.
Great points! - It seems to me that it's likely that the relay operators could assign admin privileges to a select group of individuals to run a given 'cloud relay,' though I image now we'd be discussing a subscription or paid service of some sort, but if this were the case, a group of a dozen of so people could run a pretty robust relay around the clock to respond at need to critical events. But the data itself would be literally roving about the globe based on the cost of available processing capability and storage capacity.
I appreciate this thoughts and your sharing! -- Just something that my mind associated with this engineering/lite-client/storage issue; there are emerging project(s) that will allow for distributed computation and storage that are currently running on centralized server farms - this will allow for decentralized cloud based options for running distributed, non-local, nostr 'roving cloud relays.' Ha!
IMO, kind 1064 and 1065 should be blocked by default in relay implementations as they are interntionally used to store files. Let relay operators actively decide if they want to store everyones files on their harddrive.
Kind 1063 seems ok, as it’s basically like a mapping or lookup metadata event. It’s not designed to store data, but basic properties and how to fetch it elsewhere.
However kind 1064 storing files on relays is a bad architectural approach for a few reasons.
1. Events are stored in DBs today. DBs hate binary (in general). We have enough text based data to try make fast and efficient - especially when we 10-1000X.
2. Relays need to be lighter weight to minimise the cost of running them.
3. We don’t want to encourage the vector of DDOS or fill relays disk space denial of service attacks. Or even promote storing encrypted blobs of file chunks - like in DMs.
4. We need a general purpose distributed and decentralised file storage system anyway - Nostr can piggy back off it when we solve that problem.
5. Files create more attention for geographical regulation. Hosting issues. Vector of DCMA fraud. Etc.
The main issue today is client compatibility and breaking user experiences - with something that common sense tells us cannot scale or function as intended.
