Nostr Web Client

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.

Reply to this note

Please Login to reply.

Discussion

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")