btw I took a quick look at anigma.io and I was wondering how channels work? Are new channels stored as nostr events? If yes, what kind are you using?

To address your point of x’ing out of the checklist: display an option at some point where the user ports the entire follows list into a “trust in all things” list. Make it easy and painless. That’s just to jumpstart the system. When Alice later realizes she doesn’t actually trust Bob in category X, that’s when she discovers she can provide an updated attestation to that effect.

Figuring out how to make this usable is def a challenge, but it’s one that we desperately need to figure out, at least in my opinion. The value added would be tremendous once it’s all in place.

Shifting from scraped data (which is based on the oftentimes false assumption that follows = trust) to explicit trust claims is one of the humps we need to get over. The question is: how exactly do we do that?

Perhaps for starters: for a marketplace, make a hierarchical list of product categories. Since it’s hierarchical, instead of rating all your contacts in a super granular fashion, which would take forever, you could use large categories. Probably for starters, Alice would say she trusts Bob in “all categories”. She might even just want to port her entire follows list, saying she trusts all her follows for all categories. Of course the point is that that’s not always true, so the next thing she can do is edit the trust ratings, in as granular a fashion as she desires.

nostr:npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s how do channels work in anigma.io? Are new channels stored as notes? If yes, what kind are you using?

I think something like that is a good place to start.

The main issue is that following or friending someone != trusting someone. Especially when trust is contextual: maybe I trust you to rate movies but not fashion. So perhaps the next step requires the ability to attest: “I trust by amount, with confidence, to rate ” where context would be some category of product.

Implemented?

Currently you could use NIP-32 for reviews. But you’re right, there’s currently no web of trust based system in place to filter the good from the bad.

Do you have ideas on how you’d like to do that?

Ok, I see it’s reverse-DNS, something I don’t recall ever using. I guess it’s a Java thing?

Ok I found some with L tag “social.coracle.ontology” — why is it written that way and not ontology.coracle.social? Should I be able to query the url for a primer on the namespace, which I guess would be a list of available labels and a description of what each label means?

I’m looking for examples in the wild of kind 1985 events — I see 533 such events, a bunch with ugc as the L tag and a bunch with no L tag. Should I be finding more? I’m looking for examples of namespaces in the wild. (Apologies if I’m overlooking something simple … 😬)

So how would this work?

I suppose i would invent a label like “lists of nostr developers” and then use NIP-32 to attach that label to each of the above 6 lists.

And the namespace would be ugc, unless I know of a namespace that already has a label that fit, or unless I wanted to be fancy and manage my own namespace and add the label to that?

There are at least six people with NIP-51 lists titled “Nostr Devs”

We should have a way to merge identical lists

I’ve been trying to contemplate how to rethink my work on decentralized list curation in a way that builds incrementally on top of the great work that’s already been done on lists using NIP-51.

Spitballing: “private” lists vs “public” lists. NIP-51 lists are “private” in the sense that the author of the list decides what items go on the list. What if we added a new classification of lists that are “public,” meaning that anyone (not just the creator of the list) can add items to the list?

Users could view a composite list which would include items from everyone who contributes items to the list. Or maybe limit contributors to your follows. Or maybe limit contributors to people on some other list or using some method we haven’t come up with yet.

Thoughts?

I’m adding NIP-51 support into Pretty Good. Thinking I should interface list curation with that.

That and a search function

Which clients allow me to create new NIP-51 lists?

Interesting. I had never heard of penpot. Thank you!

Also I keep running across more and more places to look for btc and nostr related bounties. I’m going to have to start keeping a NIP-51 list of them!

In the long run, we’d like it to be as easy as possible to start new relays. We need there to be no moat. That way, the efforts of the state or other powerful entities to capture and shackle the biggest relays will be fruitless, bc new ones will immediately pop up, and the market will hopefully have the tools to recognize quickly which ones have been captured and respond appropriately.

I imagine in a world like that, the business of running a relay would be pretty close to break-even.

And in a world like that, it might not be a good thing for relays to require building up a brand. Bc branding takes time and effort and expense, which would work against what I said above.

If we can ever get decentralized web of trust to live up to its potential, then our WoT will help us know which pieces of info (and/or which content authors) are worth paying for. In which case perhaps relays will become like informational wholesalers. Alice says she’ll pay x sats for whoever can deliver a file with a particular hash, and that becomes the relay business model. Maybe a few sats for a chunk of files. Whatever is enough to cover the costs of the relay.

My point being that I think IPFS suffers from the fact that users are locked-in to things like kademlia that are cool, but suffocating. Nostr has done a good job avoiding that sort of trap. Just something to keep in mind when contemplating what to do about relays.

The ability for different groups to experiment with different strategies to address the very real problem you bring up is one of the strengths of nostr. I sometimes imagine that nostr is like IPFS except minus 90% of the cool but unnecessary complicated stuff, including the fancy schmancy kademlia network that connects all the relays I mean all the IPFS nodes together.