Have you built a data vending machine for that yet? https://github.com/nostr-protocol/nips/blob/67e950a2009e81df1b8c91b0a2ade0596e83f168/vending-machine.md

Reply to this note

Please Login to reply.

Discussion

Not yet, but the idea of a data vending machine, or something like it, is going to be of vital importance, I think.

I’m in the process of putting together a series of bounties to refactor DCoSL with better design and UX to give it better visibility. Trying to decide if rebuilding it as a web app (instead of a desktop app) is the way to go. You could go to the site, pick a list, pick a reference user, and observe which list items are accepted vs rejected by the reference user’s web of trust. The key observation would be that list curation by Alice’s WoT != list curation by Scammy Joe’s WoT.

So then I think: maybe add an API, so your client could request the crowdsourced list of High Quality Writers (or notes) on Topic X (query contains the event ID of the list and the pubkey of the reference user) and get back the crowdsourced list of pubkeys (or note event IDs). And maybe charge some sats to use the API.

Ultimately, the idea of a data vending machine may be better, if I understand the idea correctly, bc the sats are going to a user (the one ultimately responsible for the curating) rather than to a website.

List of posts or other people? If it is people, you can create/update nip 51 lists and Amethyst would offer then as top bar feed options automatically.

Probably both. My tentative plan is for the series of bounties to culminate in an app that I call Nostr Channels. My description, as of last night:

The app is something that I call Nostr Channels, and it would make use under the hood of the protocol for decentralized curation of data that I have been working on for quite some time now. I envision it as a fork of one of the existing nostr clients. The idea is that you open up your client, select a "channel," and see a feed that is enriched for the topic(s) that are selected to correspond to that channel (minus any topics that you want blocked from that channel, e.g. NSFW notes). Your web of trust would curate the list of topics, the organization of topics into a hierarchy, and the association of any given topic with pubkeys and individual notes. You would have the option (if you so desire) to create new topics, to edit their hierarchical organization, to select which users you "trust" to curate specific topics, and to associate pubkeys and note IDs with specific topics. But even before you've had a chance to do any of those things, channel selection would be fully functional. In the beginning the number of available topics and channels would be few, but it would get progressively better and more refined as more and more users participate.

The difference between Curated Lists and NIP-51 lists, if I understand NIP 51 correctly: each NIP-51 list has a list owner, who controls what items go on the list.

With Curated Lists, each list has an author, but there is no list “owner” bc the author has no more control over the items on the list than anyone. Anybody can submit items to any list. And then the submitted items get accepted or rejected by the web of trust that is centered on the reference user.

And you can select anyone as the reference user. Different reference user will (potentially) mean a different set of items on the list.

(In the absence of controversy, you’ll probably get the same set of items regardless of reference user. But when there’s controversy, then you’ll see changes in the list depending on reference user. I refer to this phenomenon as Loose Consensus.)

I know that replaced some earlier NIPs that generated some controversy. I should take another look at 32. I recall there were some things I didn’t follow but if it’s being utilized then the examples will help.

NIP 32 could work for this. You could do something like

["L", "com.mycuratednostrlists"]

["l", "politicians.evil", "com.mycuratednostrlists"]

["p", ""]

["p", ""]

That would be a claim by your pubkey that those politicians are evil. People can pay attention to that classification, or they can ignore it, and claims by multiple users can be rolled up by "l" tag.

Trick NIP-32 label: ALL politicians are evil.

😂

This weird trick ends statism 😁

Are there examples of different namespaces that I can look up? How would I go about designing my own namespace?

( I think I recall correctly that L means namespace … ?)

A list of namespaces, curated by your web of trust 👌🏼

Exactly! 🕺🏻

And a namespace is itself a list of … something. But what exactly are the items on this list?

does nip 32 describe how to format a namespace?

Nos.social was working on a content labeling one, but the only one I'm aware of is coracle's relay reviews: https://github.com/coracle-social/coracle/blob/master/src/app/views/RelayReview.svelte

I'll soon build one for DMV reviews and they will be supported in NDK.

Hopefully that'll mean that NIP-32 labels will be readily accessible to many apps with a very simple interface.

DMV = Department of Motor Vehicles? 😜

Damn it.

Typostr strikes again. 😂

Too many options. Keep it simple. Focus in one VERY simple use case. Fix ins and outs and let them fill the middle. Remove all the jargon. Otherwise it will just be too much for anyone to be interested.

How to make something that is simple on the surface, yet complex enough under the hood to do what needs to be done, is challenging when it comes to web of trust, bc many simple solutions just don’t work.

But your points are well taken. Ways I could simplify:

- I describe channels and topics as two different things. Maybe get rid of channels and just stick with topics.

- I describe curation of pubkeys AND notes. Maybe just curate pubkeys, forget about the notes.

- forget about organizing topics into a hierarchy. Just have topics, that’s it.

- provide the ability to upvote but eliminate the ability to downvote.

In each of the above cases, the extra features could potentially be added later if users ask for it.

But consider this:

Flip the channel. Watch your feed. What could be simpler? 😃

Unless you are going to do a massive bounty, bounty hunters will be either professionals with 3-4 hours to devote to the solution or high schoolers with around 10-15 hours of focus. If things feel that they will take longer, they are not going to do it. Neither group will have the time to learn any WoT concepts.

This means that the more especific you get, the easier the chances of somebody completing it.

Here's a template: get code of server X, add a listener for event kind Y, which runs through the data Z, organizes in this way, calculates a score using this equation, sorts it by score and writes the result on a event kind W and sends it back to the network. You have to give them every detail.

Here’s the draft version of my first bounty (link below).

First in a long list! The app I describe would be WAYYY down the line.

20 mil sats. Very detailed description. I totally bet a good nostr dev (you, nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft , etc) could bang this out in like 2 or 3 days.

An experienced webapp/ react dev but new to nostr? I dunno … a week or two maybe?

Any good devs you’d like to shepherd into the nostr fold?

https://github.com/wds4/DCoSL/blob/main/bounties/curatedLists/phase1/phase1.md