Chat interface in sidebar for whatever page you're on

[JakeHartnell]

Moving this over from https://github.com/hypothesis/h/issues/147

@dwhly

You should be able to have an IRC like capability that's always live on every page. It might detect whether the browser tab is an active one, and show how many active h. users are on the page, etc.

This has the side benefit of giving people an outlet for banter that's not so serious, and thus allowing the annotations to reflect a more thoughtful dialogue.

The chat interface might be a separate sidebar view, or a small viewport at the bottom of every sidebar view.

[BigBlueHat]

I'd vote for TogetherJS integration / usage. Comes with audio and text chat as well as "co-browsing"--so you can see the other persons mouse (and highlights too, iirc).

[tilgovi]

@BigBlueHat I need some questions answered first. IIRC TogetherJS is WebRTC. That means that for n users there are n^2 connections. It's p2p, which is nice from a buzzword and control standpoint, but it may not scale as well as having a dedicated pub/sub chat server in the classic style.

[tilgovi]

I may also misunderstand WebRTC, but I don't think there's anything built-in for link topologies that aren't 1-1. Maybe it's something the TogetherJS project provides, or will provide? Also, maybe it's not as terrible a problem as I think. I should also clarify that it's not n^2. For any individual it's actually n-1.

[tilgovi]

The actual, total number of connections between peers would be n(n-1) / 2.

[BigBlueHat]

@tilgovi good thoughts. It looks like it's actually using WebSockets for the text chat and "co-browsing" and only uses WebRTC for audio chat.

I did some highlighting on the Technology Overview

[tilgovi]

Neat.

As slick as Together is, I'm not sure we're the target audience.

We most likely have strong UI integration needs, if this is to "fit" well in our interface rather than be an additional overlay.

We also have our own WebSockets infrastructure that we can build out. The path to chat there is actually not long, on the backend.

The only other thing I'm seeing that's potentially interesting is OT support for text areas. But for this there are other projects that are maybe lower level we might consider, so as to reuse aforementioned infrastructure for communication channels. Worth mentioning that I'd be really interested to know the failure modes of Together here, as most OT systems I've seen freeze when sync gets far behind, and we currently have a strong offline drafting story that gets stronger if we continue to lean towards using Pouch or similar.

So, good to have the notes here on this ticket. I'm not ruling it out, but I'm not very optimistic about using Together. Whoever first looks at this ticket next should assess all this.

For now, though, this is likely months off, if we get to it in the next year.

[BigBlueHat]

Cool. We might also give delta-pouch a look. It's early days for it as well...but given 6+ months, it might be ready and/or we could help it get there. :smile:

[ianb]

Multiparty WebRTC is tricky, and requires things like servers to put all the video streams together. There are some services that try to make this reasonable (e.g., TokBox), but they aren't generally free. Hotdish used some crudely hacked together stuff to activate TogetherJS whenever two people in a session were on the same page, which might be something like the effect you want.

When doing serendipitous sessions on a page, our experience is that you do not want form sync. The bad cases are really unfortunate, like when two people open https://github.com/hypothesis/vision/issues/new – they probably intend to have two truly separate sessions. With TogetherJS you will typically explicitly join a session, so it's not so bad, but with Hotdish it was more implicit. What we would have liked to do is actually just display the other person's activity, and maybe allow people to explicitly opt-in to syncing a form (or maybe just use Hotdish's presentation mode for that).