Looks complicated but correct. Reviewing this thoroughly might take more time, but I haven't found any issues yet.

Now we're "defaulting" to the condition. Is this change intentional, and does it potentially introduce any issues?

After simplifying the condition it seems like the inverted logic shouldn't work properly.

The approach is ok, but it isn't a good practice to copy the code. For all the messages we use (almost?) the same logic - can we reuse it?

An approach looks better, but we're duplicating a lot of logic. We should reuse it by e.g. introducing functions with common parts. Accepting, to not block the goal, but please improve this later.

I'm not sure if this is necessary to have this filter on keyserver, but it also shouldn't hurt.

A couple of nits but overall looks ok

Looks ok to me

In D6455#193305, @ginsu wrote:

When we have a couple of reactions, it is not clear to which of these the number corresponds.

@tomek could you elaborate on what you mean by the number these correspond to?

When we have a couple of reactions, it is not clear to which of these the number corresponds.

We're copying a lot of complicated logic. Can we reuse it in a different way?

I'm not really sure what's the plan here, probably it will be clarified later, but at this point it seems like we're hacking the solution by introducing something really similar to the tooltip. It feels like a better solution might be to extract the common part and use it inside our old tooltip and reaction tooltip, but I'm not yet sure.

Is this diff going to crash any dev app that has saved navigation state with an open tooltip?

It might be a good idea to check how this code performs on a slower Android device when there are a lot of matches and a text is long. It seems like memoization could be a good idea here - in class components we can achieve that by using createSelector, chat-thread-list contains an example.
If the performance is ok, we don't have to complicate the code.

The images from test plan don't show for me. The solution is described here: https://www.notion.so/commapp/Attaching-files-and-images-on-Phabricator-af8e2195fc91462689cc8de5c96a6759

Looks ok, but I think we should reconsider the design a little bit. For me, it feels like clicking on a community in calendar app should result in the community being highlighted.

The test plan worries me a bit. What happens when users update the application? Do they need to fresh install the app? Or maybe, we assume that the existing users already received the token and this function will be called just for the new users?

Accepting, but we should probably replace the observer with calling getCurrentState on every notif.

I'm not sure if this is the best solution. Usually in cases like this, we could introduce a new class e.g. horizontal and check it in selectors: we would have span.chatBadge selector and span.chatBadge.horizontal. This allows splitting the code which depends on the orientation from the code that doesn't. On the other hand current solution is still maintainable, so we can consider keeping it.

The test plan should also include testing this functionality while the app is running / backgrounded.

Looks ok but it is a good idea for @bartek to also take a look.

Are we still using io.invertase.firebase.messaging anywhere?