Discover Your Chat Channels To Accomplish Team Communication Efficiently
While emails are still well-streamlined forms of communication channels, but they are not always convenient or the most efficient means at times. This is where live chat channels are getting popularized and used efficiently. Chat channels enable companies to engage via live conversations irrespective of time and user base.
Chat channels can be used anywhere between the businesses demanding immense real-time communications. Channel chat is more conveniently used in sectors such as customer service, retail, Marketplace, Healthcare communication, Enterprise communication and much more to list. These varied number of chat channel use cases in industries and sectors deserves a completely feasible communication platform that has the potential to handle users privately and as well as publicly. This is how the role of MirrorFly’s Channel gets featured. MirrorFly offers chat channels that can be both public and private depending upon the chat channel use cases. A public channel group can also be created to discuss & engage with a vast number of participants simultaneously.
Everything You Should Know About MirrorFly’s Chat Channels
A private channel cannot be seen or joined directly. The gate pass to entering these channels are only via REST invites. The creator and the admin members of the private channel will be given access to a unique invite that they can pass around for people to join their group. These are visible only to participants and will decrease channel synchronization time at client start.
A public channel, on the other hand, can be seen and joined by all members of the application.
These channels are built over an XMPP protocol extension that is based out of generic publish-subscribe functionality which follows the classic “observer” design pattern where a user publishes information, and an event notification (with or without payload) is broadcasted to all authorized subscribers. The focal point for publication and subscription is a “node” to which publishers send data and from which subscribers receive event notifications. Nodes can also maintain a history of events. To create such a node, a special IQ is used.
In order to create a channel, the client posts an IQ that is responsible to create the channel and a separate IQ that is to set the profile identity of the channel. The creation of IQ is as follows.
<iq type="set" to="xyz@mix.samplemirrorflyChat.domain" id="abcd123"> <join xmlns="urn:xmpp:mix:0"> <subscribe node="urn:xmpp:mix:nodes:messages"></subscribe> <subscribe node="urn:xmpp:mix:nodes:presence"></subscribe> <subscribe node="urn:xmpp:mix:nodes:participants"></subscribe> <subscribe node="urn:xmpp:mix:nodes:subject"></subscribe> <subscribe node="urn:xmpp:mix:nodes:config"></subscribe> </join> </iq>
When a member has to join either a public or private channel, a request IQ is posted to the system like the one below.
<iq type="set" id="abcd123" to="xyz@mix.sampleMirrorflyChat.domain"> <query xmlns="jabber:iq:mixgroupchat" status="add participants module"> <participants> <participant>sampleParticipant@sampleMirrorflyChat.domain</participant> </participants> <subscriptions> <subscribe node="urn:xmpp:mix:nodes:messages"></subscribe> <subscribe node="urn:xmpp:mix:nodes:presence"></subscribe> <subscribe node="urn:xmpp:mix:nodes:participants"></subscribe> <subscribe node="urn:xmpp:mix:nodes:subject"></subscribe> <subscribe node="urn:xmpp:mix:nodes:config"></subscribe> </subscriptions> </query> </iq>
Here we see that the sample participant is subscribed to receive the presence, participant details, subject, configurations and all messages posted to the xyz channel.
Some standard mix nodes as listed in XMPP.org
| Name | Node | Description |
|---|---|---|
| Messages | ‘urn:xmpp:mix:nodes:messages’ | For publishing messages. Each item of this node will contain a message sent to the channel. |
| Subject | ‘urn:xmpp:mix:nodes:subject’ | For publishing the subject of the channels |
| Participants | ‘urn:xmpp:mix:nodes:participants’ | For publishing the list of participants (identified by anonymized bare proxy JID), and identifying the nick. This is a list of users who would receive messages (by subscription to the messages node) and/or would receive presence (by subscription to the presence node). |
| JID Map | ‘urn:xmpp:mix:nodes:jidmap’ | For publishing a list of anonymized bare JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs. |
| Presence | ‘urn:xmpp:mix:nodes:presence’ | For publishing information about the availability status of online participants, which may include multiple clients for a single participant. |
| Information | ‘urn:xmpp:mix:nodes:info’ | For storing general channel information, such as description. |
| Allowed | ‘urn:xmpp:mix:nodes:allowed’ | For storing JIDs that are allowed to be channel participants. |
| Banned | ‘urn:xmpp:mix:nodes:banned’ | For storing JIDs that are not allowed to be channel participants. |
| Configuration | ‘urn:xmpp:mix:nodes:config’ | For storing channel configuration. This information will generally be restricted to the channel owners. |
To summarize,
1. An entity publishes information to a node at a publish-subscribe service.
2. The Pubsub service pushes an event notification to all entities that are authorized to learn about the published information.
Alex Sam is a digital marketer by choice & profession. He munches on topics relating to technology, eCommerce, enterprise mobility, Cloud Solutions and Internet of Things. His other interests lies in SEO, Online Reputation Management and Google Analytics.