How feasible would it be just to feed this article into Shakespeare and say “have at it”? #vibestr

Decentralized curation of the entire nostr protocol. This can probably be implemented pretty quickly with our existing tools.

Here’s a little theoretical physics paper I published back in 2008. One of my motivations for building WoT is to help me find other people with similar intuitions so we can develop these ideas further. https://fondationlouisdebroglie.org/AFLB-333/aflb333m533.pdf #physics #wot

on the impact of bitcoin on culture and creativity cc:

To bring WoT to nostr, we need two primitives: 1. a way to ask questions 2. a way to answer them or, stated another way: 1. a way to represent information 2. a way to curate information or, stated another way: 1. the concept graph 2. the grapevine or, stated another way: 1. Decentralized Lists (Custom NIP) 2. NIP-85: Trusted Assertions or, stated another way: 1. math 2. physics https://nostrhub.io/naddr1qvzqqqrcvypzpef89h53f0fsza2ugwdc3e54nfpun5nxfqclpy79r6w8nxsk5yp0qyt8wumn8ghj7un9d3shjtnswf5k6ctv9ehx2aqqzdjx2cm9de68yctvd9ax2epdd35hxarnwrn9hx

I want to take a step back and consider a bigger question. It’s related and I don’t know the answer. Currently, a wiki entry or nip nip can be edited by the event author. So how can we enable the community to edit an existing NIP? One way would be something like git versioning, where your WoT decides what gets merged, but idk if that can work and even if it can, we’re far from ready to implement it. So here’s another idea. Take NIP-73 as an example. Take the existing version and express it using the nip nip. But we don’t copy the whole thing verbatim. Instead, we replace the table of Supported ID Types with a Decentralized List, one for each type. Each list item adds a row to the table and maybe also includes a corresponding explanation and example. So when it comes time for you to propose support for NIPs, you simply add another item to the list of supported types. The complexity would be we’d need a script to ingest the curated list and spit out a markdown file. We’d have to figure out how to make that work. And we will need to implement vanilla list curation first.

GM nostr! ☕️ ⛅️

Is this what people will use to manage their relay settings and relay tools account? Or more general purpose than that?

Gm! 🌞

If a reaction to an addressable event points to an e tag and that’s it, then I agree, that doesn’t make sense. If it points to the a tag as is the norm, then we avoid that problem of orphaned reactions. If it points to an a tag *and* an e tag, then we have an option that doesn’t exist if we use the a tag alone: Alice might choose to interpret a reaction to an outdated version as equivalent to a reaction to the current version; Bob may choose to interpret them as not equivalent. The first interpretation errs on the side of being too lax, the second of being too rigorous. Under standard practice, the first interpretation is the only choice.

By two event kinds you mean as a wiki entry or using ‘s NIP NIP. For now, the NIP NIP has advantages over the wiki entry method, like a specialized way to list all event kinds used by the NIP. Are the NIPs at the top of NostrHub pulled directly from GitHub or are they wiki events?

And our goal is to stop publishing NIPs on a GitHub repo. I know you want backwards compatibility, and your changes to kind 17 allow that, which is fine. There’s going to end up being multiple ways for people to express their thoughts on custom NIPs. You have kind 17, maybe someone does kind 7, we’re going to need one or more methods for people to express more nuanced opinions than a simple binary up or down. GrapeRank can take them all in.

not appropriate? If Alice writes some piece of content that is a parameterized replaceable event, Bob likes the content, and then Alice updates it, I may want to know whether Bob liked the current version or a previous version. Suppose Alice turns out to be a bad actor. She vibe coded a good NIP, got some likes, then swapped it out for spam. If Bob endorses spam I’ll be inclined to think maybe he’s a bad actor too, but how do I know whether he liked the spammy version or a previous (non spammy) version? You’ll point out that the old event will be discarded, so we won’t be able to find the old version, so we won’t know what he liked. If so, we’ll at least know whether Bob liked the current version or some previous (no longer existing) version, information which may be useful even if it doesn’t tell the whole story. And there’s also the possibility that older versions of parameterized content get stored by design for some particular set of use cases, even if that’s not the usual practice.

Is this a relay on android or an android app that talks to a remote relay tools server?

Here’s a question: how should we go about transferring existing NIPs from the old system to the new? Would we like original authors to do it, since they’re replaceable events? Which just now makes me wonder: when we like or dislike a NIP, should the kind 7 event have both an a tag and an e tag? And leave it up to users to decide whether to pay attention to one or the other or both?

This was my introduction to Safebox. Very interesting.

4:20:69