While I agree with most of the thread, I wonder how will these attestations (context/score/confidence) be input into the system?
I have a strong intuition people will not bother doing this. UX is everything. So yes, it may be a task delegated to an incentivized curator - which in turn requires trust in them. Which might as well be an LLM that ends up deriving trust based on proxies.
IMO for this to actually work we need users to signal trust in a more progressive fashion. User prompts should be sparse, minimal and appropriate to the context of whatever they're doing in a client, e.g. when fat zapping Lyn Alden user could be prompted to sign an event assigning more weight to Lyn in the topics of the zapped note. A bit more, not a number.
A perhaps extreme, terrible UX example would be: out of the blue, ask me in absolute terms how much I trust Lyn Alden, make me input what things I should trust her on, and the confidence I have on what I just wrote.
Also, humans do not think about trust in percentages and are lazy when the ask is too big relative to an eventual payoff, so will answer things quick and inaccurately just to get done. It's a translation, a degradation in signal, so one could argue that these attestations are also proxies. Better than follows, probably, but also proxies.
I think you’re correct when you talk about doing it in a progressive fashion. Maybe you can help me select which of the following options would be the best user experience and make the most sense for my next update at Nostrapedia (at brainstorm.ninja):
Option 1: enable thumbs up / down button for individual Nostrapedia articles. This will obviously be familiar to users. Under the hood, if you like an article written by Lynn, and she has placed it under the category of Economics (the author assigns the category as per NIP-54), and you are in my trust network, then I will see Lynn have a high trust score in the context of economics, even if she’s otherwise completely disconnected from me.
Option 2: enable the “Follow” and “Mute” buttons on a user profile page, which of course users are also familiar with, but with an additional selector that allows you to follow or mute a profile *in a particular category*. You will select the category from the list of Nostrapedia categories, generated from all currently existing articles. I could even add an additional “superfollow” option, perhaps designated by a star emoji. Maybe you could even do a Superfollow with 1, 2, or 3 stars.
In each case, I already know exactly how I’m going to interpret the attestations and process the data. Users won’t have to think in terms of numbers or look under the hood — unless they are curious, in which case they will have the *option* to verify all the calculations themselves. How many will be curious to know how the numbers are crunched? I don’t know. If they’re not curious at all, they can just keep clicking emojis like we all already do.
Here’s where Option 2 is headed. Suppose you have a normie friend you’ve been trying to recruit to nostr, who loves comic books and posts great summaries of his latest comic book finds. Normally he would make a nostr profile, look around, get no followers, see everyone talking bitcoin 24/7, get bored and leave. But you would create a superfollow for him in the category of Comic Books. The next day, your friend would have 10 new followers who all love comic books and saw your friend with one of the highest scores around in that category. And he’d stick around!
Yeah man absolutely we need to keep iterating and finding some usable middle ground. Anything with slight more signal than follows is a win.
Option 1: would this be using kind 7 likes/dislikes? If so, trust would be derived from the interpretation of those events rather than being explicit, did I get that right? Regarding NIP-54 how likely is it that she adds the category?
Option 2: love where it's headed, we need this. Communities fixes it too right?
Today, how would we add a a mute event *in some context*? (reuse kind 10000 or does it have to be NIP-77?)
In zap.store eventually I want to start asking, after a few app updates: "do you trust this dev" and make the user sign that attestation.
Probably yes about using kind 7 likes / dislikes. And a big fat yes to interpretation. I am increasingly thinking of NIP-77 as an idealization, with interpretation of proxy data into the idealized NIP-77 format as being a fundamentally important thing. Interpretation is done by the consumer, not the author of the primary data. It’s not far from what we do in real life!
Maybe around half of NIP-54 articles are given a category, something like that. Eventually you’ll be able to invent new contexts and categories without the need for a wiki author to publish one, but gotta start somewhere.
For a mute event in some context, I’m thinking I’d use NIP-77. But the beauty of interpretation is that if client A uses NIP-77 and client B uses an augmented kind 10000, the consumer can take data from both formats, interpret them into a common format, and pool them to create a larger dataset.
Oddbean new post about login | logout