I often purposely leave threads 'unread' to get back to them later (in fact LQT says I have 9000+ unread messages), and either losing my 'home-made to-do list' or getting flooded with 9000+ Echo notifications would be intolerable.
It is still not clear to me how is Flow going to address my use case.

In T93109#1144459, @Ricordisamoa wrote:

I often purposely leave threads 'unread' to get back to them later (in fact LQT says I have 9000+ unread messages), and either losing my 'home-made to-do list' or getting flooded with 9000+ Echo notifications would be intolerable.

Echo uses a similar inbox model for Flow messages (it's unread until you visit it or mark it read), though I don't think many people have 9000+ unread Echo messages (how do you navigate the 9000 LQT messages, Ctrl-F on https://www.mediawiki.org/wiki/Special:NewMessages ?)

I think a cap of 2000 applies to your overall notification count. So that is probably the main area that would impact you.

Why exactly do you feel Echo would be more spammy than LQT with a big inbox? Note that by default, Flow does not send email notifications. So basically, with LQT you have, "New messages (9000)" in the personal bar, with Echo you have a box with 99+, then be able to page through them at Special:Notifications.

In T93109#1146622, @Mattflaschen wrote:

Echo uses a similar inbox model for Flow messages (it's unread until you visit it or mark it read)

I don't want it to be marked as read unless I explicitly click the button.

how do you navigate the 9000 LQT messages, Ctrl-F on https://www.mediawiki.org/wiki/Special:NewMessages ?

(Reply|Watch|Mark as read)*, Next page

I think a cap of 2000 applies to your overall notification count. So that is probably the main area that would impact you.

Why can't I have more than 2000 notifications?

Why exactly do you feel Echo would be more spammy than LQT with a big inbox?

The red indicator is meant for strictly personal notifications requiring immediate attention (e.g. user talk page messages, mentions, reverts).

Note that by default, Flow does not send email notifications. So basically, with LQT you have, "New messages (9000)" in the personal bar, with Echo you have a box with 99+, then be able to page through them at Special:Notifications.

Really? AFAICS Special:Notifications is missing nearly all of Special:NewMessages' features like reading whole threads, marking them as read, etc.

In T93109#1152194, @Ricordisamoa wrote:

In T93109#1146622, @Mattflaschen wrote:

Echo uses a similar inbox model for Flow messages (it's unread until you visit it or mark it read)

I don't want it to be marked as read unless I explicitly click the button.

That!

I think a cap of 2000 applies to your overall notification count. So that is probably the main area that would impact you.

Why can't I have more than 2000 notifications?

https://gerrit.wikimedia.org/r/#/c/159413/
https://www.mediawiki.org/wiki/Thread:Talk:Echo_%28Notifications%29/More_than_2,000_Notifications,_will_start_to_be_removed

In T93109#1152856, @He7d3r wrote:

https://gerrit.wikimedia.org/r/#/c/159413/
https://www.mediawiki.org/wiki/Thread:Talk:Echo_%28Notifications%29/More_than_2,000_Notifications,_will_start_to_be_removed

I know the how, what I miss is the actual reason.

The reason for the 2,000 notifications cap is that there's a performance hit when we have to store and render that many notifications. We hit a point where we knew we weren't going to be able to scale up, and we had to choose a number where it cuts off. We chose 2,000 because we figured if you have 2,000 unread notifications then you aren't really using the notifications. (Note that we bundle Flow notifications, so that's not 2,000 posts -- it can be as many as 2,000 threads.)

We're going to have to make some changes over the next month or two to Flow/Echo/watchlist behavior, to give people more control over how they configure their own notifications. We'll be sorting through the use cases that people have asked about so far, and we'll be asking for more. The managed "to-do list" is an important use case that Flow/Echo doesn't address well enough, and it's something that we're going to work on.

Also, in that Mediawiki.org conversation that you linked to, you asked: "What if I want to preserve important notifications and delete the newest instead?" It sounds like that's a different kind of feature -- that you're currently using notifications as either a searchable index of your past conversations, or a way to bookmark past conversations that you'll want to refer to later.

Those aren't tasks that a "notifications" feature is meant to support. It sounds like you were using notifications as a workaround to simulate a searchable inbox or conversation bookmark system. Those are really interesting use cases, and I can picture a few different features that could provide that functionality. It's not relevant to the this particular ticket, but if you want, we can keep talking about it somewhere else...

Change 200036 had a related patch set uploaded (by EBernhardson):
[WIP] Allow new notifications to be created with old timestamps

https://gerrit.wikimedia.org/r/200036

While trying to implement this, I've realized this is horribly underspecified. What do we mean by unread flow notifications?

It appears all notifications in LQT are the same, they each have:

• a user
• a thread (a topic, in flow terms)
• a conversation (this points to the 'topmost' post of a particular set of indented posts. In the LQT model imagine you click reply on something, you can determine the conversation by following the chain of replys up to the top level. You might think of this as an individual tangent of the thread).
• a read_timestamp

In flow we have 4 notifications we send out:

• flow-new-topic - Sent when a topic is created on a board you are watching
• flow-post-reply - Sent when there is a reply to a topic you are watching
• flow-post-edited - Sent when someone edits a post you made
• flow-topic-renamed - Sent when someone edits the title of a topic you created
• flow-mention - Sent where you are mentioned in a post.

At best guess it seems like we should send one flow-new-topic notification for each imported topic. We would find all users that have an LQT notification for the thread that was just imported, ignore the conversation and read_timestamp, and disable bundling.

The end result would be 1 new topic notification for each LQT thread they were watching. This sounds like only half an answer though...any suggestions?

I think flow-new-topic and flow-post-reply should be enough. Anything else is probably unnecessary.

How does LQT handle reply notifications? I assume it always notifies you for a new topic. For a reply to that, does it amend that previous notification/message, or create a new one? What about if you've already seen the topic, then a post is made?

In T93109#1155532, @Mattflaschen wrote:

I think flow-new-topic and flow-post-reply should be enough. Anything else is probably unnecessary.

How does LQT handle reply notifications? I assume it always notifies you for a new topic. For a reply to that, does it amend that previous notification/message, or create a new one? What about if you've already seen the topic, then a post is made?

The new comment appears highlighted at Special:NewMessages, and the counter in the top of the page is increased, for each new comment (if I remember correctly).

the table lqt uses for notifications has a primary key of (user, thread), essentially meaning there can only be one active notification per thread. Replys just make sure that a row exists in this table for the given user. Marking a notification as read just deletes the row from this table.

I've also just noticed that LQT does send notifications via Echo as well, i think these notifications will become unavailable when we disable LQT though. We could probably do something about that if we want. The links contained in them still all work, we aren't getting rid of the namespaces or the wikipages behind LQT. They are just edited into redirects which will go to the appropriate flow Topic page and have hashes to bring them to the particular post they came from.

I think we turn an existing LQT notification into a "new reply" Flow notification.

Basically, this conversion is going to generate a one-time set of transition notifications.

Depending on what choices we make, that transition could lead to one of two options:

• a lot of false positives (I have more notifications than I expected, what the heck are these? Make them stop!)
• a lot of false negatives (all the individual topic notifications got rolled up into just a few, where did my detailed notifications go?)

I think we'll get more false positives if we use "new reply" notifications -- people who are just passively watching the page will get individual notifications about all 34 topics that are active on that page.

We'll get more false negatives if we use "new topic" notifications -- people who are particularly interested in specific conversations will lose the ability to tell them apart.

We've got a better fail-safe system for false positives -- people who really don't care can click "Mark all as read", and the problem goes away. If we generate false negatives, then we don't have a way to help people untangle them.

So I think we go with "new-reply", generate some extra noise, and let people mark all as read.

In T93109#1154047, @DannyH wrote:

Also, in that Mediawiki.org conversation that you linked to, you asked: "What if I want to preserve important notifications and delete the newest instead?" It sounds like that's a different kind of feature -- that you're currently using notifications as either a searchable index of your past conversations, or a way to bookmark past conversations that you'll want to refer to later.

Those aren't tasks that a "notifications" feature is meant to support. It sounds like you were using notifications as a workaround to simulate a searchable inbox or conversation bookmark system. Those are really interesting use cases, and I can picture a few different features that could provide that functionality. It's not relevant to the this particular ticket, but if you want, we can keep talking about it somewhere else...

I'm not actually using notifications, I'm just not comfortable in this world of data with permanently losing information that was once available.

I can categorize most discussion notifications into one of these kinds:

• messages on my user talk page: the poster expects me to reply; if I don't, probably nobody else will
• mentions ('pings') from possibly unrelated discussions: requiring attention but not always a reply
• messages on threads on talk pages I watch: maybe interesting, maybe not
• messages on threads I directly watch: probably interesting, but I may not be supposed to reply

The first two categories ('noisy') require immediate attention and are worth a notification, but are mostly 'reply-and-forget', and Echo is just great at handling them.
The other two categories ('quiet') should not trigger an Echo notification but are likely to require my continuous attention - especially to watch for other users' replies - and LQT is the perfect fit.
What Flow is missing is a page like LiquidThreads' Special:NewMessages to handle important discussions in a quiet, clean, and scalable way.

Change 200238 had a related patch set uploaded (by EBernhardson):
Convert LQT unread messages into flow-post-reply notifications

https://gerrit.wikimedia.org/r/200238

@Ricordisamoa -- thanks for the summary of what you need. We're going to be working seriously on making the watchlist/notifications interactions more sophisticated and targeted for what different people want to see. It's not going to be part of this ticket, but we'll be coming back to you in a little while to ask more.

I just posted this to the flow conversion thread [1] without being aware this task.

Is there an equivalent to "Special:NewMessages" for Flow? I use this to keep important threads sticky in privacy. I probably could use personal categories for this once it is implemented (for MonoBook?) but these categories would not be private. I cannot really use my watchlist for this since I follow much more threads which only pop up when action takes place. So basically something inbetween inintial notification of a new post and watching all interesting threads will be cool.

This is just to cheer you up in terms of people will appreciate this feature while working on this.

[1] https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw

In T93109#1159160, @Kghbln wrote:

I just posted this to the flow conversion thread [1] without being aware this task.

//Is there an equivalent to "Special:NewMessages" for Flow?

Kind of, but not exactly. Flow notifications use an inbox metaphor (stuff doesn't get marked read without you explicitly opening the topic or marking it as read), but it's not intended you keep accumulating messages forever. There is a 2000 limit. Also, there is no way to mark unread (T94061), and it's not really designed for easily navigating a massive number of notifications (you *can* have 1999, but the experience isn't really intended for that).

It's somewhere between a transient notification and an email inbox.

Given those caveats, the closest thing is Special:Notifications.

I probably could use personal categories for this once it is implemented (for MonoBook?) but these categories would not be private.

Not sure what you're referring to here. Phabricator number?

This is just to cheer you up in terms of people will appreciate this feature while working on this.

As always, thanks for the feedback.

Kind of, but not exactly. Flow notifications use an inbox metaphor (stuff doesn't get marked read without you explicitly opening the topic or marking it as read), but it's not intended you keep accumulating messages forever. There is a 2000 limit. Also, there is no way to mark unread (T94061), and it's not really designed for easily navigating a massive number of notifications (you *can* have 1999, but the experience isn't really intended for that).

Indeed we are not talking about thousands of threads. Usually I have about 10 to 15 threads "sticky". Never seen "Special:Notifications" before. Just found it and figured out how to access it without directly typing the page name. But enhancing this special page with T94061 will be cool. Also removing threads and not just marking them as read will be nice.

Not sure what you're referring to here. Phabricator number?

It's T88114. As I see it is not implemented yet. I the past MonoBook usually lagged 6 to 12 months for cool stuff so I initially figured it might probably already be up and running for Vector.

In T93109#1168628, @Mattflaschen wrote:

Flow notifications use an inbox metaphor (stuff doesn't get marked read without you explicitly opening the topic or marking it as read), but it's not intended you keep accumulating messages forever. There is a 2000 limit. Also, there is no way to mark unread (T94061), and it's not really designed for easily navigating a massive number of notifications (you *can* have 1999, but the experience isn't really intended for that).

So it is designed to delight new users who will ask questions but piss off someone who could answer them?

In T93109#1170179, @Kghbln wrote:

Also removing threads and not just marking them as read will be nice.

T94689: Flow should allow hiding read messages from [[Special:Notifications]].

Change 200238 merged by jenkins-bot:
Convert LQT unread messages into flow-post-reply notifications

https://gerrit.wikimedia.org/r/200238

Change 202608 had a related patch set uploaded (by Mattflaschen):
Convert LQT unread messages into flow-post-reply notifications

https://gerrit.wikimedia.org/r/202608

Change 202608 merged by jenkins-bot:
Convert LQT unread messages into flow-post-reply notifications

https://gerrit.wikimedia.org/r/202608

Change 200036 abandoned by EBernhardson:
[WIP] Allow new notifications to be created with old timestamps

Reason:
went a different route with the LQT notifications

https://gerrit.wikimedia.org/r/200036

Which different route?

We didn't end up setting the timestamps for the imported notifications in the past. They are set to import time.

Change 200036 restored by Matthias Mullie:
[WIP] Allow new notifications to be created with old timestamps

https://gerrit.wikimedia.org/r/200036

Change 200036 merged by jenkins-bot:
Allow new notifications to be created with old timestamps

https://gerrit.wikimedia.org/r/200036