Nostr Web Client

myself 2y ago

#plebchain

Replying to

jasperc2011

I never convinced my dad to buy. You did better than me.

myself 2y ago 💬 1

You just don't convince people to buy bitcoin. They must convince themselves.

myself 2y ago

Seen on Coinbase 👀

#plebchain

myself 2y ago

https://nostr.build/i/nostr.build_76192808b176ffc6155f3522ab8e7b55e1f952c829beeb034efc92c413e2b6a6.jfif

#plebchain

myself 2y ago

Let's cry together #[0]

myself 2y ago 💬 5

I have some USDC. How fucked am I? #plebchain

Replying to

mark

just moving to more deserving hands

myself 2y ago

💯

Replying to

Blake

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)

Replying to

Blake

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 💬 1

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>

Replying to

Blake

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 💬 1

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.

Replying to

Blake

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.

myself 2y ago 💬 1

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.

myself 2y ago 💬 1