Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Story] Indicate when calls are unsupported in the timeline/notifications #2563

Closed
7 tasks done
manuroe opened this issue Oct 9, 2024 · 13 comments
Closed
7 tasks done

Comments

@manuroe
Copy link
Member

manuroe commented Oct 9, 2024

Description

  • As a callee
  • I want to know when I am missing a call that my client cannot participate in
  • So that I can contact the caller and let them know I am unable to answer their call and they don't feel ghosted.

Acceptance criteria

Legacy side:

  • An incoming notification for an Element Call m.call.notify event will be delivered saying there is an unsupported call.
    • We should check the m.mentions property to make sure the notification is intended for this user, but the type doesn't matter as we will never ring.
    • String: "Unsupported call"
  • In the timeline an Element Call m.call.notify event will show a timeline item to indicate an unsupported call.
    • No need to worry about the m.mentions here, a call has been placed, let the user know if they're in the timeline.
    • String: "Unsupported call. The new Element X app is needed to join this call."

EX side (already implemented although we might want to tidy up the copy):

  • An incoming notification for an m.call event will be delivered saying there is an unsupported call.
  • In the timeline that same m.call event will show a timeline item indicating an unsupported call.

Leads

Size estimate

None

Dependencies

  • None

Out of scope

  • Group calls
  • There will be no notice if the notifcations on the room are disabled. There is no call ringing in this case on legacy apps. They are both the same case. So, the consequence is the same: the caller will be ghosted forever.

Open questions

Questions

Preview Give feedback
No tasks being tracked yet.

Subtasks

Android

Preview Give feedback
  1. bmarty
  2. T-Task
    bmarty

iOS

Preview Give feedback
  1. pr-misc

Web

Preview Give feedback
No tasks being tracked yet.

Other

Preview Give feedback

bugs

Preview Give feedback

Sign-off

Android

  • Design sign-off on completion
  • QA sign-off on completion
  • Product sign-off on completion

iOS

  • Design sign-off on completion
  • QA sign-off on completion
  • Product sign-off on completion
@manuroe manuroe changed the title [Story] Send a warning to the caller making legacy call if the callee is using EX [Story] EX: Send a warning to the caller making legacy call Oct 9, 2024
@manuroe manuroe changed the title [Story] EX: Send a warning to the caller making legacy call [Story] EX: Send a warning to the caller making a legacy call Oct 9, 2024
@mxandreas
Copy link

mxandreas commented Oct 9, 2024

do we want to display a popup asking for confirmation before sending like "Alice is trying to call you using legacy call. Do you want inform them they should use Element Call to reach you"

Given, this is a temporary/workaround, I would keep it simple and without confirmation. I think it does not compromise privacy much, only exposes that one is using EX.

Are we ok with "The notice will be in the language of the callee EX app"?

I think that is fine; even hardcoding to English is also probably fine.

In terms of the message itself, I would propose something like:

"Bob may not be able to answer your call since you're using legacy calling. Please use Element X to reach them".

@manuroe
Copy link
Member Author

manuroe commented Oct 9, 2024

We had a tech discussion about it. We are all aligned that we need a long term plan for the migration from lecacy calls to Element Calls BUT we cannot go quick to implement it, even with the band aid solution described in the issue. We tried to not overthinking but we kept raising concerns. It makes think we cannot converge in a better solution than what we have now in the 1 or 2 days of work allocate for this.

From the meeting:
Problems:

  • Privacy concern: the app is going to automatically send message in place of the callee
  • Several clients can generate several notices, poluting the timeline
  • Privacy concern: it will advertise the app the callee is using
  • Tech: we need to manage timeline resets. A stupid and simple implementation will create bugs that we are going to manage

Discussed options:

  • Implement this-auto sending in the SDK where it manages call notifications
  • Another user flow: The user taps the incoming call notification -> the app opens on the room -> the app sends the notice
    • Problem: there is no notification if the user is already looking at the room
  • Ideally: we need MSC work to address it properly like having a negotiation setup step in the call flow. But it is going to budgeted time by a lot
  • EX could send m.call.reject to say "sorry, can't answer now as you need to speak MatrixRTC". We then make a trivial change to the legacy apps to display that appropriately
  • For group calls, we could display the Jitsi link in the timeline. It implies to add Widget API support in EX.

