How a proper ignore function should work
-
IMO, it should ignore all posts by ignored users, and it's descendants (all replies and replies to replies and etc). And mute notifications caused by them.
There should be a a button to toggle an unfiltered mode, in case you get lost on the discussion or curious.
Bonus points if there is an option that instead of hiding, just makes it gray and smaller, easier to ignore but readable if you feel like it.
-
@fbmac PMs should also be blocked.
-
A toggle button for ignored topics and categories would be cool too. Maybe sometimes you want to read the garage and sometimes not. Could be the same button.
-
@fbmac said in How a proper ignore function should work:
A toggle button for ignored topics and categories would be cool too. Maybe sometimes you want to read the garage and sometimes not. Could be the same button.
I believe you can ignore a category, yet still open it and find topics to review. The color of the topic link indicates whether you've caught up on that thread or if you have unread posts there.
-
@djls45 but if you ignore a topic it's a lot of work to find it again (if you don't remember the category it was)
-
@fbmac So maybe there should be a distinction between getting notifications for a thread and seeing it in your unread/recent posts feed? I think I could support that.
-
@fbmac You exterminated your Dalek?
Now I has a sad.
-
@fbmac Most of nodeBB is hard work. Try looking at the recent threads list and working out which threads you've contributed to, for example.
-
@tufty Fortunately, not a single one of us has ever contributed anything to this site that the world would be significantly worse for losing.
-
@flabdablet There is that, of course.
-
@tufty are you telling me to do work?
-
And what will happen when, say-- and surely this will never happen, but just in case-- y'know-- someone you ignored just necro'd a topic. Does that necro'd topic float to the top of your unread list or not?
-
@Lorne-Kates Ideally it wouldn't show on your unread.
-
@fbmac that would be really complicated to write, because only the ID to the direct parent of a post is actually stored. And some posts quote from multiple other posts, but can only have one "parent" post, so you'd have to do a bunch of parsing to find all the "parents" of a post, to decide whether to hide it... and if it had more than one parent, then that means that a hidden discussion could swallow another one that shouldn't have been hidden: say Alice and Bob both post in the same topic, but on different tangents of the discussion. Charles replies to both of them in one post, on both tangents. Alice replies to Charles' post as it referred to her own.
Now if you ignore Bob, you don't see Charles' reply, which was also referring to what Alice posted, or Alice's reply to Charles which isn't even talking about what Bob posted.
But even just the complexity issue would be problematic, because to determine whether any post is hidden you'd have to recursively check the post, every post that it quoted/replied to, every post that any of those posts quoted/replied to, and so on until you had a set of ancestor posts that were not replies and contained no quotations from other posts. If any post in that ancestry tree was by a user you'd ignored, the post would need to be hidden. You could reduce the complexity by, say, going back only n generations, but it'd still be a fairly large, complex search, and it'd have to be done for every post before displaying it.
-
@anotherusername I'm just saying what I think would be the perfect solution, without considering complexity.
If I were to implement it, I would look back only to the information that is already fetched from the database in a single request.
-
@fbmac I'm just saying, it seems like it'd be more complex than you think and would have undesirable side effects that you didn't think of.
-
How about implementing 'active ignores'?
Every time the ignored user makes a post, the system would automatically create a reply from the ignoring user saying "I don't care what you say, you're on my ignore list".
-
@anotherusername just delete all complicated and side-effecty corner cases.
Look back only what is already in memory, and if a post is in an hard to decide situation just show it.
-
@fbmac Yeah, no one here would ever complain about the inconsistency of that sort of solution.
-
@anotherusername said in How a proper ignore function should work:
But even just the complexity issue would be problematic, because to determine whether any post is hidden you'd have to recursively check the post, every post that it quoted/replied to, every post that any of those posts quoted/replied to, and so
Not if you keep a transitive reply-to relationship (with a flag that indicates whether it's a direct reply) in the DB.
-
@asdf then you'd be adding increasingly large numbers of reply-to relationships for each new post. Just for the 20 posts in this topic, you'd need the following list (if I didn't make any mistakes in compiling the list...)
parent parent_id parent_user child child_id child_user direct 0 1113670 fbmac 1 1113684 asdf TRUE 2 1113749 fbmac 3 1113801 djls45 TRUE 2 1113749 fbmac 4 1113805 fbmac FALSE 3 1113801 djls45 4 1113805 fbmac TRUE 2 1113749 fbmac 5 1113807 djls45 FALSE 3 1113801 djls45 5 1113807 djls45 FALSE 4 1113805 fbmac 5 1113807 djls45 TRUE 0 1113670 fbmac 6 1113823 flabdablet TRUE 2 1113749 fbmac 7 1113873 tufty FALSE 3 1113801 djls45 7 1113873 tufty FALSE 4 1113805 fbmac 7 1113873 tufty TRUE 2 1113749 fbmac 8 1113874 flabdablet FALSE 3 1113801 djls45 8 1113874 flabdablet FALSE 4 1113805 fbmac 8 1113874 flabdablet FALSE 7 1113873 tufty 8 1113874 flabdablet TRUE 2 1113749 fbmac 9 1113875 tufty FALSE 3 1113801 djls45 9 1113875 tufty FALSE 4 1113805 fbmac 9 1113875 tufty FALSE 7 1113873 tufty 9 1113875 tufty FALSE 8 1113874 flabdablet 9 1113875 tufty TRUE 2 1113749 fbmac 10 1113883 fbmac FALSE 3 1113801 djls45 10 1113883 fbmac FALSE 4 1113805 fbmac 10 1113883 fbmac FALSE 7 1113873 tufty 10 1113883 fbmac TRUE 11 1113983 Lorne-Kates 12 1114048 fbmac TRUE 0 1113670 fbmac 13 1118171 anotherusername TRUE 0 1113670 fbmac 14 1118214 fbmac FALSE 13 1118171 anotherusername 14 1118214 fbmac TRUE 0 1113670 fbmac 15 1118217 anotherusername FALSE 13 1118171 anotherusername 15 1118217 anotherusername FALSE 14 1118214 fbmac 15 1118217 anotherusername TRUE 0 1113670 fbmac 17 1118247 fbmac FALSE 13 1118171 anotherusername 17 1118247 fbmac FALSE 14 1118214 fbmac 17 1118247 fbmac FALSE 15 1118217 anotherusername 17 1118247 fbmac TRUE 0 1113670 fbmac 18 1118259 boomzilla FALSE 13 1118171 anotherusername 18 1118259 boomzilla FALSE 14 1118214 fbmac 18 1118259 boomzilla FALSE 15 1118217 anotherusername 18 1118259 boomzilla FALSE 17 1118247 fbmac 18 1118259 boomzilla TRUE 0 1113670 fbmac 19 1118904 asdf FALSE 13 1118171 anotherusername 19 1118904 asdf TRUE There's 42 relationships. And, it doesn't increase as a linear function... this post adds 3 more.
-
@anotherusername don't bring me problems, bring me solutions
-
@anotherusername
So? I thought MongoDB was web-scale.
-
@asdf web scale does not mean idiot schema proof.
-
@Jarry said in How a proper ignore function should work:
schema
TDEMSYR! We're talking about MongoDB here!
-
@Jarry Doesn't Mongo necessarily mean both "idiot" and "schema proof"?
-
@fbmac said in How a proper ignore function should work:
don't bring me problems, bring me solutions
Each post is stored with a set of the users involved in its construction. This set is quickly and easily constructed as the union of the user-sets of all posts referenced and the set of all users directly referenced in the post itself, including the author.
Sets can be stored as a simple list of user IDs, a list of user ID extents or a bitmap, whichever is more compact for any given post.
-
@flabdablet said in How a proper ignore function should work:
bitmap
So we should be using spatial database extensions for implementing this? Brillant!