Or there is an opportunity in decentralizing those registries. I guess it hasn't been done because it's not particularly rewarding job to do.

This is utter bullshit! You are not free, freedom is relative. You must breath, you must have social relations, you must have a place to live, and so on. And what do you do with the freedom you've been fighting for? You fill it with purpose! And then, you're not free anymore. You take on responsibilities, make promises to yourself and the world. And you continue to fight for your freedom to be able to fulfil your purpose even better. You'll need social, economic capital to succeed. And if you call out bullshit in the wrong place, or too much, or too cruel, you will be cut out from the social network and it will be hard to achieve your purpose alone.

But yeah, there is a point in time when you have to take that step and call bullshit on everyone around you, so as you can experience true perfect freedom for a few hours, days or even years, just to realize it's not what you wanted in the first place.

Nature is on our side!

If you need filtering based on that tag, then maybe a separate kind is better. Otherwise, "proto" would be self-descriptive and wouldn't interfere with "p" at all. Intuitively if I would see "P", I would associate it with pubkey, too.

Thanks for reading! I made a PoC implementation in nostr-rs-relay, it's not complex at all.

Are you suggesting DVMs because of complexity or performance overhead of the querying? I feel because this is essentially data retreival only, there is no computation involved, that DVMs are overkill for this task. However, DVM's could be used for processing the results of this query, run algorithms on top, possibly including kinds 7s and 3s and so on.

I might be too optimistic on this feature, and expect large webs of trusts emerging. But if somehow they would grow big, then kind:7 events, created only by a 30077-trusted group of people would be an excellent input for algorithms to decide on content quality.

Overall, during discussions on this topic I felt there is a need to move away from follow lists because they are too broad already.

Haha, it feels a little bit like this classic xkcd: https://xkcd.com/927/

I think it's not a task of a NIP to define how we're going to use existing trust attestations, explicit (38000) or implicit ("827919") or proxy (zaps+likes). This is a field where "read" algorithms will compete. Maybe a NIP could be used to define the inputs or outputs for such algorithms, but it was not my intention with NIP-77.

I would be fine if app developers in the future chose this uniform format to express trust. I also think it's useful to have a query that returns a recursive trust graph, and algorithms can do anything on this data, possibly including other data sources. The goal is to avoid the xkcd situation as much as humanly possible.

And thanks for mentioning couchsurfing! https://www.trustroots.org wants to bring his community + reputation system to nostr, I'll contact him!

I hear you on the point of hierarchical context, and I agree that from the viewpoint of usability and flexibility, especially in the long term and for complex algorithms it's essential to have hierarchical contexts. I haven't written a word about it in the NIP so here it goes:

Some kind of hierarchy is already possible to express in context: "science", "science/physics", "science/physics/quantum-physics". We could make the algorithm match if the trust is a prefix of the next one. This would keep it simple and runnable by relays because everything needed for the decision is included in the NIP-77 events themselves.

Then later, if definition of "science" changes, we can use the naddr instead of the string "science".

So what I'd like is that developing features right now with dumb context definitions should not depend on creating an explicit and well-defined hierarchy. I'd like to experiment more on the basic trust/filtering capabilities. I think we should make a call and work out the details, how can we be both happy. it's much more effective in a call.

Updated NIP-77 proposal about Web-of-trust.

https://github.com/lez/nips/blob/master/77.md

It feels clean and simple to me, also extensible, but I would love to hear feedback on that.

#wot #sovwot #wotnip #nip77 #trust #hierarchy

Updated NIP-77 proposal about Web-of-trust based on explicit trust attestations. https://github.com/lez/nips/blob/master/77.md

It feels clean and simple to me, but I would love to hear feedback on that.

#wot #sovwot #wotnip #nip77 #trust #hierarchy

Hop on!

We could do better. Let's say a small dev community wants to protect itself from ghosting. Whenever a new contributor comes and takes on responsibility, he needs to pay a deposit of a size that corresponds to the size of the task he is committed to and the degree the team depends on finishing the contribution. If the contributor ghosts the team, the deposit is split among current and past contributors.

I see this can be a barrier of entry in the beginning, but if all open-source developers make such a deposit and it becomes the norm, the ghosting problem will be successfully mitigated.

Implementation details intentionally left out.

Depends on the audience and the topic. I think what Stuart refers to is more about fighting the demons inside that make us lie unconsciously. https://www.youtube.com/watch?v=tw0sskCqrpI

Here is my 2 cents for the questions:

1. App developers often make bugs, and for list events it means that it's easier to unwittingly erase the list if the user wants to add a new pubkey and cannot find the previous event on the network. Apart from that, it's easier to build graph from individual events (as VictorPamplona mentions in the github issue).

1.5 Replaceable events or static events? - Replaceable events can be updated, if trust relation changes over time. Also, event deletion seem to be not well implemented in relays.

2. Another model is private to the author + shared by relay/DVM when needed. I think the common sentiment is that we all see usecases for private trust events, but implementation is more complex. We need interactive protocol for this - as Hodlbod mentioned - or ZK proofs, and who knows what. For now, I think we should go for public, discover the possibilities and implement private model when we know more about the problem / we see what the main usecases are.

3. I would vote for an optional scalar "score" and "confidence" value. If they are absent, it's a binary true value.

4. I like the "context" term. I think it could be optional, but see a lot of value in embedding into the event, so as it can be used by filters as input. I don't see clearly what is the usecase for it derived by filters. Is it like "I trust this guy", and the algorithm tells me the context it was used in?

5. I'm probably not the one who has dig into it deeply. Not sure if this is what you mean by spec, but I'd like to know: what are the inputs/outputs, where the filter should be ran (client / relay / DVM / phone) and when (when content is created OR when queried). Should I be able to make a relay subscription based on a content filter?

Someone should open a shoe shop in Madrid where Bitcoin is accepted. Then call it Zapatoshi.

"ostriga" means Oyster in my language (Hungarian). Just saying.

One of the many approaches to this problem: https://github.com/lez/nips/blob/master/77.md

If you're already in there, get well soon. If it's just a feeling that you're tired more than you should be, there is still a chance to fight it back agressively and early. My tactics on this is to take 50k vitamine D + 50k vitamin A + 3 drops of MMS, later on 4g of vitamin C. Add Zinc 30mg and Magnesium 200mg (from glycinate). Next day, continue with 50k vitamin D, 50k vitamin a 2 times, 12hrs delay in between. Usually I can avoid getting sick by doing it, or if not, it will be much less severe.

Looking forward! Tired of imgur and aws URLs.

On nostr, I would share them.

I'm on a wifi, but that is pretty stable, distance is 30cm from the laptop. Fiber to the house internet. Do you want to go on a video share? It is reproducible.