BTW. The websocket thing is something I wonder about often. In a use-case with reasonably frequent updates, is it better to have clients hold an active but mostly idle tcp connection (like websocket), or make them do polling, or some long polling?

A proper async IO runtime can probably handle tons of connections at once anyway. 10k, 100k, maybe 1M.

Also with a gossip-like note fetching, it should be feasible to have lots moderately sized relays, without a loss to usability, so maybe worrying too much about scaling vertically a single relay is unnecessary.

Otherwise some client&application level load balancing might fix the problem. Eg when connecting to a relay it answers with a list of keyspace "shards" (possibly overlapping for redundancy), and then connects/queries to the actually node that holds the data. That would allow reasonably simple and flexible scaling of the relays without complex server side load balancing.

one of the slowest parts of receiving lots of events on mobile is actually json decoding. I wonder if it’s time to create an optimized binary transport for nostr notes. Could be a simple TLV format.

Tell us why you hate VS Code.

Anyone have a good TLDR for BRC20?

Elon Dusk

Centralized systems always evolve into social credit systems.

Only a world built on #Bitcoin offers hope for the future.

BTW. The websocket thing is something I wonder about often. In a use-case with reasonably frequent updates, is it better to have clients hold an active but mostly idle tcp connection (like websocket), or make them do polling, or some long polling?

A proper async IO runtime can probably handle tons of connections at once anyway. 10k, 100k, maybe 1M.

Also with a gossip-like note fetching, it should be feasible to have lots moderately sized relays, without a loss to usability, so maybe worrying too much about scaling vertically a single relay is unnecessary.

Otherwise some client&application level load balancing might fix the problem. Eg when connecting to a relay it answers with a list of keyspace "shards" (possibly overlapping for redundancy), and then connects/queries to the actually node that holds the data. That would allow reasonably simple and flexible scaling of the relays without complex server side load balancing.

BTW. The websocket thing is something I wonder about often. In a use-case with reasonably frequent updates, is it better to have clients hold an active but mostly idle tcp connection (like websocket), or make them do polling, or some long polling?

A proper async IO runtime can probably handle tons of connections at once anyway. 10k, 100k, maybe 1M.

Also with a gossip-like note fetching, it should be feasible to have lots moderately sized relays, without a loss to usability, so maybe worrying too much about scaling vertically a single relay is unnecessary.

Otherwise some client&application level load balancing might fix the problem. Eg when connecting to a relay it answers with a list of keyspace "shards" (possibly overlapping for redundancy), and then connects/queries to the actually node that holds the data. That would allow reasonably simple and flexible scaling of the relays without complex server side load balancing.

I need to automatically convert these links to note refs….

nostr:note12044688xrg67tnc2lkv5whwrvycy0y2rsrg6lgd8s8ses2pr57nsfv85x5

i think the choices in #nostr are not only technical, but social and mostly taken from the Bitcoin culture:

1. Open source and open protocol

2. Bips are Nips

3. transparency by default

4. selfhosting relays

5. all you need are your keys.

6. start with a small set of function

7. provide an emancipating tool

8. time it when twitter and co goes mental :) (like 2008 and financial sector)

TL;DR:

nostr reuses basic bitcoin culture to create a basic protocol that can evolve.

one of the slowest parts of receiving lots of events on mobile is actually json decoding. I wonder if it’s time to create an optimized binary transport for nostr notes. Could be a simple TLV format.

Is BLAKE3 really also faster if hardware accelerated instructions are taken into account, like Intel SHA extensions?

Thoughts on #nostr.

Nostr is a websockets-based text protocol for logs of authenticated (but unauthorized) tagged (and otherwise unstructured) messages stored at public relay servers. The rest is a specific nostr application (like social networking or payments) on top of it.

Nostr takes several decisions on possible tradeoffs, which I try to analyze here:

1. Websockets. Good: pub/sub data access, web-integratable. Bad: high load on relay servers limiting scalability. Verdict: ⚠️

2. Elliptic curve (secp256k1) for identities. Good: bitcoin-based. Bad: very low performance, not GPG/SSH compatible, sidechannels. Overall: ❌.

3. Signature scheme: BIP-340 Schnorr. Good: batch verification, standard. Bad: optimized for onchain, discarding y coord, making verification ~50% more expensive than non-BIP Schnorr. Verdict: ⚠️

4. Hashing function: SHA256. Good: standard, bitcoin. Bad: slower than BLACKE3. Verdict: ⚠️

5. Text JSON encoding. Good: easy to implement. Bad: hard to pass & slow to encode/decode non-text/binary data; no limits on data sizing opening a door for DoSing relays and clients. Verdict: ❌

6. No authorization scheme. Good: easy to implement. Bad: limits use cases, limits scalability. Verdict: ⚠️

7. No encryption on the transport level, relying on TLS. Good: easy to implement. Bad: centralized, not end-to-end. Verdict: ⚠️

So I see most of selected tradeoffs by Nostr as a bad or poor decision. This us arguable of course.

Can Nostr survive and success? For sure, if even much worse systems had done that in the past (Ethereum, JavaScript, PHP).

What is the greatest Nostr weakness? Limited scalability and possible DoS (not even DDoS) attacks.

If I were the one who did nostr, what I would had made differently? I would had used Ed25519 signatures on Ristretto25519 (speed), binary encoding with strict limits on data sizes, use Noise_XK encryption - and provide bridges to Websockets only when they are needed for the web. But we have what we have.