BluePrint: Chat

Introduction

The Blueprint aims at development of a real time chat system for Sahana Eden.

Description

• Provide a chat board through which users can help each other or get help from the system administrator.
• Perhaps have one chat for each organization or project.

Requirements

Necessary features

We expect to need the ability to...

• Show which users are online.
• Maintain a chat history, and allow users who are members of a chat to see its history.
• Apply access controls to the chat and its history, i.e. selectively permit users to enter a chat and see its history.
• Assure security for messages.

Desirable features

These may include the ability to...

• Ping users to alert them that a message is directed to them.
• Call users to the chat if they are not present.
• Send out messages to a user who is offline, using their designated contact methods, and receive messages into the chat from external channels such as Twitter or SMS.

Advanced Features

• Easily switch to the user's email / SMS / Phone to contact them if they are not available by chat
• Status Updates
• History
  • Store chat history in DB (per-room & per user<>user private chat with appropriate permissions).
  • Scheduled task to prune.
  • Allow access to view this history from within the client 1 day/1week/1month/3months.
  • User can override archiving.
• VoIP
  • Single-user
  • Multi-user
• Video
• Whiteboard
• Screen Sharing
• File Transfer

Stake Holders

• The End Users: the group of end users would like to have a communication channel through which they can contact each other.

• Developers - Instead of using an IRC the people who contribute to Sahana Eden can find themselves at a one stop platform to clear various doubts or have a technical discussion.

• Site Administrator, Site Operators.

Need

Many organizations and people use Sahana Eden. Eden Chat will be a medium of communication between organizations and users. It would allow users to remain on a single platform and accomplish the task they want to perform without the need to go over 3rd party software to communicate.The chat would be integrated with Eden features that would help making tasks easier such as customized commands(like in irc) for accomplishing different tasks by different users. It would have the capability of seeing online users and message on mobile incase the user is offline. This would make communication easier since one need not any other information to contact other user.The chat could allow to send map images or map location from Eden Map to other user. The chat would be much more secure than irc and it will have better privacy than irc. We want to be able to provide the ability for users to be able to message each other in real-time.

This is useful for compliance reasons as well as just convenience.

Examples

Examples of existing chat facilities, pointing out features that may be desirable or difficult to mimic:

• IRC

• Skype
  • Shows when someone is typing, which permits "conversation pacing" -- holding off to allow the other to post, or to see what they're about to say, and to not "speak over" an in-progress conversation. This is necessarily not easy to implement.
  • History is available, and can be disclosed to new users entering the chat.
  • Shows the user the messages they missed when they sign on -- this could be a very desirable feature.

• Assorted "instant messaging" services.

• GChat, Facebook Chat (meaning the user-to-user real-time chat, not email threads or the FB timeline).

• Comments sections of web sites
  • The main feature of interest here is threading -- is it of use to allow people to designate their post as a reply to another post? This might help alleviate the "speaking over another convo" issue. Might help with conducting meetings.
  • Comments are usually not posted in realtime, so that's not the aspect being made an example of here.

• ​Atlassian HipChat
  • This may be the closest parallel to Eden-hosted chat, as it is specifically intended and designed for work teams. It would be worth looking at the features offered and the UI.

Use Case Diagram

Server Design

There are several options for implementing the server.

• Implement it within Eden, using the Eden framework, building on existing systems such as the msg module.
• Run a separate chat server, using an existing chat package, to which Eden calls across as needed.
• Use an existing, external service, such as freenode, Skype, HipChat, IM.

Internal to Eden

• Use the msg module for processing and storage of messages.
• Represent chat rooms as groups -- the users participating in the chat are members of the group.
  • Groups are very flexible, as they can be created for any association of users.
  • Teams will already exist as groups, so can just have their chat feature enabled by an admin.
• Use the group's inbox to hold the chat history.
• No need for logging in to a separate server, or duplicating users in a separate server.
• No need for "integration".
• Add a "real time" processor for chat messages in the msg queue. This would:
  • Store messages in the group's chat / inbox.
  • Launch requests to update users' chat windows.
• File transfer could consist of uploading a document via the doc module, and posting out a link to it in the chat.

Run a separate chat server

• Run a chat server, preferably an open-source package, and call across to it from Eden.
• Populate its user database as needed.
• Provide single-signon.
• Some options:
  • ​ejabberd
  • ​OpenFire

Use an external, existing service

• For preference, provide single-signon by some means.
• If the service is web-hosted, display the UI within an Eden page.

Client Design

Viable Clients

• Converse.js : ​https://conversejs.org/

Will allow us to authenticate users using sahana eden authentication. It also supports OTR which makes it secure.

• ​https://github.com/cryptocat/cryptocat
• ​http://www.igniterealtime.org/projects/spark/

For an Eden-based server

• Look for appropriate, existing JavaScript packages, or at least examples.
• Need only the UI, not any protocol.
• Eden could implement the client-server part of an existing chat protocol to leverage a particularly appealing JS client. Unless the client is very desirable, implementing the protocol may be wasted effort...
• ...unless users wanted to provide an existing external chat service (e.g. one of the IM services) as a contact method.

For an external service

• The UI would be that of the external service, perhaps with styling.

VoIP

Assuming single-user:

• ​http://mumble.sourceforge.net
• Flash client included in ​http://frug.github.io/AJAX-Chat/

Implementation

This is suggested as a GSoC project for 2014. Students can edit this blueprint, and should also link to their proposals, and optionally wiki pages with any additional ideas, investigation, and work.

• ​GSoC 14 - Chat in Sahana Eden by ​Arnav Kumar Agrawal(irc nick: knowing42)

References

<Links to external resources>

Msg module

Code:

• ​https://github.com/flavour/eden/blob/master/modules/s3/s3msg.py
• ​https://github.com/flavour/eden/blob/master/modules/s3/s3notify.py
• ​https://github.com/flavour/eden/blob/master/modules/s3/s3parser.py
• ​https://github.com/flavour/eden/blob/master/modules/s3db/msg.py
• ​https://github.com/flavour/eden/blob/master/models/tasks.py
• ​https://github.com/flavour/eden/blob/master/controllers/msg.py

Previous GSoC work:

• http://eden.sahanafoundation.org/wiki/Event/2012/GSoC/MessageParsing
• http://eden.sahanafoundation.org/wiki/Event/2013/GSoC/MessageParsing

Separate chat server

Professional XMPP Programming with JavaScript and jQuery: ​http://professionalxmpp.com/

---

BluePrints