Nostr Web Client

It’s a critical take on Nostr, but if we distill the core innovation - it’s the simple cryptographic Event JSON payload - and the protocol’s openness.

Websocket relays are ok, but Nostr can work over hybrid p2p or REST. The query engine is ok, but it’s basic and has design faults and limitations.

So why write this post?

I think we can expand on todays relays and evolve the event transport layer, likely to many simultaneous methods including a p2p layer, and greater privacy.

I think we can reimagine the event query engine, allowing for more performant and expressive queries. Perhaps GraphQL, maybe feature from new streaming databases like SurrealDB.

I think if we open the box a little more, we can start to explore new and powerful innovations that can expand upon the NIP-01 primitives.

If we start to experiment and challenge ourselves to discover new ways to make Nostr unstoppable, I think we will find amazing new capabilities are possible and bring forth a wave of communications innovation.

Reply to this note

Please Login to reply.

Discussion

Andrew 2y ago

I’m intrigued by this P2P layer you mentioned, I’d love more details on that!

Blake 2y ago

I don’t have the answers today. I experimented a little in the past with hypercore. I didn’t enjoy it.

I’m hoping others with p2p interest or experience can try experimenting too. I’ll continue, but at a slower pace.

Not everything has to be p2p. And we have a p2p payment mechanism now, so p2p could also mean value for value. Lots of possibilities.. we just need to experiment and try crazy ideas.

Komi_Hartman 2y ago

The key to creating a profitable solution for #Nostr would be to build upon its core innovation while addressing its limitations & design faults. By doing so, Nostr could become a more "powerful & versatile" platform for "managing & analyzing data" across a wide range of applications and use cases.

Incorporating "machine learning algorithms" for predictive analysis or integrating with blockchain technology for secure & transparent data management could create entirely new use cases & applications for Nostr.

So, by continually evolving and improving upon the core primitives of Nostr, the platform can remain "relevant and valuable" to users, while also opening up new possibilities for "data management & analysis" in the future.

theGig 2y ago

I am still keeping an eye out for P2p media sharing with holepunch hyperdrives broadcasted over Nostr :)

OpenSourceOptimist 2y ago

Sometimes it's is simplicity and limitations that foster the greatest innovations. In many cases less is more.

Blake 2y ago

I agree.

The challenge I see however is being honest, centralisation is easier. Decentralisation is harder.

Many things solved for big tech doesn’t work well for decentralised (discovery, spam, data persistence, availability, etc).

We basically need to reinvent ways to do these things - and often on smaller lower powered devices like mobiles.

Until we can make things simple, sometimes we just need to make them work first.

OpenSourceOptimist 2y ago

Decentralization is really hard. But I am sceptical the solution lies in the buzzwords I hear at work.

ElectronicMonkey 2y ago

I agree. the core protocol should decouple from the transport layer. it is good to have a websocket impl at first stage, but it is unnecessary to be limited to it.

Oscar 2y ago

棒，不能自嗨，Nostr需要不断进化。🧬If we start to experiment and challenge ourselves to discover new ways to make Nostr unstoppable, I think we will find amazing new capabilities are possible and bring forth a wave of communications innovation. 👍

Blake 2y ago

As a reference too, I haven’t tested it yet for Nostr, but hear great things.

“SurrealDB is an end-to-end cloud native database for web, mobile, serverless, Jamstack, backend, and traditional applications. SurrealDB reduces the development time of modern applications by simplifying your database and API stack, removing the need for most server-side components, and allowing you to build secure, performant apps quicker and cheaper. SurrealDB acts as both a database and a modern, real-time, collaborative API backend layer. SurrealDB can run as a single server or in a highly-available, highly-scalable distributed mode, with support for SQL querying from client devices, GraphQL, ACID transactions, WebSocket connections, structured and unstructured data, graph querying, full-text indexing, geospatial querying, and row-by-row permissions-based access.”

https://github.com/surrealdb/surrealdb

myself 2y ago

This is offtopic but isn't it strange that Nostr uses a JSON-serialized string to calculate the event ID/signature? It's somewhat vague as different implementations may serialize the same object differently (e.g. due to escaping). Maybe something binary would have made more sense.

Blake 2y ago

I had concerns too, but I haven’t yet seen one complaint about failing/invalid event ids.

Here is the extract from the NIP-01, which strictly defines how the hash digest must be formed prior to hashing the event id.

myself 2y ago

It's not that strict. It only says that the encoding is UTF-8 and that there shouldn't be white spaces or line breaks. I have seen different implementations serializing the same object differently for example when you use stranger characters like emojis. So here when you calculate the event ID/signature you have to pay attention on how the rest of the clients will serialize your object so that their calculations will match yours.

Blake 2y ago

You can look at some Nostr library code and open source apps to see how’s it done today.

Certainly could be more strict. But it leverages existing JSON programming language libraries, which likely have already mostly standardise.

The signature is only signing the event id, not the serialised event. But again, I’m yet to see any issues in the wild.

myself 2y ago

The signature signs the whole object (minus the signature of course). Let me quote NIP-01:

> "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>

Blake 2y ago

https://github.com/0xtlt/nostr_rust/blob/main/src/events.rs#L127

https://github.com/scsibug/nostr-rs-relay/blob/master/src/event.rs#L359

myself 2y ago

What's your point? They are all signing the hash of the serialized event data (the whole object basically)

CheezeGrater 🇿🇦 2y ago

#[0]

mchotbot 2y ago

Your post is being well-received.

Added to the https://member.cash/hot feed