Nostr Web Client

Three new projects were released recently - Wayman, Filestr and Zapworthy, all relying on new data types (kinds). So we now have music, files and highlights data formats (nostr events), all queryable over a common API (nostr protocol). I don't know who needs to hear this, maybe it's just me, but I finally realized it's the true potential of Nostr.

We used to just have "information" on the internet - a presentation-layer (html+css) and custom APIs behind it on every website. Now with Nostr we can access "data" - all data types can have a standardized representation as nostr events and a standardized API to store/query this data from a decentralized swarm of relays.

We already have people, notes, posts, highlights, stalls, products, music, files. All the other stuff will follow - companies, drugs, recipes, cars, TVs, games, excel tables, you name it... All visible to any new app, all addressable, composable into new experiences.

I thought that portable identity was what Nostr added to the internet. Now I realized it's also a data layer.

This is mind blowing! Need to rethink it all over again.

Nice and Kind Vic 2y ago

I see this and want to ask....

Why tho

There seems to be a misallocation of resources in a misguided desire to push various data types through a text protocol.

Sure, you can take anything and encode it and even document a standard for how it's encoded that others can make use of. This is not innovative and has been done decades ago.

But this doesn't make it scale.

Data will either get encoded and centralized through relays where costs have been pushed on others and performance for end users suffers...

Or data owners should just stand up their own servers, and it should be obvious that natural data formats, and specialized data structures like databases are going to be far superior to layers of encoding.

It's like we're repeating mistakes in an effort to just do stuff because we can rather then considering the impacts.

#[0]

Reply to this note

Please Login to reply.

Discussion

Joda 2y ago

That's fair, but also, I feel like we're still in the open-pre-beta, "fuck around and find out" phase. Nothing's permanent, you know. People are just trying "other stuff" with their "notes"...

Nice and Kind Vic 2y ago

Yes. that's true. It is very beta. Need some refinements. Need more external services leveraging login and zaps too

brugeman 2y ago

> 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?

Water Blower 1y ago

After a year, I still agree with you

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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