Currently trying to register will cause a fatal error of "Terms login stage not found", if the server doesn't provide and T&Cs.

The chatterbox footer should include links to the Element enterprise chatterbox marketing material (for potential customers using chatterbox to find out more about it and purchase it), and to matrix.org, for those that want to find out more about Matrix.

I suggest the following:

@steveloynes -- what is the best link to use for the chatterbox link (presumably linking to the new marketing site material)?

According to Rick's statement of what should be included in v1, it appears as though Chatterbox only currently supports "Join Room" (from Rick's Figma).

So this issue is about requesting the development of the "Responder group" operation mode, which involves (assuming my understanding is correct):

• The ability for one or more configured users to be invited to a room with the Chatterbox user.
• The ability to toggle between (via configuration):
  • All responder users being invited to a room (with the Chatterbox user).
  • One randomly selected responder user being invited to a room (with the Chatterbox user).

Related to #18. The current chatterbox timeline when initiating a session is probably a little cluttered and complex from an end-user point of view:

It would be great if we could hide / not display the timeline messges for the chatterbox user room join. Additionally we should either hide invite messages (as they are probably a little redundant form the end user point of view, or hide that they were invited by the chatterbox user (as they won't have taken any action to do so, and this could be quite confusing).

Or:

I have just installed chatterbox on my server. I find it very interesting. But what I ask myself all the time: if my registration
token is visible, how do I prevent someone from writing a bot that registers millions of users on my server?

In Hydrogen, clicking on the image opens up a lightbox but that can't happen in chatterbox

Is your feature request related to a problem? Please describe.
The documentation in this repo is pretty sparse, and in my attempts to play with it in my own deployment I've identified that my homeserver needs to allow registration, and that I will also need to presumably generate a registration token to be used to create new users (a feature that is pretty rare to encounter for most homeserver operators, since registration tokens are not supported by arguably the most popular Matrix clients element-[web|android|ios]). Unfortunately, I'm finding these things out simply by rather a lot of trial and error and watching the announcement video trying to glean any information I can, rather than from the setup instructions.

Describe the solution you'd like
I would like detailed information about prerequisites to use Chatterbox included in the setup instructions.

Describe alternatives you've considered
Use an alternate project - but then I'm not using chatterbox :)

Describe the solution you'd like
Currently all chat users are "new" users. With the application token new users are created. In our environment we have all our clients registered in Matrix. By making the config.json endpoint dynamic (should send cookie credentials retrieving it) we could provide a predefined session token in the config for the known user. This helps us to identify the user (#63) and detect the preferred language for our bot.

Describe the bug

• Be logged into Chatterbox from a previous session.
• Click on the chatterbox icon, no chat window is rendered yet.
• Chatterbox creates a new DM (apparently doesn't know about any previous ones)
• Room is created. Chatterbox then tries to fill the room gaps (which don't exist yet, /messages returns an empty chunk)
• An error is recorded: room.fillGap(): Invalid end token in response
• The chatterbox icon hides itself

Screenshots

• Browser: Chromium
• Version: 103

Describe the bug

When a new user tries to chat with me from my page, it seems that the registration on my homeserver is too slow and the user is greeted with an error. Reloading the page or pressing the chat button again corrects the problem. It seems like some race condition from the chat app while waiting for the user registration to complete.

To Reproduce

• The first time a user visits my page and click the chat icon, the chat box will produce the following error:

  Something went wrong…can't access property "kind", i is undefined

• In the console, I can see repeatated calls to the register endpoint of my server

• Reloading the page OR pressing the chat button again will make chat work properly

Expected behavior
The chat window to load properly on first key press without any error.

Screenshots

Desktop (please complete the following information):

• OS: Windows
• Browser Firefox Developer
• Version 103.0b7 (64-bit

Additional context
Same behavior in different browsers and on different devices.

for more personalized support from the representative on the other side :)

this should probably be optional as some installations will find it valuable to have the user jump right in

Chatterbox doesn't have a license, we should fix that :)

Describe the bug
A clear and concise description of what the bug is.

To Reproduce

1. Open chat support in the browser

Expected behavior
Show the close bar

Screenshots

Smartphone (please complete the following information):

• Device: Android
• OS: 12
• Browser Firefox
• Version 103.2.0

It seems not to calculate the address bar with the available height of the screen.

Reading the wiki:

The registration module also (optionally) checks the MAU count of chatterbox users and if the count matches/exceeds the allowed maximum number of users, it will block the registration token until the count drops or the maximum is increased (to reduce the chances of bill-shock for the EMS customer).

-- https://gitlab.matrix.org/new-vector/internal/-/wikis/Chatterbox

I was curious what actually happens when you run into the limit.

The screenshot explains some of it:

Monthly Active Users

You will be charged based upon the number of people using Chatterbox each month.

If you go over your configured limit, Chatterbox will not present itself to users until you increase the limit. You can change your limits by modifying the configuration below.

Questions

• Do we also notify agents that they're currently at/over the limit?
  • It would be weird to sit there as an agent with no incoming tickets and no way to tell what's going on.
  • How do we notify?
  • Does the notification include instructions for how to increase the maximum?
• Is there a courtesy reminder/warning when you reach a threshold of your MAU limit?
• Do we provide a graph of your MAU over time?
  • As a chatterbox owner, this would better help forecast if the limit needs to be raised.

Describe the bug

When clicking on an image sent by a participant, I was served an nginx 404 page in Chatterbox's iframe. Upon hitting the "Previous" button in said iframe the frame is empty:

To Reproduce
Steps to reproduce the behavior:

1. Send an image
2. Click on it

Expected behavior
Not sure, are images supposed to be clickable?

Describe the bug
In our website we work with layers (z-index) and the button is attached at the body. In our case behind the carousel.

Expected behavior
It should be visible or be able to tune the z-index because even 1000 might be to low if it is set fixed.

It would be cool if we could bundle a standard looking website that includes the chatterbox iframe as a sort of preview. Doesn't need to be fancy, but the idea is a customer can navigate to chatterbox.element.io/preview and see an example of what their site would look like.

We would likely need to specify the config in the URL, somehow.

See #80 (comment)

Like #12, but for email.

Possibly some sort of button to essentially reset the state and have another go. This might be tricky in the case where we have operator bots and the chat might contain 3 people (might just need to make the operator leave in these circumstances).

The hs may change the username

Using Math.random() here seems wrong given it's not suited for cryptographic purposes

https://github.com/vector-im/chatterbox/blob/3c8df045579bce9682bd03e44b0e86f6fbb6a8d6/src/random.ts#L17-L29

I haven't looked into it very deeply, but it seems to me this is actually used for stuff that should use cryptographically strong random values

https://github.com/vector-im/chatterbox/blob/3c8df045579bce9682bd03e44b0e86f6fbb6a8d6/src/viewmodels/AccountSetupViewModel.ts#L40-L62

There can be quite a delay (with no feedback) after clicking "Accept and continue to chat", before anything happens (probably about 4 or 5 seconds for me

)

E.g. after hitting this button --^
@MidhunSureshR - Is there anything relatively easy that we can do to update the text to a spinner, and disable the button, or something, after clicking on it?

So that users can consent to T&Cs during their first interaction

When the following occurs:

1. chatterbox is opened
2. a room is created and invite_user is invited
3. a useful (?) chat is had
4. invite_user leaves
5. how does one initiate a new chat with invite_user? how does one start over?

Related to #44

The Chatterbox instance at https://chatterbox-staging.element.io/demo.html is intended for internal testing. As a staging instance it could break at any point. We should put it behind HTTP basic auth, to avoid the URL being leaked to the public and it becoming relied upon, externally.

Can we please set up a new instance of Chatterbox for general public testing / demo of the product.

• The instance should be on a live EMS domain, and associated with a live EMS host.
• The instance should have a simple auto-responder (similar to the staging demo instance)
• The instance should have the ability / credentials to log in as an admin to view and respond to demo interactions, if needed

Once the instance is set up it can embedded into a simple, stand-alone html page (like the one for the demo staging instance) and be publicised.

Later (as soon as possible) the instance should be embedded along-side content in the Element marketing site (Steve and marketing will need to drive this last bit, once everything else is up and running).

Chatterbox currently does not log when a user leaves the room, this would be useful so users don't just talk into the void.

Describe the solution you'd like
It would be great if you could configure a space for the chatterbox to create the rooms in. This would allow clients on the support providing side to group support-related rooms together.

Describe alternatives you've considered
The only alternatives I see is either to just have internal team rooms mixed with support rooms with external people or to manually move the support rooms to the space once I am invited to them.

If the user doesn't have an avatar, opt to not show anything over the current placeholder icon. Chatterbox users cant set avatars yet so it feels a little redundant.

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

E2EE is of very limited use if you can’t prove whether you’re talking to the right person or a MITM.

Describe the solution you'd like

Ability to view the olm public keys of the user you’re talking to, and be warned if they change, and have the option to verify them via device verification (and/or via some other out-of-band verification channel, e.g. an ID server)

This is quite subtle given trusting the website hoster to embed a non-malicious chatterbox means that even with verification, there's a risk of a malicious chatterbox being inserted into the mix if the host website wants to MITM its users. Suggestions welcome on how best to solve this one, as verification is useless if you can't trust the endpoint...

Additional context
https://news.ycombinator.com/item?id=32020476
https://twitter.com/MTRNord/status/1545089701698306050

It's likely that hosts using chatterbox may want to enable captcha (EMS does this).

We should probably 404, or redirect to chatterbox.html?

Rick says:

For chatterbox, specifically, I think that it would probably make most sense not to have header text at all, rather than a room name, in most cases.

E.g. Chatterbox seems to pick the first flow it is given by the registration API.

// (env) ➜  synapse curl -X POST --data '{}' https://cb-staging.ems.host/_matrix/client/v3/register
{
    "session": "ruZGCVZpMIHmvVDUMvOsEmZM",
    "flows": [
        {
            "stages": [
                "m.login.terms",
                "m.login.dummy"
            ]
        },
        {
            "stages": [
                "m.login.terms",
                "m.login.email.identity"
            ]
        },
        {
            "stages": [
                "m.login.terms",
                "m.login.registration_token"
            ]
        }
    ],
    "params": {
        "m.login.terms": {
            "policies": {
                "privacy_policy": {
                    "version": "1.0",
                    "en": {
                        "name": "Privacy Policy",
                        "url": "https://cb-staging.ems.host/_matrix/consent?v=1.0"
                    }
                }
            }
        }
    }
}

The above is an example of a flow from a host with public registration enabled. Chatterbox should ideally be opting to use flow 3, rather than flow 1.

Currently, chatterbox displays fairly long and unweildy user IDs for new users by default (as shown in the screenshot below). It would be good to be able to set a default value to be shown as the display name of the chatterbox user in the local client if one has not been specified (e.g. displayname === undefined or displayname === matrixUserId).

Ideally this would simply be a local representation of the display name in the client, rather than setting the Matrix display name for the chatterbox users, as this would result in all chatterbox users appearing the same in full Matrix clients like Element-web, and could cause confusion, for example in the Element-web left panel.

For now it would be good for the default, local display name for chatterbox users to be "Me". However, it would be good for this to be easily changable in futture, as we may wish to use other values like "Guest" etc., instead.

Describe the bug
Attempt to run the application locally with yarn start resulted in an error in the chatterbox window when starting a new chat.

Full error:

Something went wrong…
vm2 is undefined

This occurred while running mountView@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:4779:12.

render/<@http://localhost:3000/src/ui/views/ChatterboxView.ts:13:65
mapView/<@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:5231:31
_addReplaceNodeBinding@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:5179:26
mapView@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:5220:17
render@http://localhost:3000/src/ui/views/ChatterboxView.ts:13:9
mount@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:5027:25
mountView@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:4777:17
view@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:5217:12
mapView/<@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:5233:21
binding@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:5184:35
update@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:5051:9
_updateFromValue@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:4976:10
emit/<@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:10481:32
emit@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:10481:16
emitChange@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:20356:12
_showTimeline@http://localhost:3000/src/viewmodels/RootViewModel.ts:62:10
_setupNavigation/<@http://localhost:3000/src/viewmodels/RootViewModel.ts:29:74
emit@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:1082:8
emitIfChanged@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:20043:12
applyPath@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:19928:48
push@http://localhost:3000/node_modules/.vite/deps/hydrogen-view-sdk.js?v=37b91674:19914:17
completeRegistration@http://localhost:3000/src/viewmodels/AccountSetupViewModel.ts:70:21

To Reproduce
Steps to reproduce the behavior:

1. clone repository
2. modify public/config.json with server information, token information, invite_user value
3. execute yarn start to run test server
4. visit localhost:3000 and begin chat
5. chat window returned error above
6. invite_user user is successfully invited to a chat with the newly generated user, but web-chat user cannot interact with the conversation

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Arch Linux
• Browser Firefox
• Version 102.0.1

Additional context
All changes I've made are contained in the config.json. Full diff is below:

diff --git a/public/config.json b/public/config.json
index 62a90b9..53d1cba 100644
--- a/public/config.json
+++ b/public/config.json
@@ -1,18 +1,18 @@
 {
-    "homeserver": "https://your-homeserver.com",
+    "homeserver": "https://synapse.mssj.me",
     "auto_join_room": "Internal matrix id of the room",
     "username_prefix": "foobar",
     "header": {
         "title": "Your Fancy Title",
-        "avatar": "https://link_to_avatar/awesome.png"
+        "avatar": "https://www.mssj.me/images/logo.png"
     },
     "footer": {
         "chatterbox_link": "https://element.io/solutions/chatterbox-embedded-live-chat-for-customer-service",
         "matrix_link": "https://matrix.org"
     },
-    "token": "Valid Token to be used with Token Authenticated Registration",
-    "invite_user": "@botuser:your-homeserver.com",
+    "token": "REDACTED",
+    "invite_user": "REDACTED",
     "encrypt_room": false,
-    "avatar": "https://link_to_avatar/avatar.png",
+    "avatar": "https://www.mssj.me/images/logo.png",
     "disable_composer_until_operator_join": true
 }