Bookmarked. I’ll try to understand how all of this works and fits together.
Nostr unfortunately suffers a bit from not-invented-here syndrome. I mean, there are a gazillion well-known tools to specify APIs with proper documentation, validation, code generation, testing, mocking, etc tooling that can run locally on the CLI, in IDEs, in browsers, or in CI pipelines.
For instance, at first glance I think AsyncAPI would be a great fit for Nostr given the event-driven, JSON-over-WebSocket model. But I guess the devs doing core Nostr development have already evaluated and discarded off-the-shelf tooling. Unfortunately, I don’t know in what channels this sort of conversation is happening (assuming the folks developing the tooling talk amongst themselves to begin with). Again part of the herding the cats problem. If you ask me, communication (or lack thereof) is one thing that needs some love on Nostr. As ironic as it sounds given the amount of communication tools that devs are building over Nostr.
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.
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.
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.
Ok, we are not in the same wavelength at all. Thanks for your services regardless.
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.
Thread collapsed
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")
Thread collapsed
Thread collapsed
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.
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.
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.
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
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)
Thread collapsed
Thread collapsed
Thread collapsed
