> 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 

 What are the Lagrange browser and the Gemini Protocol?  

 🟣
https://i.imgflip.com/7jsv9b.jpg   

 I don't really see the point 

 It enables you as a user to define your own experience. Currently web is all sorts of colors and themes and shapes, that you can't really adjust. Letting users and their "clients" own the experience instead would be in my opinion interesting experiment  

 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