Lol @ asteroid btw

I run knots and core. They are both neighbors and peers. Nothing is broken.

Sshhhh

And wss://purplepag.es is a blackhole?

No, it doesn't directly resolve it, but it is the right approach. All your examples are still technically relays, the issue is you have no way to clasify or express them. Adding an arbitrary number (2-3) of new terms and eliminating usage of the term "relay" might address the stated issue, but creates new ones. What are those 2-3 terms? How are they defined? What percentage of alignment does a *relay* need to be a _____. What if there is a relay that us a combination of all 2-3 types in some way in the future?

Nostxyz 😂

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

...HAHAHAHAHAHAHHAA

Well, community relays are just a relay that exhibit particular behaviors and restrictions; any combination of those (and other) behaviors and restrictions could be atomized and expressed programmatically. How those behavior and restriction flags are defined could be tricky, but it would be far easier to maintain an array of flags in say NIP-11 than it is to constantly update the named properties (such as restricted writes) or to try to group those features under some atomized property. The methodology of using feature flags instead of named properties was one of my motivations behind signaling that we might consider splitting NIPs, which IMO should be specifications that affect relay behaviors from data schema specifications (what I called NAPs); they have different implications, different draft tracks and require different levels of scrutiny. IMO they are relays, as they fit the technical definition, but we shouldn't call everything just a "relay" and there needs to be a way to disscern one from the other. IMO your work on relay types was a good start to this.

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.

I have thought about this for years, but it was way to early to attempt to atomize relays. Seems like now is a better time + you already started this effort more than a year ago, no?

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.

I have ubuntu touch on my lineage edition pinephone. quite good, but you need to write your own appsif you want to do anythinf and build them using out of date toolchains 😔

did a pretty good job with this in the nostra protocol/nips repo; I believe it was an issue not a PR.

Your meme is lame

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)

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.

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.

I feel like I could make better propaganda than this and I haven't really been paying attention. D-