Federated typing indicators with same userId

[SystemKeeper]

Since it's not directly related to federated calls, I thought creating a new issue makes the most sense.

While testing #12604 I was unable to get typing indicators to work at first. For my testing I used the same userId on both servers, so I basically had 2 admins in my conversation:

Since we suppress typing indicators for ourselves, the federated indicator did not show up, but the signaling messages from that user were received fine.

Purely from the signaling message, I don't see a way to distinguish if it's "my" userId or a federated one:

{
  "type": "message",
  "message": {
    "sender": {
      "type": "session",
      "sessionid": "Tco...",
      "userid": "admin"
    },
    "data": {
      "type": "startedTyping",
      "to": "2fJ7u..."
    }
  }
}

[fancycode]

You should rely on the sessionid in the sender to find out who sent a message. If it's your own (as received in the hello response), you sent the message, otherwise it's somebody else. You receive the other session ids in the join events.

[SystemKeeper]

Yes, but if I have a session on web and one on iOS, currently when I type on web, I don’t show myself as typing in iOS. But this is not possible with the session id ?

[fancycode]

Besides, message are never sent back to the own session:
https://github.com/strukturag/nextcloud-spreed-signaling/blob/1d68bdd8df7e826102217db3a278abcbd0b7804e/hub.go#L1729-L1732

[fancycode]

Yes, but if I have a session on web and one on iOS, currently when I type on web, I don’t show myself as typing in iOS. But this is not possible with the session id ?

Oh, I see, that's right.

So what I could do is add a flag in the join event for the federated sessions, so you can differentiate from there, e.g. save the entries from the join events, use the sessionid from the typing indicator to lookup the entry and check the (tbd) federated flag. Would that solve your issue?

[SystemKeeper]

Yes, having a federated would solve it. Then we could check userId == myUserId && !federated. But I am wondering if it would be easier to just add the federated flag to the typing message itself? Either on the signaling server or by the client, as the client also knows that it’s a federated room.

[fancycode]

We might need the information for other parts in the future, too. Also I would rather have it only once in the join event than including it in every typing message.

[SystemKeeper]

Just to be sure (I don't know right now on the top of my head), when I join a room where participants are already there, do I still receive a join for those that are already part of the conversation? And there's no chance that a typing message would be received before I receive a join message, right? I guess then it would work as well and we can just map the session.

[fancycode]

You will receive join events for all sessions already in the room. As they are sent asynchronously (especially in clustered setups), there is a small chance that a typing message could be sent while these join events are being sent.

How do you get the display name to show with the typing status? Don't you use the session id to lookup the entry from the join events already?

[fancycode]

Flag added in strukturag/nextcloud-spreed-signaling@fc0591b

[SystemKeeper]

How do you get the display name to show with the typing status? Don't you use the session id to lookup the entry from the join events already?

That is a very good point indeed 😂 Yes, then this would be absolutely fine. Thanks!

[nickvergessen]

Is there still something to do here?
If so for whom? Backend or Frontend/clients?

[SystemKeeper]

The flag was added and the handling was implemented on iOS. In theory frontend needs to also handle this, but might not be worth the effort.