@manuroe
Copy link
Member Author

manuroe commented Oct 9, 2024

The current solution is that the callee gets a notification and a timeline item saying "Call in progress (unsupported)". Then, the callee can they interact with the caller to find a way to communicate.

image

Another option could be to iterate on the wording on this not useful information in the timeline. The copy could invite the callee to engage and chat with the caller.
Doing so, we could revisit the mechanism that computes the call state in that timeline item. It is not working well.

@bmarty
Copy link
Member

bmarty commented Oct 9, 2024

Note: if by "notice" we're talking about m.notice msgtype, we will need to handle element-hq/element-x-android#3636 as well on Android.

@davidmehren
Copy link

Instead of just showing "Call in progress (unsupported)", could you not display the Jitsi link, so the callee may join using the Jitsi app or their browser?

@ara4n
Copy link
Member

ara4n commented Oct 10, 2024

How about we spec m.call.reject code which EX can send to say "sorry, can't answer now as you need to speak MatrixRTC". We then make a trivial change to the legacy apps to display that appropriately?

@manuroe
Copy link
Member Author

manuroe commented Oct 10, 2024

Instead of just showing "Call in progress (unsupported)", could you not display the Jitsi link, so the callee may join using the Jitsi app or their browser?

Thanks for the hint. We were focused on the DM case but we could definitely used the Jitsi link for group calls. We just™️ need to make Element X support the widget API :/

How about we spec m.call.reject code which EX can send to say "sorry, can't answer now as you need to speak MatrixRTC". We then make a trivial change to the legacy apps to display that appropriately?

Oh, yes. @bmarty raised it too. I added it to the list

@manuroe
Copy link
Member Author

manuroe commented Oct 31, 2024

I edited the user story indicating what we are going to experiment on Legacy and EX mobile apps. This changes follow the meeting we had with @bmarty and @pixlwave (https://docs.google.com/document/d/13GQLlgFZrJXlERKUYxaUUfm8QSqcvn937b7UBQ_AzGs/edit?tab=t.0_)
The EX team is starting this project. Once we are happy with the solution, the EW will join. Hopefully, EW will be able to apply the same logic as legacy mobile apps.

@manuroe manuroe changed the title [Story] EX: Send a warning to the caller making a legacy call [Story] Send a warning to the caller making a legacy call Oct 31, 2024
@pixlwave
Copy link
Member

pixlwave commented Nov 7, 2024

I've updated the story with the solution we discussed in the room.

@pixlwave pixlwave changed the title [Story] Send a warning to the caller making a legacy call [Story] Indicate when calls are unsupported in the timeline/notifications Nov 7, 2024
@bmarty bmarty self-assigned this Nov 12, 2024
@manuroe
Copy link
Member Author

manuroe commented Nov 13, 2024

Testing session

Alice is on EX apps and EW. Bob, on legacy apps and EW.

The tests are done for each versions of the mobile apss: EA, EXA, EI and EXI. EW can make both Element Calls and legacy calls.

Legacy side

We must have unsupported banner for:

  • Alice (EX) calling Bob (E)
  • Alice (EW x EC) calling Bob (E)

No unsupported banner. The call just works:

  • Alice (EW x Legacy call) calling Bob (E)
  • Alice (EX) calling Bob (EW)

EX side

We must have unsupported banner for:

  • Bob (E) calling Alice (EX)
  • Bob (EW x lecacy call) calling Alice (EX)

No unsupported banner. The call just works:

  • Bob (EW x EC) calling Alice (EX)
  • Bob (E) calling Alice (EW)

@manuroe
Copy link
Member Author

manuroe commented Nov 13, 2024

I checked some items but we need to discuss notificaiton for EC calls in legacy apps: https://github.com/element-hq/element-android-rageshakes/issues/72241.

@manuroe
Copy link
Member Author

manuroe commented Nov 19, 2024

The EA notification bug has been fixed in element-hq/element-android#8945.

The whole feature will be available in those versions of legacy and EX apps:

  • EA 1.6.23
  • EXA 0.7.4
  • EI 1.11.21
  • EXI 1.9.6

@manuroe manuroe closed this as completed Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants