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.
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.
Twitter used lists because it started out with MySQL (owned by Oracle), which is a relational database, containing a bunch of gigantic tables. If there is a "follow" table, you would have to read the entire table out, and search through the table to find the row, to update a single row. The rows cannot be searched for and edited in isolation because the relationship is from table-to-table, not from row-to-row.
We are using events, which are json (or yml/xml/whatever) documents, and similar documents can be clustered at run-time. Furthermore, you can create direct relationships between individual documents. This is the programmatic equivalent of having a separate table for every single follow. It only makes sense to put _dissimilar_ events into a collection/list event, as the similar ones can be collected and displayed together, at run-time, by saying, "please display the content of all of the follow tables, one on top of the other". There is no obvious reason to store them all together, just to display them all together, and this increases the risk of entire tables getting "nuked".
And to store them together, in one long, ever-expanding table, is to break two of the core advantages of using documents, rather than tables: small event size and individual addressability of each item. If you put all of the follows in a list, how do you then reference a particular follow? If you keep expanding the size of the events, to accommodate ever-expanding lists, how do you keep binary data out of events and prevent spammy load attacks? Break the list down into chunks? Why not just do that, from the get-go? What size should the chunk be? How about... one row?
And now we have the problem that people don't want to put all of the nubs they are interested in, into one list, but they want to put some npubs into multiple lists. There should just be one entry "me and this npub are linked" and then other information "this npub is a good friend, posts a lot of news, and I want their stuff to surface more often than other npub's stuff". The relationship should only be established once, but categorized n times.
And, here's the best part:
You can categorize people without establishing a relationship with them.
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.
nostr:npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sf
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.
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
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.
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?
I was referring to relationship status indicators being a bad idea. Not really sure what parent note means about getting rid of mute lists; thatβs why I followed up with βhow do we mute people?β
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
