My tentative answers are:

1. Should we pursue this? Yes. I think this is a pretty natural direction for the product. The only real risk I see are that there are some things we won't be able to do as nicely as a native app can. Our mobile experience will also be iffy for a long time. Despite these disadvantages, I think real-time updates are all we need to build a good-enough application that can compete seriously against other options, and we can close the gap further with things like Desktop Notifications.
2. Add rooms to Conpherence? Yes. Chat software has private messages, this is just building them in the other order. I think these things are technically and conceptually similar.
3. How created? Explicit creation by default ("Conpherence > New Chat Room")? With an interface and an action "Create Chat..." from objects, which invites all the relevant users, attaches a transaction ("epriestley started a chat about this thing.")? Also maybe project tagging in chats. But I think weak binding is the way to go here, generally.
4. How do you find rooms? I think we need a new UI for this. I don't know where to put it.
5. How separate are the UIs? Mostly the same, but I think the room vs thread distinction probably ends up being fairly clear?
6. Participants? This is really fuzzy. I have a few ideas but I think this depends on (8). I'm also not sure how this interacts with the threads listed on the left in Conpherence.
7. Notification Rules I think we need separate defaults for rooms? Depends on (6) and (8).
8. Technical: Participants List This seems hard to do via the Aphlict server. I think v0 has to be browsers pinging the app servers every ~10 minutes, and maybe you "go idle" after one missed ping and are marked inactive after two. When browser windows close, we try to clean up participation. This will create some level of load, but it shouldn't be too bad, and app servers are relatively easy to scale.

Here's a very tentative plan for the last half of things:

• We add a new "browse rooms" UI somewhere (where?)
• You can view a room and read the chatlog without joining the chat.
• You can either explicitly "join", or implicitly join by chatting.
• When you've joined a room, it stays pinned to your left nav and you show up in the participants list.
• You can "leave" a room, which unpins it and removes you from the participant list.
• When viewing a room or thread, participants are shown in several states: active (browser window is open / recent activity), idle (was active recently, but no pings/activity for a few minutes), or inactive (user has joined the conversation, but is not monitoring it in real time -- they'll get messages you send, but not necessarily right away).
• Rooms have a new "invite" concept, where users are invited to become participants but not made into participants. This can happen when they're mentioned, via "start a chat about this thing". This basically just means that broadcasts and participant lists will be less spammy and more accurate for widely-disseminated messages: if you start a chat with 30 people and only 5 of them care, the other 25 just ignore the invite and don't have to deal with the thread.

I would expect Conpherences to gain Policies. Some are Public (readonly), some All Users, some restricted to Projects, and the way it works currently would be "Custom" where you've chosen the individuals. The create UI would need a lot of thought though to make this easy to navigate.

I'd just probably put the joined rooms above the private message Conpherences thread list. It seems to make the most sense.

A bit more detail on my thoughts:

My tentative answers are:

Should we pursue this?
Yes. It centralises yet another aspect of software development and makes it easier to communicate with other developers.

Add rooms to Conpherence?
Yes. I don't think that private messages or rooms are actually a different concept at all; one just has a view policy of "Participants of Conpherence Thread" and one has a view policy of "All Users" / "Public".

How created?
Change the "New Message" action in Conpherence to allow setting of policies for new rooms, and allow creation of messages without a target participant (i.e. the thread is created with just the current user).

How do you find rooms?
I think the sidebar of Conpherence should be reworked to something like the following:

• [Category Bar] Pinned Rooms
• General
• Random
• [Category Bar] Joined Rooms
• Blah
• Phabricator
• Something
• [Category Bar] Private Conversations
• @epriestley, @chad
• @hach-que
• [Category Bar] Search
• Search for Rooms

Pinned Rooms are threads pinned by administrators (or more accurately, whoever has the PIN_ROOMS application capability). This allows administrators to pin rooms for the entire instance (naturally, these must have a view policy of All Users or Public).

Joined Rooms are threads with a view policy of "All Users" or "Public" that the user is present in.

Private Conversations are threads that the user is present in but have a more restrictive policy than "All Users" or "Public". Participants of a thread get automatic view capability.

We should also probably use the edit policy to indicate who can actually post messages to a thread. This allows a view policy of "Public" to make sense, and means you could configure project threads where anyone can read, but only project members can post.

How separate are the UIs?
Identical because they're the same thing.

Participants?
With the policy configurations above, you'll be able to view a thread without actually being a participant. Users can either join manually if they have edit permission, or as soon as they post a message they automatically become a participate (posting a message also requires edit capability). Maybe we want something like a join policy as well, but this seems rather redundant?

Notification Rules
This should be configurable. Slack has the option of having notifications for new messages in any channel you're a participant in, or only notifications for private messages or public channels where you've been notified (e.g. someone writes @hach-que).

For smaller installs and groups, the former option is definitely desirable, where as large organisations would want the latter.

Technical: Participants List
Unlike the diff I posted, I think message notifications for threads should appear regardless of whether you have the thread open. This means someone is considered online under the following scenarios:

• They have desktop notifications on, and have Phabricator open anywhere.
• They have desktop notifications off, and are currently inside Conpherence with that tab in focus (where we might update the sidebar with (1) when new messages appear, so they'll know about new messages even when they aren't looking at the thread directly).

They are distracted / away under the following scenarios:

• They have desktop notifications off, and have Phabricator open anywhere, but are currently not looking at Conpherence.

They are offline under the following scenarios:

• They don't have Phabricator open at all, anywhere.

Of course, statuses are completely hidden if the notification server is not running or not configured.

This simplifies a lot of the checks we need to do, because:

• If they have desktop notifications on, then they are online if there is any Aphlict client connected on their behalf.
• If they have desktop notifications off, then we only need to toggle state when they start looking / stop looking at Conpherence, and can assume an away status otherwise.
• If there's no Aphlict clients connected for a user, then they're offline.

Unlike the diff I posted, I think message notifications for threads should appear regardless of whether you have the thread open.

This feels a little weird to me -- particularly, private message content appearing in plain view when showing a coworker something on my screen. Do you use other software which pops private message content into notifiations? ("epriestley sent you a message." seems fine, but including the content seems a little iffy to me.)

Slack does this and GMail / Google+ does it as well for their chat system. With the hangouts Chrome extension, hangouts pop up in a chat window, which not only shows you the new message but history as well. The polite thing to do as a coworker is to not read it :)

