Support/Live Chat/Node.js: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
== What? ==
== What? ==


This page outlines the work being done to implement a server that will work with an AJAX-based Live Chat frontend. The goal is to eventually replace the existing Java-based Live Chat system.
This page outlines the work being done to implement a server that will work with an AJAX-based Live Chat frontend. The goal is to eventually replace the existing Java-based Live Chat system.  


<br>


== Repository ==
== Repository ==


The project has been codenamed "Inko" (Parakeet in Japanese). The repository for the new code is hosted on GitHub, at [http://github.com/endtwist/inko].
The project has been codenamed "Inko" (Parakeet in Japanese). The repository for the new code is hosted on GitHub, at [http://github.com/endtwist/inko http://github.com/endtwist/inko].  


<br>


== Roadmap ==
== API  ==


* June 10: Authentication
See: http://wiki.github.com/endtwist/inko/web-api
** Find existing Django session ID in cookie √
** Extract Django session data from database √
** Create new "chat session" ID cookie √
*** Use modified Session library from Express to store data (in memory?) √
** Retrieve chat permissions from database √
** Add authentication check (against stored session) to each page load √
** Automatically authenticate user upon first load of chat system, if logged in. Otherwise, redirect them to the login.


* June 17: Basic Messaging
<br>
** Build "Message" object that will contain all of the important message data and serialize it into a json object
** Create a "Room" object that will allow both 1-on-1 and multi-user conversations to be initialized.
** Guests should only be allowed in one room at a time?
** How to hash room names/keep them private?
** /message -> allow users to create new Message objects with data
** Add filtering for messages that will strip any potentially-harmful data (<tags>, etc.)
** Add CSRF verification.
** /listen -> add listener for new Message objects using long polling


* June 24: Watchers
== Roadmap  ==
** Allow authorized users (check perms) to join 1-on-1 rooms
** Messages in rooms should be broadcast to all users
** Watchers should not be allowed to speak in rooms
** Add ability to pass conversations to other users
** Agent interface as reference implementation


* July 1: Group Chat & Guest Interface
*June 10: Authentication
** Guest interface as reference implementation
**'''<sup>[√]</sup>''' Find existing Django session ID in cookie
** Multiuser rooms should have their own set of user permissions? (Op/H-Op?)
**'''<sup>[√]</sup>''' Extract Django session data from database
** Add ability to kick users from chatrooms. Ban?
**'''<sup>[√]</sup>''' Create new "chat session" ID cookie
***Use modified Session library from Express to store data (in memory?)  
**'''<sup>[√]</sup>''' Retrieve chat permissions from database
**'''<sup>[√]</sup>''' Add authentication check (against stored session) to each page load
**'''<sup>[√]</sup>''' Automatically authenticate user upon first load of chat system, if logged in. Otherwise, redirect them to the login.


* July 6: Non-Authenticated Guests
*June 17: Basic Messaging
** Allow guests that are ''not'' authenticated to join the support queue.
**'''<sup>[√]</sup>''' Build "Message" object that will contain all of the important message data and serialize it into a json object
** Setting and updating a user's status
**'''<sup>[√]</sup>''' Create a "Room" object that will allow both 1-on-1 and multi-user conversations to be initialized.
** Agent-Agent private chat
**'''<sup>[√]</sup>''' Guests should only be allowed in one room at a time?
**'''<sup>[√]</sup>''' How to hash room names/keep them private?
**'''<sup>[√]</sup>''' /message -&gt; allow users to create new Message objects with data
**'''<sup>[√]</sup>''' Add filtering for messages that will strip any potentially-harmful data (&lt;tags&gt;, etc.)
**'''<sup>[√]</sup>''' Add CSRF verification.
**'''<sup>[√]</sup>''' /listen -&gt; add listener for new Message objects using long polling


* July 6 - 10: Summit 2010!
*June 24: Watchers
**'''<sup>[√]</sup>''' Allow authorized users (check perms) to join 1-on-1 rooms
**'''<sup>[√]</sup>''' Messages in rooms should be broadcast to all users
**'''<sup>[ ]</sup>''' Watchers should not be allowed to speak in rooms
**'''<sup>[√]</sup>''' Add ability to pass conversations to other users
**'''<sup>[√]</sup>''' Agent interface as reference implementation


* July 15: Logging
*July 1: Non-Authenticated Guests
** Message/conversation data needs to be logged somewhere
**'''<sup>[√]</sup>''' Allow guests that are ''not'' authenticated to join the support queue.
**'''<sup>[√]</sup>''' Setting and updating a user's status
**'''<sup>[√]</sup>''' Agent-Agent private chat


*July 6 - 10: Summit 2010!


=== Notes: ===
*July 15: Guest Interface
* Agents must be approved before they can pick questions from the chat queue.  This is currently the "Live Chat helpers" group on sumo
**'''<sup>[√]</sup>''' Guest interface as reference implementation
* Also, room monitors have permission to watch any chat room, open/close the queue, and set other helpers' limits.
**'''<sup>[√]</sup>''' Chat queue status (queue positioning/time estimate)


*July 22: Logging & Group Chat Permissions
**'''<sup>[ ]</sup>''' Add ability to kick users from chatrooms. Ban?
**'''<sup>[ ]</sup>''' Message/conversation data needs to be logged somewhere


== Features currently used in Live Chat XMPP server ==
<br>


=== Core chat features ===
=== Notes  ===
* Automatic scrollback log when users join a conference
* Individual status for each signed in user.  (Online/Away/etc)
* Private messaging between conference members
* Storage of all logs, along with metadata, in a database for later access
* Wiki formatting and links
* Individual messages up to 30KB each
* Chat sessions up to 2MB each
* Notification when another user is typing
* Join/part notifications
* Topic for each room
* Ability to invite other users into a conference
* Up to 50 users chatting at a time in up to 50 conferences, with up to 600 combined messages per minute
* Access control for users in conferences
** Permission to join
** Permission to invite
** Permission to kick
** Permission to set the topic


*Agents must be approved before they can pick questions from the chat queue.&nbsp; This is currently the "Live Chat helpers" group on sumo
*Also, room monitors have permission to watch any chat room, open/close the queue, and set other helpers' limits.


=== Chat queue features ===
<br>
* Ability for up to 50 people to be waiting in queues at once
 
* Fair dispatching of requests to available helpers, based on specific criteria
== Features currently used in Live Chat XMPP server  ==
* Ability of helpers to set their chat limit
 
* Access levels to determine who can receive questions from the queue
=== Core chat features  ===
* "Room monitoring" ability that allows privileged users to join or monitor any chat in progress
 
* Metadata associated with each room entered by the user being helped, including question/OS/version/useragent/plugins/etc (AAQ)
*Automatic scrollback log when users join a conference
* Tag data associated with each room, either entered by helpers or automatically detected
*Individual status for each signed in user. (Online/Away/etc)
* Integration with CSAT surveys to track which chats are successful
*Private messaging between conference members
* Integration with support forum for users who need to follow up
*Storage of all logs, along with metadata, in a database for later access
* Ability for a monitoring helper to take over a conversation
*Wiki formatting and links
* Ability for privileged users to open/close the chat queue
*Individual messages up to 30KB each
* Automatic chat queue status based on number of people signed in and the number of people waiting. (Must automatically close when the queue is "full")
*Chat sessions up to 2MB each
* Give people waiting in queue updates on their current queue position
*Notification when another user is typing
*Join/part notifications
*Topic for each room
*Ability to invite other users into a conference
*Up to 50 users chatting at a time in up to 50 conferences, with up to 600 combined messages per minute
*Access control for users in conferences
**Permission to join
**Permission to invite
**Permission to kick
**Permission to set the topic
 
=== Chat queue features ===
 
*Ability for up to 50 people to be waiting in queues at once  
*Fair dispatching of requests to available helpers, based on specific criteria  
*Ability of helpers to set their chat limit  
*Access levels to determine who can receive questions from the queue  
*"Room monitoring" ability that allows privileged users to join or monitor any chat in progress  
*Metadata associated with each room entered by the user being helped, including question/OS/version/useragent/plugins/etc (AAQ)  
*Tag data associated with each room, either entered by helpers or automatically detected  
*Integration with CSAT surveys to track which chats are successful  
*Integration with support forum for users who need to follow up  
*Ability for a monitoring helper to take over a conversation  
*Ability for privileged users to open/close the chat queue  
*Automatic chat queue status based on number of people signed in and the number of people waiting. (Must automatically close when the queue is "full")  
*Give people waiting in queue updates on their current queue position
 
<br>
 
== Staging ==
 
* Software requirements are outlined in the repo: [http://github.com/endtwist/inko http://github.com/endtwist/inko]
* The server needs to daemonize itself.
** PID should go into /var/run/
** Log file should go into /var/log/
*** It would be best to rotate logs with logrotate.
* Restarting the server occurs how?

Latest revision as of 16:10, 30 July 2010

What?

This page outlines the work being done to implement a server that will work with an AJAX-based Live Chat frontend. The goal is to eventually replace the existing Java-based Live Chat system.


Repository

The project has been codenamed "Inko" (Parakeet in Japanese). The repository for the new code is hosted on GitHub, at http://github.com/endtwist/inko.


API

See: http://wiki.github.com/endtwist/inko/web-api


Roadmap

  • June 10: Authentication
    • [√] Find existing Django session ID in cookie
    • [√] Extract Django session data from database
    • [√] Create new "chat session" ID cookie
      • Use modified Session library from Express to store data (in memory?)
    • [√] Retrieve chat permissions from database
    • [√] Add authentication check (against stored session) to each page load
    • [√] Automatically authenticate user upon first load of chat system, if logged in. Otherwise, redirect them to the login.
  • June 17: Basic Messaging
    • [√] Build "Message" object that will contain all of the important message data and serialize it into a json object
    • [√] Create a "Room" object that will allow both 1-on-1 and multi-user conversations to be initialized.
    • [√] Guests should only be allowed in one room at a time?
    • [√] How to hash room names/keep them private?
    • [√] /message -> allow users to create new Message objects with data
    • [√] Add filtering for messages that will strip any potentially-harmful data (<tags>, etc.)
    • [√] Add CSRF verification.
    • [√] /listen -> add listener for new Message objects using long polling
  • June 24: Watchers
    • [√] Allow authorized users (check perms) to join 1-on-1 rooms
    • [√] Messages in rooms should be broadcast to all users
    • [ ] Watchers should not be allowed to speak in rooms
    • [√] Add ability to pass conversations to other users
    • [√] Agent interface as reference implementation
  • July 1: Non-Authenticated Guests
    • [√] Allow guests that are not authenticated to join the support queue.
    • [√] Setting and updating a user's status
    • [√] Agent-Agent private chat
  • July 6 - 10: Summit 2010!
  • July 15: Guest Interface
    • [√] Guest interface as reference implementation
    • [√] Chat queue status (queue positioning/time estimate)
  • July 22: Logging & Group Chat Permissions
    • [ ] Add ability to kick users from chatrooms. Ban?
    • [ ] Message/conversation data needs to be logged somewhere


Notes

  • Agents must be approved before they can pick questions from the chat queue.  This is currently the "Live Chat helpers" group on sumo
  • Also, room monitors have permission to watch any chat room, open/close the queue, and set other helpers' limits.


Features currently used in Live Chat XMPP server

Core chat features

  • Automatic scrollback log when users join a conference
  • Individual status for each signed in user. (Online/Away/etc)
  • Private messaging between conference members
  • Storage of all logs, along with metadata, in a database for later access
  • Wiki formatting and links
  • Individual messages up to 30KB each
  • Chat sessions up to 2MB each
  • Notification when another user is typing
  • Join/part notifications
  • Topic for each room
  • Ability to invite other users into a conference
  • Up to 50 users chatting at a time in up to 50 conferences, with up to 600 combined messages per minute
  • Access control for users in conferences
    • Permission to join
    • Permission to invite
    • Permission to kick
    • Permission to set the topic

Chat queue features

  • Ability for up to 50 people to be waiting in queues at once
  • Fair dispatching of requests to available helpers, based on specific criteria
  • Ability of helpers to set their chat limit
  • Access levels to determine who can receive questions from the queue
  • "Room monitoring" ability that allows privileged users to join or monitor any chat in progress
  • Metadata associated with each room entered by the user being helped, including question/OS/version/useragent/plugins/etc (AAQ)
  • Tag data associated with each room, either entered by helpers or automatically detected
  • Integration with CSAT surveys to track which chats are successful
  • Integration with support forum for users who need to follow up
  • Ability for a monitoring helper to take over a conversation
  • Ability for privileged users to open/close the chat queue
  • Automatic chat queue status based on number of people signed in and the number of people waiting. (Must automatically close when the queue is "full")
  • Give people waiting in queue updates on their current queue position


Staging

  • Software requirements are outlined in the repo: http://github.com/endtwist/inko
  • The server needs to daemonize itself.
    • PID should go into /var/run/
    • Log file should go into /var/log/
      • It would be best to rotate logs with logrotate.
  • Restarting the server occurs how?