10:32 < jpwhiting> 21:59:12> jonnylamb: how does one set the timestamp for an 
                   incoming message on the TpMessage?
...
10:32 < jonnylamb> 22:01:51> or tp_message_set_int64 (msg, 0, 
                   "message-received", time (NULL));
10:32 < jpwhiting> 22:02:53> jonnylamb: ah, ok, is there a list of what headers 
                   are possible to set?
10:32 < jonnylamb> 22:03:05> yes.
10:32 < jonnylamb> 22:03:28> the spec.
...
10:32 < oggis_> 22:03:31> in the tp spec which you're not supposed to need to 
                read :)

Apps doing advanced things, and particularly CMs, will always need access to extension points like tp_message_set(), but we could make life easier for typical clients and even simple CMs.

Things a client may want to set before submitting a message (i.e. read/write for TpMessage):

* header: sender-nickname
* header: message-type

Things a CM may want to set before signalling a sent/received message (i.e. read-only for clients, settable for CMs - either on TpMessage or TpCMMessage):

* header: message-token
* header: message-sent
* header: message-received
* header: scrollback (indirectly gettable via tp_message_to_text())
* body: truncated (indirectly gettable via tp_message_to_text())

Things that are already covered adequately:

* header: pending-message-id (settable via TpCMMessage)
* header: message-sender, message-sender-id (gettable via
  TpSignalledMessage, settable via TpCMMessage)
* header: rescued (settable via the TpMessageMixin)

More complex, do them later (e.g. clone the bug):

* header: supersedes, original-message-sent, original-message-received
  (support for superseded messages; the latter two must be optional)
* body: convenience API for specific use-cases, e.g. HTML body after
    Bug #15449 has been solved

Things that are too complex, and should just use the extension-point API, because anyone using them is expected to be reading the spec anyway:

* interface
* body parts in general (not just specific use-cases)