Add message timestamps and attributes

Messages should optionally allow timestamps indicating the time a message was sent. Also, a system for additional message attributes should be added to support style-specific per-message options. For example, an attribute describing emoji reactions to a message.

Specification:

• Attribute format:
  • Attributes are key-value pairs enclosed by square brackets, with key and value separated by an equal sign.
    • e.g. [key = value]
    • Square brackets inside of attributes must be escaped with backslashes, e.g. [title = Title \[with brackets\]]
    • Equal signs do not need to be escaped, since only the first equal sign is detected.
      • Attribute keys may not contain equal signs.
  • Timestamps are a special form of attribute without an equal sign. Timestamps must be in an accepted format as described in the Timestamps section.
    • e.g. [12:30], [1999-12-31 23:59]
  • Attributes can be applied to individual messages, or to a conversation as a whole.
  • Message attributes and timestamps are specified before or after the username, but before the colon indicating the start of a message.
    • e.g. [key = value] username: message or username [key = value]: message
    • Messages may have any number of attributes.
  • Conversation attributes and timestamps are specified on their own line, without a username or message.
    • e.g. [title = Group Chat Name]
• Timestamp format:
  • Timestamps are specified in ISO-8601 date/time order, with various short forms allowed.
    • [yyyy-mm-dd hh:mm:ss]
    • [yyyy-mm-dd hh:mm]
    • [mm-dd hh:mm:ss]
    • [mm-dd hh:mm]
    • [hh:mm:ss]
    • [hh:mm]
  • The time portion of timestamps can be in 24-hour time, or 12-hour using an optional meridian.
    • [23:59]
    • [11:59 pm]
    • [11:59pm]
  • Timestamps relative to previous messages can be used:
    • [+Nd]: N days after previous message
    • [+Nh]: N hours after previous message
    • [+Nm]: N minutes after previous message
    • [+Ns]: N seconds after previous message
    • [+N]: N seconds after previous message (shorthand)
    • TODO: decide if + should be optional
    • TODO: combine formats like [+1h 3m 4s]? or [+3:21]?
• Timestamp rules:
  • Timestamps can be used as a message attribute to set the time that message was sent.
  • Timestamps can be used as a conversation attribute to set the "current" time in the conversation.
    • Including relative timestamps. If a conversation ends in [+1d], then the last message will appear as if it was sent a day ago.
  • Timestamps can never be earlier that the previous timestamp in the conversation.
    • Too bad for time travelers, but allowing that would make this even more complicated than it is already.
  • The first timestamp in a conversation determines the conversation's level of time specificity.
    • If the first timestamp only has hours and minutes, then only hours and minutes will be displayed. Messages older than a day will appear as 1 day ago, 5 days ago, etc.
    • If the first timestamp only has months, days, hours, and minutes, then yearless dates will be displayed. Messages older than a year will appear as 1 year ago, etc.
    • If the first timestamp is relative, then only relative times will be used, e.g. 2 minutes ago, 6 months ago.
  • Subsequent timestamps must not increase specificity.
    • If the first timestamp has only hours and minutes, than later timestamps may not include years, months or days.
    • If the first timestamp is relative, than later timestamps cannot be absolute.
  • If timestamps are not used in a conversation, then they'll be disabled and absent from the rendered result.
• Auto intervals:
  • Messages without a timestamp will be given timestamps that are later than the previous messages' by the conversation's time interval.
  • Time interval is specified as the timeinterval or ti conversation attribute.
    • e.g. [ti=1m] or [timeinterval=5s]
  • Default time interval is something reasonable, e.g. 30 seconds.
• Rendering:
  • Styles will decide how to process and display timestamps, allowing different behavior for different styles.
  • Styles will have access to conversation and message attributes, allowing them to use them for style-specific purposes.