I wonder whether Blackrock is gonna try to fork btc
I agree with this line of reasoning.
The question is not whether curation needs to happen. The question is WHO gets to do the curating. Putting it into the hands of the CCP or big tech big media or some other centralized entity is the dystopia we’re trying to avoid.
But the alternative is not: no curation; the alternative is decentralized curation, where you the user are ultimately in charge of who / how it’s done. If you trust Big Tech Co. to curate your feed, then great. If not, you need tools to allow you to delegate curation to another entity or entities. And other entities need tools to do the curation for you. Those tools need to be easy, cheap, effective, and customizable. Those tools are what will allow us to exit the dystopia that otherwise awaits us.
Pretty Good Apps functions but is still really clunky, so I'm adding descriptions with screenshots to the repo so you can see what it does without wrestling with its bugs.
This page illustrates basic list curation using the DCoSL protocol, with "nostr clients" as the list in question.
https://github.com/wds4/pretty-good/blob/main/appDescriptions/curatedLists/exampleListCuration.md
I suppose I haven’t heard him speak enough times to get tired of anything in particular. I do wonder how much of what he recalls about his family is through rose colored glasses. And yet, his remarks about the importance of being able to put yourself in your enemy’s shoes and of the way that tribalism impedes this ability are valid ones, imho.
Incredible speech by RFK Jr. So refreshing to hear a politician speak these words.
“I don’t always drink beer. But when I do, I drink dos nostr.”
If parallel worlds are a thing, then there are certainly some worlds where this is gonna happen. And some where it already happened.
Maybe a lot. đź’€
Maybe this is why we haven’t seen any aliens. 👽 Because in all the worlds where we do see them, we see them for 1 millisecond and then💥
Decentralized data curation by your web of trust is ultimately going to be replace centralized data curation by Google.
It’s inevitable.
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.
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.
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.
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.
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!)
When discussing web of trust I think it’s worthwhile discussing whether we agree (or not) with the following two proposals, in the abstract:
1. The goal is not to produce one curated result for one community. It’s to produce one curated result per user. If Alice and Bob don’t have identical WoT, they should see different results.
2. It is generally preferable to use explicit attestations rather than scraped data. (Don’t assume Alice “trusts” Bob just bc she follows him and it’s easy to scrape a follows list. She should explicitly attest “I endorse Bob in context X.”)
I have written these up as DIP-01 and DIP-02, respectively, which are linked to on this page:
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.
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.
NIP-89 is what nostrapp.link uses, if I’m not mistaken?
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.)
Suppose you hear about a decentralized app that provides a tool for the community to curate (“crowdsource”) lists. Lists can be of whatever you want.
Which would you get more excited about:
- one community, one set of results. For any given list, everyone sees the same set of items. But it’s crowdsourced so hooray!
- one set of results for each user. For any given list, the items that Alice sees may or may not match what Bob sees.
Thoughts?
I actually wrote about that idea 8 years ago. Damn.
There are a few other abstract ideas that flow naturally after this one that are also worth explicit consideration imho, if we are ever to make a web of trust that lives up to its potential.
https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/Principle-of-Relativity-for-WoT.md
Yeah that is right. All you'd really need to make mute lists comprised of other lists work well for users is to have clients parse a user's mute lists in a recursive way – e.g. when they come across a list in the mute list, they'd need to fetch that list too and add the users/threads from those lists.
I don't know how many clients already do this...
nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49 ?
I very much like the idea of putting together a mute list in the way you’re describing. It comports with the abstract notion in DIP-01 of dcosl, which makes explicit the idea that community-generated lists (of whatever) ideally shouldn’t generate one list for the community, but rather one list for each user. It’s a principle worth thinking about in the abstract.
Yeah that is right. All you'd really need to make mute lists comprised of other lists work well for users is to have clients parse a user's mute lists in a recursive way – e.g. when they come across a list in the mute list, they'd need to fetch that list too and add the users/threads from those lists.
I don't know how many clients already do this...
nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49 ?
I see. Alice’s mute list would effectively parse into two lists: one list of pubkeys to mute and one list of lists of pubkeys to mute. Putting someone else’s list on the list is pretty close to being an explicit endorsement of contextual trust. And it could be implemented transitively, if desired. Maybe up to N hops away. And perhaps a user showing up on a list two hops away counts for less than just one hop away.