Nostr Web Client

I actually benefit from the Bitcoin and Nostr bias, but I like to write about OtherTopics, too, and I find it brutally difficult to get that material to new npubs who might enjoy it, and be more-inclined to stay, if they saw it. Because I also write about Bitcoin and Nostr, the people solely interested in OtherTopics don't follow me.

Do I need another npub for OtherTopics, or something? I have so much trouble rotating between npubs, tho. I have to keep switching back and forth, but keep forgetting, so npubs wait a week for a response and give up on me.

I'm running out of ideas and feeling increasingly frustrated.

#asknostr

david 1y ago

Content discovery is a huge pain point on nostr, and this is a problem I want the grapevine to address. The grapevine score is designed to serve as a weight, useful for weighted averages or vote tabulation. If we have a system where you can either self-attest you like to write about topic X or recommend others as good follows for some topic (maybe badges can do this?), the grapevine can synthesize that info into recommendation lists. If Alice wants to find great follows for SomeTopic, her grapevine will have a rec list for that, and you’ll probably be on it if there are indicators you should be.

#WoT

#grapevine

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

one of the root causes of the discovery problem on nostr is a lack of distinction in the protocol between public and private (of interest to a limited group) events

a profile metadata is public, a relay list is public

really, follow and mute lists should be private

or at least, there should be a private form of them, that can differ from the public form

public events should be broadcast everywhere and accepted by anyone who is publicly followed by any paid user on a relay

private events should be only sent to in/out boxes and be accessible only to those who have been publicly declared friends, and not to those who are enemies (really, mute lists should be called enemy lists, and follows, friends)

making these kinds of distinctions in the protocol would help guide implementation a lot better than the mess we ehave now, where certain things are implicit but not really correct

nostr:nevent1qvzqqqqqqypzpef89h53f0fsza2ugwdc3e54nfpun5nxfqclpy79r6w8nxsk5yp0qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpzfmhxue69uhkummnw3eryvfwvdhk6tcqyplkevx558gmz7lh3ut6rqd2q7n6a35up4uzttmw269fduazp9dc23klze0