◀ Merged tasks: T5246.

◀ Merged tasks: T5099.

T5099 discusses a use case where the invite list for a room is locked to the members of some project.

Please make it more mobile friendly. Experience provided by Whatsapp would be great.

To summarize the javascript-heavy stuff in subtasks:

• Networking: T6559 has discussion about moving to WebSockets instead of Flash. It looks like WebSockets are really good in modern browsers (at the least, way way better than they were 4 years ago). In particular, they got rid of the most-incredibly-crazy part of the spec that I had the greatest difficulty with a few years ago. If this doesn't turn into a mess, this will make debugging and development a lot easier and let us get rid of all the ActionScript / Flash stuff. This will also give us realtime mobile support. bin/aphlict will get easier, too (no root required anymore).
• Sync: We need synchronization (basically, identifying one open browser window as the "leader", plus a couple of other inter-window communication things) to do one connection per browser instead of one connection per tab, play sounds only once, and send desktop notifications only once. We currently do this with Flash. D11235 has a proof-of-concept for doing it with LocalStorage instead. I'll build this out and get the correct primitives in place. We need this around the time we move to Websockets, and before we do sounds or desktop notifications.
• Sound: T5369 has a proof-of-concept for HTML5-based sound without much fanfare or complexity, versus the earlier Flash-based draft. Seems to work well. Depends on Sync.
• Desktop Notifications: This is T4139; this was never a Flash issue. Depends on Sync.

@joshuaspence has some steps toward WebSockets in D11143, I'll work with him (and/or commandeer all his revisions while he's asleep) to try to get us switched over.

For the most part, the APIs and stuff shouldn't change, but that should give you more solid technical footing for the product work.

Just throwing this on the Phacility workboard since we might roadmap it into a phase sooner than "Do Eventually".

Will this somehow federate with XMPP? Or could Phabricator become an actual XMPP client via RFC7395? That would allow a variety of existing clients to be used immediately.

See T1271 for Jabber/XMPP. We have no plans to build integration at this time.

Kicking this off Phacility 'cause it's just normal roadmap stuff.