The protocol request mode: postevent

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 hpassword.

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.

The event/log text the user is submitting. Carriage returns are okay (0x0A, 0x0A0D, or 0x0D0A), although 0x0D are removed internally to make everything into Unix-style line-endings (just \ns). Posts may also contain HTML, but be aware that the LiveJournal server converts newlines to HTML <BR>s when displaying them, so your client should not try to insert these itself.

Specifies the type of line-endings you're using. Possible values are unix (0x0A (\n)), pc (0x0D0A (\r\n)), or mac (0x0D (\r)). The default is not-Mac. Internally, LiveJournal stores all text as Unix-formatted text, and it does the conversion by removing all \r characters. If you're sending a multi-line event on Mac, you have to be sure and send a lineendings value of mac or your line endings will be removed. PC and Unix clients can ignore this setting, or you can send it. It may be used for something more in the future.

The subject for this post. Limited to 255 characters. No newlines.

(Optional) Specifies who can read this post. Valid values are public (default), private and usemask. When value is usemask, viewability is controlled by the allowmask.

Relevant when security is usemask. A 32-bit unsigned integer representing which of the user's groups of friends are allowed to view this post. Turn bit 0 on to allow any defined friend to read it. Otherwise, turn bit 1-30 on for every friend group that should be allowed to read it. Bit 31 is reserved.

The current 4-digit year (from the user's local timezone).

The current 1- or 2-digit month (from the user's local timezone).

The current 1- or 2-digit day of the month (from the user's local timezone).

The current 1- or 2-digit hour from 0 to 23 (from the user's local timezone).

The current 1- or 2-digit minute (from the user's local timezone).

Set an arbitrary (but restricted) meta-data property to this log item. See Chapter 30, Journal Entries Meta-data for the documentation of them and the list of valid names. You may send zero or more keys like this, one for each property you're setting.

(Optional) If posting to a shared journal, include this key and the username you wish to post to. By default, you post to the journal of "user" as specified above.

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 success was 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.".

The unique number the server assigned to this post. Currently nothing else in the protocol requires the use of this number so it's pretty much useless, but somebody requested it be returned, so it is.

The authentication number generated for this entry. It can be used by the client to generate URLs, but that is not recommended. (See the returned 'url' element if you want to link to a post.)

The permanent link address to this post. This is an opaque string--you should store it as is. While it will generally follow a predictable pattern, there is no guarantee of any particular format for these, and it may change in the future.