Nostr Web Client

There is a general blueprint for nostrCI suggested by nostr:npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx in schemata https://github.com/nostrability/schemata

Being not dev literate, my hope is with nostr:npub16ux4qzg4qjue95vr3q327fzata4n594c9kgh4jmeyn80v8k54nhqg6lra7 and nostr:npub1xzrkzsrnr83vn7h0udq6tnapwpswy5equlrtkn3nu0e0anlmzynqne0qap to tackle nip-10, and marketplace nip JSON validation schemas, respectively.

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 was also looking at this

nostr:nevent1qqs2n47k008wxkw7xf5uaz3ja3aeeg8jhlt75evxusr5h85dwwwh32cpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgq3q80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsxp7anh

Anthony Accioly 3mo ago

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.

Reply to this note

Please Login to reply.

Discussion

sandwich 3mo ago 💬 6

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.

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)