AddOn communications protocol As the number of addons using raid or guild communications is increasing it ' s become apparent that we need a community protocol for addon developers to use to standardize these comm functions . You can find discussion of this protocol on The US WoW forums or in Channel Management . There are two primary issues here , channel names and maintaining the channel connection , changing and chat suppression . Channel Names . Channel names have a 31 char limit and should be considered case - insensitive . Global . A simple global channel should be available , something like CommGlobal Group . A group channel should be provided , with a unique name derrived from the party or raid leader ' s name . If the player is in a raid a party channel will not exist , but party - - specific communication can be maintained by the addon receiving the messages by checking the sender against the party roster . Sample channel name with raid leader named Tekkub : CommRaTekkub Player names are unique within a realm , cannot contain spaces , and the name limit is 12 chars , but special characters are allowed . When we strip those characters out , there could be conflicts - - so we ' re going to use a checksum system here to prevent that . We can use the following function to strip out all special characters : There is a possibility that a channel name could conflict due to this , so addons using this channel should probably verrify that the sender of a message is in the raid or party before the message is parsed , but the checksum system should prevent most of this . You could use the following function to create group names ( where CheckSum is defined below ) : A group channel with leader " Tekkub " would become " CommRaTekkub21cdb4 " A group channel with leader " Clãdhaire " would become " CommRaCldhaire23e70a " A group channel with leader " Clædhaire " would become " CommRaCldhairebc9459 " Any addon or library maintaining connection to this channel must handle leadership changes smoothly . It must close connection to the old group channel and open connection to the new channel . Guild . A guild channel mechanism should be provided . This should not restrict the user to their current guild , as many guilds keep an " app guild " or " alt guild " wherein the players may need access to communication with the main guild ' s addon channel . The addon managing this channel should be able to give some sort of indication of the guild channel it is maintaining , so conflicts do not arrise but many guild channels could potentially be opened . Guild names have the same issues as playernames for the group channels , plus they can take spaces . So a checksum is used here as well , and all non - alphanumeric chars are stripped from the name . For example : " Khaz Modan Brigade " would have the channel CommGuKhazModadb3bb5 " Khaz Modan Reserve " would have the channel CommGuKhazModa0e3045 " KhazModanBrigade " would have the channel CommGuKhazModa4209dd " KhazMødanBrigade " would have the channel CommGuKhazMdanfa944d To get the guild name checksum , the following method can be used . It makes some concessions to prevent collisions in our specific case , but can be used as a general algorithm as well . In order to keep the channel names as clean as possible for the users , we ' ve capped the checksums to six hex characters . Thanks to Iriel for the suggestion . Using CheckSum and Strip from above , the following function could be used to get a full channel name from a string : Channel Management . There are a few things addons will need to do if they are using a channel : Global Registrar . A simple table could be used to maintain a registrar . Any addon using the comm protocol would look for this table when they need to register into a channel . If it doesn ' t exist they would create the basic empty table and add themselves in . Proposed table structure . AddonCommRegistrar = { Registering a channel . When registering into a channel , an addon should execute this block of code : Unregistering a channel . When an addon is done with a channel it needs to check if anyone else is using it , if noone is it should make sure the channel is departed . Leadership Changes . When the raid or party leader changes , each addon that uses the CommRa * channel should check to see if the switch has been made yet , if not it should perform the switch . Also it should be noted that leaving a channel has a slight delay , the best solution appears to be to delay 1 second between leaving and joining . Message throttling . Message throttling has it ' s advantages , but the jury ' s still out on if the protocol should require throttling or not , further details and discussion can be found at Addon Comm Throttling Chatframe Filtering . Here is a proposed hook for the ChatFrame _ OnEvent to block all Comm text from ever appearing in the default UI ' s chatframes . Note that only the first addon to register should implement this ( see sample in Registering a channel ) Message Protocol . A standard protocol for messages sent should be used to assure addons do not unintentionally receive other addon ' s messages . The proposed standard is : " < Namespace > : < message > " < Namespace > is some unique token that a develop ' s addons use . Some devs may choose to share a token across their addons , like " Tekkub " or they may make it addon - specific like " CTRA " . Handling of the < message > portion of the communication is entirely placed upon the receiving addon . This will allow for simple filtering of messages intended for other addons . It is recommended that use of the chars ' s ' and ' S ' in the < Namespace > section of the message be avoided , especially if the addon does not use a sobriety filter . For example , if the addon only communicates numbers the filter would not need to be implemented , it ' s just a wasted function in this case . Please see Addon Comm Sobriety Filter for possible implementations of this filter .