Add calendar extension for Brave Talk on Google Calendar

Question

Add calendar extension for Brave Talk on Google Calendar

mrose17 opened this issue 3 years ago · 9 comments

This is a fork/branch of the Jitsi calendar plugin in order to add a Brave Talk confab URL to a calendar entry. The idea is to put the CRX file on Brave Talk so folks who use Google Calendar can add a confab URL to the calendar invite, e.g.,

(Note that the icons are still Jitsi icons. These will be updated to Brave Talk icons soon.)

Answer 1 · 2021-11-17T13:28:55.000Z

It turns out this is fairly straight-forward, so i've bumped the priority.

Answer 2 · 2021-11-18T19:23:39.000Z

cf., https://github.com/brave/security/issues/669

Answer 3 · 2021-11-29T15:45:53.000Z

Now onto the design for phase 2: having the plugin "schedule" a room for subscribers, so they get moderator privileges!

Answer 4 · 2021-12-08T11:27:52.000Z

Creating the Room with Moderator Privileges

Context

Making use of the mechanics implemented for the /talk slack plugin (i.e. passing the create=y query parameter), it is possible for this chrome extension to generate a room name which will get created on first use, without any communication with talk.brave.com. This is what @mrose17 described as "turns out this is fairly straight-forward".

However, that approach comes with a significant limitation: the first subscriber to enter the room is the one who gains moderator privileges. We would obviously prefer the person who scheduled the call to have those privileges.

In order to achieve that, due to the unique privacy-focused model of talk:

the user's issued credentials need to be presented to the create room api call. These credentials are only present in talk.brave.com's localStorage.
the resulting jwt and refresh token need to be stored in talk.brave.com's localStorage.

Investigation 1

Use message passing to initiate room creation within the context of talk.brave.com.

Extensions communicate between their (global) service worker and content scripts injected to specific pages using the sendMessage api as described here.

However, on talk.brave.com we want to invoke the existing code within the page that creats a room. Standard web pages cannot participate in the extension-specific sendMessage api, so we need to inject a content script to talk.brave.com and convert those messages to postMessage calls, as described here. This results in a setup like this:

[diagram link]

Most of this is pretty simple and I've successfully prototyped much of it. The mechanics between steps 4 and 5 are ugly and error prone as postMessage is totally asynchronous and unlike sendMessage cannot return a response, so the content script injected into talk.brave.com would need to cache callbacks in order to tie up with the request from step 3.

However, dealing with failure cases is even more complex, the most obvious being that the user is not logged in as a subscriber. We can only discover this between steps 4 and 5, at which point presenting a UI to the user to login is difficult, as the tab will be in the background.