Oddbean

Skeptical, yes, but I think there is plenty of potential value proposition for many implementations of WoT. However, I would argue that it is still being integrated poorly. This is no fault of WoT devs. @nielliesmons is who I would call upon for a good counter-argument in general. I will argue both in favor as well as against WoT because I see things differently, but let it be stated that I am not much of a developer, so my perspective may be skewed. (Warning, this post is kinda long) I had never heard of Web of Trust until I found @straycat on GitHub, and I followed his ideas as best as I could. I basically harassed him to educate me to the best of his abilities about Web of Trust for about one year. At many times his arguments seem very promising but perhaps seemingly short-sighted, though again, I wouldn't place this "burden of proper WoT implementation" on an "amateur WoT dev". I make these distinctions because I believe in the freedom tech movement as much as the next purple-feathered dingo, and I recognize that @straycat wasn't much of a developer either until Nostr encouraged him to keep pursuing his idea of WoT. Watching his progress has been even more satisfying than watching my own. In any case, how this relates to your question- I've been getting to know @cloud fodder and his relay.tools project, and it has me considering what I've thought about Nostr since I got here (~2 years). Relays are flexible as proven by many applications. They can be decidedly ephemeral or attempt to maintain permanence. What impresses me most is the versatility of Blastr. In my mind there will be various structures to the Nostr network which will continue to take full advantage of Blastr indefinitely. When Nostr says censorship resistance, I say BLASTR is the WAY. But not everything needs to be Blasted. So, relay.tools is implementing NIP-42(?) auth which should take care of that and provide ephemeral identities. At this point in my mind, any instance of relay.tools now has the same "problem" of Nostr. "What client is going to integrate with this?" Or, "What does a client with on-demand relays look like?" And, yeah, that's a tough question, cloud. I am fully confident in the direction things are heading. But again, the question. What is WoT for? I think it's for relays. I think with relay.tools we will be able to maintain decentralized distribution of relays that SCALE. And I think it's important that it be done this way. We will be able to create communities of relays based on endorsements from the administrators and users. We will be able to replicate entire collections of relays from one domain to the next. Nostr is a flood and WoT is the wind. It's the direction we choose. The people we trust. It's a trust metric. But I don't trust npubs. I trust heavily endorsed networks of relays, especially when that trust score is heavily procured by my own follow list. By enabling what I call "operational relays" to exist separately with relaytools, we can manage authority structures locally at the domain level, as well as allow users to migrate from one domain to the next, irregardless of client. I believe relay.tools is the future API of scalable Nostr relays and Web of Trust will be our way of sorting signal from noise, down to the personal level, inclusive of client and server levels, and always maintaining total decentralization at the client level, thanks to #Nostr. This is what I see as someone who merely considers themselves a user at this time. When Listr.lol becomes Logseq.lol we will have a better tool for managing complex, personal lists of user data. This kind of application is in development. I found someone on here who is building a client for that too. When I suggested collaborative editing, they seemed on board with that too. The future is fucking BRIGHT king. WoT is not the answer, it is merely our way of filtering signal from noise. But it starts at the relay level. Prove me right or wrong but I hope all of you are aware of how awesome you are. 🍯

Great take! Filtering signal from noise starts at the Relay level indeed. Layers on top that I see: 1. .Communities built on Relays (NIP-29 groups) → Using these as a specific lens / filter instead of your blunt Following List 2. Following Lists → For Web of Not Spam only, not for Trust 3. Specialized Verifiers → Code verifiers in Zapstore for example

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.