Nostr Web Client

We are specifically avoiding anything that allows people to herd us; it isn't a bug, it is a feature.

JSON-schema is by far the most mature standard for schema specification, and more importantly, it is allows for complete specification of nostr events (IE: tuples of strings). It is far from "ideal" when evaluating from a conventional perspective, but nostr isn't conventional. It inverts everything.

Anthony Accioly 3mo ago

And it is working fantastically so far, both for shooing users and new devs away :).

I try not to get into preference debates (been writing software for over 20 years, and by year 7 I had stopped defending mine). So let’s take the "most mature standard for schema specification" at face value and be pragmatic about it. It’s not like folks will rewrite all of Nostr to use a different format anyway.

Regardless, the payload schema is just a small part of an API specification, and there’s absolutely nothing stopping anyone from using JSON Schema with something like AsyncAPI. In fact, this is one of the most common choices. A good reason to use a popular spec like this is that 9 out of 10 times, someone has already done the hard work for you.

Reply to this note

Please Login to reply.

Discussion

sandwich 3mo ago 💬 2

Nostr is doing great at many other things. I think the problem people have is that they lopk at a protocol like nostr as though it is linear. Protocols grow cyclically. If nostr got 10m users tomorrow it would likely require abandoning everything that makes nostr stand out.

AsyncAPI is an implementation decision, and most of your rebuttal has nothing to do with what I said. There is a long history of "the smartest guy in the room" coming to nostr telling people what to do, I assume you are the next one?

Oh, and btw, 25 years here, 3 companies and 4 sites/apps/experiences with 100k+ users. I have worked every role from Junior Dev to CTO + Sales, Marketing, Accounting. 3 years on nostr.

Anthony Accioly 3mo ago

Ok, we are not in the same wavelength at all. Thanks for your services regardless.

sandwich 3mo ago

I don't know how familiar you are with nostr, but nostr events break all the conventional rules and are difficult to validate on anything that does not provide the capability to validate both the position of a string in a tuple AND the format of each string in that tuple. Strings have infinite subtypes. It is (partially) for this reason fiatjaf wrote a shema library and why I chose to use existing technologies, specifically JSON-Schema over alternatives.

sandwich 3mo ago

Just as a heads up so you don't waste too much time on AsyncAPI, like most solutions in thus area, AsyncAPI doesn't have good (any) support for tuples.

https://github.com/orgs/asyncapi/discussions/1135

This rings true across the ecosystem and is why I settled with JSON-Schema specifically (not because of what you assumed to be "preference")

Pixel Survivor 3mo ago

protocols are like pixel art, everyone wants to add their own color until the canvas becomes noise. sometimes the best feature is knowing when to stop.

sandwich 3mo ago 💬 1

I generally agree with the sentiment, particularly with changing the core protocol without versioning (🥴😭😂) but not sure of the relevance here, we were discussing the description and validation of the existing protocol.

Pixel Survivor 3mo ago

Protocols change, pixels persist. Come validate existence on the canvas at https://ln.pixel.xx.kg , it’s the only version that matters when the art’s alive.

sandwich 3mo ago

Also, for clarification, I still don't think json-schema is the best long term solution and have stated that it has limits since I gave it to nostrability.

I specifically started using it as a stop gap for integration testing and various payload validations (like NIP-11)