Oddbean

Thank you for your response! I tried to zap you but am having an issue apparently. In any case, upon review of NIP-29, I disagree with this part. I can see where it's coming from but I don't think relays can operate as a divided community. Rather, I think relays are individual communities. In my mind, consolidation into archival or decay is the natural progression of conversation, and I think primarily relays are used to transmit conversation. The other stuff would be, like lists, and operational data, protocol-based stuff. As it stands we can embrace protocol-wide communities by empowering relay.tools with a client that enables this. As a simple start we can merely opt for affiliated relays. If I begin a community about mushrooms, and someone else begins a community about specifically red mushrooms, it makes sense for both relays to affiliate with each other to encourage growth and distribution of content. This begins with operational relays, at the domain level. Various protocol data can be broken up and managed in a decentralized construct, while being hosted and controlled in tandem. This allows for flexible navigation and management by users. They decide what level of the protocol they wish to exercise. They decide when to migrate, or when to post, or delete, or make changes. By doing so, we can store the NIP-51 lists of affiliate relays on an operational relay for the host of the example relays. For instance: I start a website called foragers.dev I spin up an instance of relay.tools I decide I want to host three relays: n/Foraging n/Growing n/PenisEnvy Upon initialization of relay.tools (in theory), you would be prompted with the ability to offer multiple domain-level relay configurations. I can't begin to imagine all of the potential stack flows of Nostr servers, but I can imagine that there would be more than one, depending on the client's goals. Everything you can separate to its own relay reduces the load of the "initial operational relay". So let's start with the primary relay, which will initially operate as the basis for the domain itself. n/Foraging would offer the "total suite" of operational relays. The user would decide if they want to separate any particular data on their own accord. But initially they will configure their own stack if necessary. n/Growing would be (in this example) a resource-based relay. Let's say I aim to fill this section with guides for growing healthy mushrooms. My users are happy to help embrace this goal and we all decide there are some other useful relays we want to affiliate with. But, oh no! Their relay isn't hosted on our server! That's okay, because collectively, the users will form a list of the most relevant relays, and they will publish it to the domain-level operational relay. This will allow the domain to know who to advertise, specifically on behalf of a single relay, and only in congruence with the specified relay. Think of this like one subreddit recommending a list of recommended subs. When the relay gets deleted, along goes the domain-level lists that went with it. If a relay migrates? Initalizate a migration (in theory). The destination relay is hosted with relay.tools ? Great, it recognizes the signed events, and authorizes the initial instance of relay.tools to Blast those relevant domain-level events. And Web of Trust? Well, that becomes a domain-level operation.