nostrmeet.me
> is ultimately going to be the killer app that motivates normies to join.
nostr:note1s730l6jm5e0zznzxfs4shs89vqqmqka9hsu8t7xy8prsg88x9hzqe645zj
nostrmeet.me
> is ultimately going to be the killer app that motivates normies to join.
nostr:note1s730l6jm5e0zznzxfs4shs89vqqmqka9hsu8t7xy8prsg88x9hzqe645zj
I could feel your disdain for equating follows with trust. I feel the same way. We need more of that energy. 💪🏻
But it DOES work for some… so … still work to be done to design a minimal standard for implementing WoT.
I agree that there is a role for proxy data to play. In fact, I will be using the follows list to calculate preliminary influence scores at brainstorm.ninja. But it is a crutch that must be weaned as fast as possible.
Here’s how to wean it:
1. Calculate WoT scores using follows data.
2. Give users the option to submit explicit, contextual trust attestations.
3. Replace low quality follows data with high quality trust attestation data as it becomes available.
Users will gradually become acclimated to the new way of things.
On the topic of making trust attestations private:
There are scenarios where trust attestations MUST be private.
There are scenarios where they MUST be public. Specifically: if we want to harness the power of transitive trust. Which we def need to do.
So both options must be available.
The only question is which option to provide first. I propose public attestations first, so that we can harness transitivity.
Describe transitive trust.
I trust you to curate topic X on wikifreedia
You trust Bob to curate topic X of wikifreedia (or topic Y which is a subcategory of X)
Therefore I trust Bob even though I know nothing about him other than the above.
Right. I think that can be accomplished even with private trust events.
It’s not only one or only the other. Both options must be available.
Why?
For the same reason that the world shouldn’t have to decide between credit cards versus money order. CC are a bad option for remittances. And money orders are a bad option for buying coffee. Optionality is needed to serve a variety of scenarios.
When it comes to WoT, there are LOTS of questions and issues where people debate method A versus method B versus method C, and the correct answer is that methods A and B and C will all have a role to play. Optionality must exist, long term. The only question is which options ought to be rolled out in what order.
And so part of our job involves thinking about the tradeoffs between the various available methods / features / options. Also, which features will be awesome but only after some other feature / option is already sufficiently matured. This takes a lot of mental energy but we need to do it if we’re going to know which features to build and in what order.
Long term: I will be able to generate a piece of data and make it available to some particular set of users under some particular set of conditions, with those users and conditions defined in some arbitrarily complex fashion.
But short term, we cannot provide arbitrarily complex features. We must take baby steps.
Currently, follows are public. I propose the first baby step should be contextual trust attestations, but still public, so we can make it easy for us devs to process transitive trust relationships. The option to make them private should come after that.
Seems cool, but it didn't work. Couldn't download the qr to test it.