How should clients mix/score search results from several relays?

Can I flip to ONLY nsfw?

Now building fulltext search into nostrdb 😅

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? 😃

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.

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.

I agree with you to beware building tools that reinforce large accounts. It is one of the symptoms of legacy, ad-based tech platforms that prioritize influencers over all else. Building tools that simply reward follower counts can be a hard habit to break.

On that topic: in DCoSL, the grapevine is based on replacing average scores with *weighted* averages, where weight refers (mostly) to a contextual influence score. But we must be careful to calculate influence scores in a way that does NOT scale linearly with follower count or any other simple measure of visibility. Minus the pathologies of the centralized ad-based system, there’s no reason to give the social media “influencer” who spends all his time building up a million followers more weight than the Einstein who only has 8 followers bc, well, he has better things to do than be an “influencer.”

What do you mean “break further down from event kind”?

You mean the kinds the DVM will take into account? That’s a param for the DVM:

[ “param”, “kinds”, … ]

I love #Amethyst but the choppy scrolling is almost a showstopper.

It kills the experience 🥹

Will Amethyst provide this function in-app eventually?

“I use DVM npub1XX for kind:job-req-feed-generation”

Or even

“I use DVM npub1XX for kind:job-req-feed-generation, t: ‘bitcoin’”

I would say what I was going to say but you already know what I would have said.

But they allow for long-tail algorithms that could be interesting for a particular set of users:

“Give me trending notes for my npub”

I think this model wins because it allows a developer to write 5 different and weird algorithms in one day, even if those algorithms only have 10 or 20 devoted fans

How?

Have you looked into primal implementations? I believe they're doing it based on likes and zaps. That could be a way to have a trending category

Ah, that's sad. I'm curious which parts *really need search? I like the idea of not needing search except on the local db.. but I'm also just wary of this search extension since I haven't seen any OSS implementing it. Does primal do it?