editfriendgroups — Edit the user's defined groups of friends.
The protocol request mode:
Username. Leading and trailing whitespace is ignored, as is case.
The authentication method used for this request. Default is 'clear', for plain-text authentication. 'cookie' or any of the challenge-response methods are also acceptable.
Deprecated. Password in plain-text. For the default authentication method, either this needs to be sent, or
Deprecated. Alternative to plain-text
password. Password as an MD5 hex digest. Not perfectly secure, but defeats the most simple of network sniffers.
If using challenge-response authentication, this should be the challenge that was generated for your client.
If using challenge-response authentication, this should be the response hash you generate based on the challenge's formula.
(Optional) Protocol version supported by the client; assumed to be 0 if not specified. See Chapter 27, Protocol Versions for details on the protocol version.
Send a key in the form editfriend_groupmask_
friend is the friend's username. The value should be a string representing an unsigned 32-bit integer with bit 0 set (or the server will force it on anyway), bits 1-30 set for each group the friend belongs to, and bit 31 unset (reserved for future use).
Send a key of this type to delete the friend group with number
groupnum (which can be from 1-30, inclusive). The server will modify all old entries that allow access to that friend group, so a new friend group using that number won't have access to old non-related entries, and unset the bit for that friend group on the groupmask of each friend, unless your client sends the friend's new groupmask explicitly.
Create or rename the friend group by sending this key, where
groupnum is from 1-30. The value is the name of the group.
efg_set_ is sent, this field should be sent to indicate the sorting order of this group. The value must be in the range of 0-255. The default is 50.
efg_set_ is "1", then this group is marked as public. If public, other users can see the name of the group and the people that are in it.
OK on success or
FAIL when there's an error. When there's an error, see
errmsg for the error text. The absence of this variable should also be considered an error.
The error message if
FAIL, not present if
OK. If the success variable is not present, this variable most likely will not be either (in the case of a server error), and clients should just report "Server Error, try again later.".