Google Source: Process Typing Indicator Events via Websocket

[steffh]

Is your feature request related to a problem? Please describe.

We should process typing indicator events so relevant conversational interfaces such as our Airy Inbox UI are able to indicate to logged in users that relevant contact is still typing.

Describe the solution you'd like

Relevant events are being received in the following format:

{
  "agent": "brands/BRAND_ID/agents/AGENT_ID",
  "requestId": "REQUEST_ID",
  "conversationId": "CONVERSATION_ID",
  "customAgentId": "CUSTOM_AGENT_ID",
  "sendTime": "SEND_TIME",
  "userStatus": {
    "isTyping": true | false,
    "createTime": "CREATION_TIME",
  },
}

Source: https://developers.google.com/business-communications/business-messages/guides/build/events#receive

We should process and send them via the web socket but not via the webhook to avoid noise as mostly synchronous clients benefit from such real time events (compare with Slack RTM API vs. Slack Events API).

Describe alternatives you've considered

Additional context

[chrismatix]

Same comment as for the Facebook ticket: https://github.com/airyhq/airy/issues/2122#issuecomment-877141751

[steffh]

Copying @chrismatix comment from https://github.com/airyhq/airy/issues/2122:

Processing typing indicators on the websocket/webhook

In case the agent was typing, the contact would not be present in payload.metadata, but maybe that's rather weak and puts more pressure on the clients. Or would you rather suggest to move the typed_at property into the contact object in that case?

The entire metadata object is always present. And yes, putting typed_at on the contact field makes sense 👍

Also from the perspective of the clients it might be really hard to screen the payload object for keys to determine whether typed_at is defined or not. Looking at the way you implemented tags and channel updates having their own types as documented here (https://airy.co/docs/core/api/websocket#channel) it might justify having a separate event type instead of just sending a metadata event?

Introducing a separate event

In our taxonomy conversation metadata is any optional data associated with a conversation. That's not true for tags and channels, which is why we made them separate entities. Therefore I am against introducing a separate entity for that.

Clients' ease of parsing

In Javascript languages, this is fairly easy to do, but I see how this can become cumbersome at some point. There are ways of making this look and behave a bit more like the Google userStatus webhook event, but I would discuss and plan them once we get there.

[steffh]

@chrismatix - I agree with the general logic you apply regarding the question whether it should be a separate event, however I think we cannot fully ignore that while tags and channels are separate entities and don't relate to a conversation in the way conversation metadata does, we are looking at events here that we receive in a specific format as outlined above.

Maybe we should try to transform the relevant event only as much as needed and stay agnostic about the event as much as possible.

Given that we market Airy as an open source conversational platform with unified messaging APIs, I think what we cannot do is simply swallow events that people might want to receive had they decided to not use Airy in between the source and their app, but connected their app directly to the source.

Obviously, the more we transform the event instead of just passing it through, the easier it gets to work with our solution and to remove logic from the clients (e.g. to differentiate between Google typing indicators and typing indicators from other sources such as Slack, etc.). However, the more we transform these events and create our own metadata updates from them, the more we need to support on our end.

So in this case, I would support your perspective and implement it as suggested, but we need to be careful not to prevent more complex use cases like the Slack typing indicators where there is added complexity because of several participants in a channel and in the end it's relevant to know who is typing.

Even within the Airy inbox app, we could benefit from showing User Agent A that User Agent B is typing, so we should design the metadata event in a way that the clients have a chance to understand what is happening and who is doing what.

[chrismatix]

Sorry for leaving this hanging for so long @steffh. Fully agree with your points and would thus layout the conversation metadata like so:

{
  // ... conversation
  metadata: {
    typing: {
      "user/conversation-id": "last typing time"
    }
  }
}

conversation-id here indicates that the contact was typing last, whereas user id indicates the same for the agent. This design would also work for multi-participant sources in the future. Let me know what you think.

[chrismatix]

@steffh in an effort to close this: Do you agree with the above design?