There are so many things to replace! The question is how exactly to do it. And also, which thing(s) to try to replace first. Obviously start with simple things, so we can tackle the first question: _how_.
(How to do … what? How to recreate all these things in a truly decentralized fashion.)
My argument above was that we are probably irrationally shocked by the data volume of things we want to decentralize.
Collaborative curation would be awesome and we could start small but maybe not too small. I would love to move the nip registry onto nostr. Let nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 maintain a list of nips and other approve of the list or not. How hard can it be?
With the WoT idea, I imagine being able to refer to "nip1" in a way ... like %nip1 such that your client would know where to look up what my understanding of "nip1" is. If I define ["nip1", "fiatjaf.nip1"] in the right place, your client would get you there. I think there is little missing for this to work. The idea of pet names is there and the rest can be done with some parametrized replaceable events.
This can absolutely be done. If I want to find a list of nips and which ones are approved and which ones are rejected by my WoT, I should be able to look it up. That can be done without requiring much data storage.
Pretty Good Apps could curate a list of nips right now. Buggy and not very spiffy but the proof of concept is there.
One problem to consider is: what if Alice and Bob each claim NIP-101 as their own? Two different NIPs but same number? Answer: we need to use cryptographic identifiers, not human readable names, to refer to their submissions. Then the WoT picks one over the other.
That is where I see the use of pet names. You would not talk about "nip101" or if you did, you would have something in place that would resolve to an actual parametrized replaceable event via maybe indirection. Or you would explicitly reference Alice.nip101 and then the nostr client would search for Alice's definition of "nip101".
Probably multiple ways to handle this. In my stuff, any given chunk of data may have several ways of identifying it uniquely: universally unique ones like the data hash or an event id (which are immutable; there’s also mutable ones line IPNS names); then there are slugs which are semi-human-readable; and one of the criteria of a concept graph is that every node in the graph must have a unique slug. But of course, outside the graph the slug won’t be unique, which is why you need a universally unique id. (if you ever want to share the data with anybody, that is; which is frequently the case when we’re doing WoT) Within any individual concept, there may or may not be any unique identifiers (whether local or universal), which will vary from concept to concept.
Rebuilding something in a truly decentralized fashion (and it’s probably worth thinking about what that even means, exactly) will likely require approaching / building lots of things differently than we are used to. For instance, we would need to make sure we don’t run into the problem you mention where Bob ends up expected to pay for storage of old data. Perhaps we would have to relax the expectation from the outset that a fully fleshed out snapshot of the entire App Store must get backed up just bc Bob’s WoT likes it at that moment in time. If he wants to back the whole thing up, he could do that separately. Just like I may have a local list of the 1000 best rock songs of all time, per Rolling Stone; it doesn’t mean I necessarily have them all on my phone. But maybe I’ll use the WoT-curated list tomorrow to help me decide whether to purchase one.
(I hope I’m following your line of thought. Let me know if I’m misunderstanding!)
Right now I’m working on a proof of concept where your WoT curates content for your nostr feed. You select a “channel” (a topic, like politics or sports or electronics) and your feed is determined by a list of pubkeys, curated by your WoT.
For this to work, there are several lists curated by your WoT:
1. A list of topics
2. A list of relationships between topics (like, smartphones is a subcategory of electronics)
3. One list of pubkeys for each topic.
If Alice doesn’t see the topic she wants, like Funny Cat Videos, she adds it and maybe endorses a few profiles that post on that topic. Maybe she also adds a topic: Videos that are Relaxing, and makes the cat topic a subset of that one. So if she turns on the relaxing channel, she automatically gets all the cat vids, plus whatever other categories her WoT added under Videos that are Relaxing.
