SilberWitch on Nostr: Twitter used lists because it started out with MySQL (owned by Oracle), which is a ...
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.
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.