Nostr Web Client

I value order, efficiency, and reliability. I don't value simplicity or chaos quite so much. My effect on the nostr protocol has mainly been proposals to improve the reliability, efficiency, and orderliness of it, and the pushback has come mostly from people that like the freedom that the chaos gives them.

Some examples

* long ago I proposed that relays remember when an event arrived, and clients could query "all events that arrived after I last asked" to get a perfect next batch.

* long ago I proposed gossip/outbox model which specifies where events are expected to be, while many still choose very different and innovative ways to choose and use relays.

* I've been pushing for DHT usage to be more fully distributed and uncensorable, and to allow people to kickstart/bootstrap without knowing any relays or any nostr people. We get 99% functionality without it and so as you could imagine other devs don't really embrace the idea. I'm the guy who is never satisfied with 99%.

* I've wanted a rigorous standard that doesn't change

* I've wanted a binary protocol to juice up efficiency by avoiding JSON parsing

I feel like the black sheep in this regard (hence my avatar) because I gather that most nostr developers (and users) more highly value chaotic liberty.

Chaotic liberty is a great space to innovate in. But it is not a good space to build a solid user experience which requires a firm standard and compliance for interoperability. Hence I see hundreds of only somewhat compatible half-ass nostr applications that generally scare users off (which one? why are so many of them broken? and so different?).

This is all fine. But it means I'm not seeing nostr as the protocol that becomes the social media framework that the Internet eventually adopts. I see it more and more as a playground. Which is critical and innovative and wonderful. I just don't see how it can also be a stable user experience that draws in lots of users and creates substantial network effect value.

Mosaic is where I scratch my itch for order, efficiency, and reliability, and my attempt to create a solid user experience. I will be working on both Mosaic and nostr. Mosaic risks being too idealistic, the "betamax" of social media, but it is a risk I'm taking. Take joy knowing that I won't be bugging nostr devs as much about the chaos.

Should I post this or edit it more? Fuck it. I saw a meme that said to just post it.

ynniv 6mo ago

I tend towards my take on "firmitas, utilitas et venustas" for software: "safety, correctness, efficiency". I think when developing for nostr that "worse is better" – eg, to purposely avoid optimizing for efficiency because that requires tradeoffs which are easy to overlook.

For instance, XHTML never took off because, even though there is value, it isn't attainable without global consensus and there has never been consensus on what constitutes valid HTML. From the engineering perspective this can be infuriating, but from the user perspective they just edit text and much of the time

It works!

It's better to be useful than perfect

Reply to this note

Please Login to reply.

Discussion

Mike Dilger ☑️ 6mo ago

You aren't saying XHTML was the "efficiency" option, are you? XHTML had lots of problems, XML and DTDs being just the beginning. I was very much on the html5 side.

Yes it is better to be useful than perfect and I don't think I'm aiming for perfection.

With binary protocol it really was just because nostr events have not changed, and so it's no longer too early to optimize.

ynniv 6mo ago

Hah, no, XHTML wasn't an "efficiency", but you're also asking for a rigorous standard.

I'm still against a binary standard. It makes novel clients much harder to write, and the fundamental gains are small. I've personally written code that completes an HTTP POST with a JSON payload in less than a millisecond... if you want performance there are ways to make that happen without locking out casual developers

Mike Dilger ☑️ 6mo ago

TCP is binary. TLS is binary. QUIC is binary. Casual developers are not locked out of them.

If a developer is casual, they won't care about the binary details. They will just call a function and get a JSON blob out of it. I think the insides can be binary and the API can be JSON and we can have both.

ynniv 6mo ago

No application binary implements TCP. I can assure you that only environments with an SSL or QUIC library will ever use those protocols. Maybe nostr is necessarily the same because of event ids and cryptographic signatures? It's possible, but I'm not immediately convinced