Oddbean new post about login | logout I have a modest proposal to make: **Get rid of follow/mute lists.** Use kind 30382 (see PR below) to denote some "relationship status" between your npub and another. **Get rid of bookmarks lists/sets, good wiki authors lists, and curation sets.** Use labels, highlights, and embeddings to keep track of the stuff you find interesting. https://github.com/nostr-protocol/nips/pull/761
We should not be using follow lists, to determine what to read, to attest to someone being worth interacting with, or to publicly declare frenship. We should not be using mute lists, to mark what we consider spam, or to denote "npubs who get on our nerves and should just be quiet for a bit". That is bad design dragged in from legacy social media and it is holding us all back. And now we're coming up with bug fixes and workarounds for this stuff, or cracking jokes about how crappy it all is and declaring the crappiness to be our Proud Nostr Tradition, instead of admitting that we need to just scrap that whole concept. https://media.tenor.com/QmoETUjttMEAAAAC/maybe-things-will-be-better-jade.gif
How do we mute annoying people?
I agree, it would be nice to have more nuance and variety here.
Damus has “mute temporarily” already. Something I think would be great but we’ll probably have to wait for AI to get good: topic-selective muting. Then, if you like notes on subject A from a person but can’t stand it when they talk about B, your feed can reflect it.
Oh, heck, yeah. Hadn't even thought of that. @liminal
Its an interesting idea. i think the human labels for navigating might get us pretty far - more so than AI embeddings. Using some ML and NLP could clean up that feed even more. With embeddings, scale is the biggest issue. They're expensive to hold and compute with. Bet there are open source solutions to model off of though.
I’m not very technical, by human labels do you mean hashtags? They’re not used enough for this functionality
He means the label NIP 1985.
And also 1983 and 1984, of course.
There’s so much potential if AI can detect topics and tone well. It could be a powerful way to find accounts of interest to users, not just selectively muting accounts when they are not of interest.
Are relationship statuses public? If that’s the case, it’s a disaster in the making.
Why so? Follow and mute lists are already public.
“Oh, we’re not friends anymore?!”
People may already think that if they are unfollowed 🤷🏻♀️ this is already a problem
Unfollow doesn’t mean much. But if you’re setting and changing status on people, and everyone can see what you consider them as, this is like high school popularity contest but 1000x worse
Point
It’s going to turn nostr into a shitty version of linked in
LinkedIn is follow-based.
Aren't lists public too?
And? A follow list doesn’t say much about your relationship to someone. A status says a lot if it’s visible to all.
What if its a top8 list ?
https://image.nostr.build/db0ca3bbce0c01ee4ca668b1507cf68d16908da7dff90d96306fe0253494a300.png https://image.nostr.build/278dbd7ee54e55557abb48b1d2c6725d96e54d345d2f7f5eeb3a2b0fafbdda7f.png
Thanks? I’m not sure what reaction you’re expecting from showing me my mute list…
That was the topic of the thread, wasn't it? How is a public list of mutes different from publicly labeling an npub as muted?
They can be public and they can be private. This comes down to how the clients choose to implement them while following the specification. - public association to pubkey, public clear text data - public association to pubkey, private encrypted data - public association to pubkey, with a mix of clear text data and encrypted data etc In the case of Corny Chat petnames, I went with making it known the relationship was public, but the actually assigned petname is private.
Yes, they can be either/or. Which one makes sense depends upon the type of client. I think Vitor wanted this for health care data, so patient:doctor should probably be private. But Alex wants them to define community membership, and then it might make sense to make them public, so that the other members can see who is in the community. Especially, if the relationship events stay on a dedicated community relay.
Lists are already public. If I take someone off the "Cool Dev Absolutely Fave Must Read" list and put them on the "Gives me the ick" list, I don't see how that's different. 😂 And you can make all of your categories private, if you care.
At any rate, I linked the spec in the OP. Just read it, yourself, instead of jumping in with both feet to bitch.
Yes to getting rid of follow/mute lists. I'm already in the process of this with using other lists and may end up pushing those into relationship status if enough clients add support No to getting rid of bookmarks lists/sets, authors lists, curation sets. Some collections are relatively static and do not need to be defined dynamically across a series of notes the way that relationships work. Plus, lists are the best way to give contextual order to related data, and allows for duplicate entries within the list. Curation sets are actually Curation lists.
We think we can blow the usefulness of static lists out of the water with embeddings, but not everyone wants discovery that powerful because they find it uncanny. At any rate, the list structure will remain (our own 30040 index uses it, to create an ordered list of chapters for a book) and people will continue to use it, but I'm eager to put everything on the table and give it a good look. Where do lists make sense and where not? I think we need to just ask that question, straight-out.
Y'all, just read the PR I linked to. This is genuinely one of the more brilliant things I've seen and the spec craftmanship is unusually good. I saw this and thought https://media.tenor.com/N373wEc3NPEAAAAC/thats-it-that-right-there.gif
And, here's the best part: You can categorize people without establishing a relationship with them.
Relays have never been SQL databases. I'm saying that the error has been trying to inject RDB structures into events.
He submitted it after I posted my spec on the wiki. Just saying.
It's not similar to mine, which is 1983 (based upon 1984) because mine is not a replaceable event (in the 30000 range), otherwise it wouldn't function as a fixed, possibly-expiring, record of some particular interaction and couldn't be used to create a sort of handshake, with the attestation/confirmation pairing. This is more like relationship status 30382 and therefore superfluous.
>>"Would be very sad to see Nostr become like the MongoDB API". Fiatjaf<< That's not a logical argument. Tell me why you hate my idea, concretely. Don't quote Fiatjaf, like he's bringing down the Laws of Nostr from Mount Sinai.
Hehe yep, I get why you'd do that. Follow lists are a mess though, I like the proposal to instead start using individual events for it: nostr:nevent1qvzqqqqqqypzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqyghwumn8ghj7mn0wd68ytnvv9hxgtcpr3mhxue69uhhg6r9vd5hgctyv4kzumn0wd68yvfwvdhk6tcqyqjwewmrj4yz58jnu87p5fevr4f8lwulavks4jkmwegyrfjnherqq6v33px
Regarding Follows you might enjoy this thread: nostr:nevent1qvzqqqqqqypzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqqszfm9mvw25s2s720slcx389sw4ylamnl4j6zk2mdm9qsdx2wlyvqqf8hm6t Regarding Zaps I agree with you. That's why I'm designing for Zaps to be more than just Tips. IF 1. Creators can reply to them 2. Zappers can see their zap amount in context THEN We can see some kind of market pricing form around what amounts/comments are going to get you recognition/attention/reputation ...
