Oddbean new post about | logout
 > There seems to be a misallocation of resources in a misguided desire to push various data types through a text protocol.

I don't like the idea of storing 'files or other stuff' on Nostr. You only need metadata. Just like an aggregator doesn't store the songs/tickets/goods itself, but only links to them.

It's not about storing everything on Nostr, it's about indexing everything on Nostr.

Does this point change anything in your line of thinking? 
 After a year, I still agree with you 
 the protocol must remain simple, it could actually be simplified further, like tags being separate from events, for one example

events themselves can be modeled as a simple content addressable store in the same vein as IPFS, and then you can stack the filter index on top of this (i've even considered making a flat file event store because filesystems are very optimized for this)

filters are their own thing... currently NIP-01 covers like 5 separate things, of which three of them consist of another 10 different things each (filters, tags and envelopes)

nostr only uses text encoding for messages because it is convenient for web apps to work with json, but they can also work with protobuf with little extra tooling and be far more efficient over the wire

the more you think about how you can break down monoliths into atoms, the more you realise how flexible and composable it can become