mitter.io. The design of mitter.io tries to assume as little as it can about Messages in general or the data they contain. The system is designed to be extremely flexible around the type of data a Message can contain. A Message has two important constraints: it requires a sender to be sent, and that it must have a text representation of the data it is sending. This can be an empty string as well but it is not recommend. There are other situational constraints as well, which will be discussed further in this section. A Message as other
identifiablesis identified by a unique identifier, which can be overriden. The standard restrictions for an identifier apply as usual:
messageIdcontains the unique identifier of this message.
messageTypeholds the type of this message. A message type defines handling parameters for this message. It is a closed set of values, and must be one of
Notification. Currently, only
payloadTypedefines the type of data that this message contains. By default mitter.io provides support for certain types of messages. Each type of a message prescribes a format for the
messageDatumfield. This value can be anything the developer wishes and can modify it to use custom payloads.
senderIdfield is the identifier of the user who sent this message. This is a mandatory field.
textPayloadis the text representation of the image that is sent.
messageDatafield contains custom data in a list of
MessageDatumobjects. This field is covered in detail in the upcoming sections.
timelineEventsfield contains events associated with this message. This field is covered un detal in the upcoming sections.
createdAt(creation time) and
updatedAt(last update time) timestamps. These cannot be overridden in
POSTcalls and will be ignored if sent.
payloadTypefield, however no such type name can start with
messageDatum. However, if the developer sets it, mitter.io will persist it and forward it on most delivery methods. Certain delivery mechanisms will ignore the message data field so it is recommend to not set this field.
deconstructed messages, which are messages heavily stripped from their JSON structure and aggresively compressed to reduce the overall byte size when delivering over messaging mechanisms like FCM. This mechanism will not support the
ImageMessageis handled much differently when sending messages, the
linkfield is not directly populated (if the image is to be stored and handled by mitter.io itself). Refer to the section Image and binary payloads later in this section.
datafield must contain a
linkwhich is the URI of the hosted image. This URI contains a placeholder
$reprwhich would be one of the specified representations.
deconstructedmessages for Formatted Messages as well.
mitter.mtet.SentTimeThe time at which the message was sent. This timestamp is populated with the timestamp on the client device.
mitter.mtet.ReceivedTimeThe time at which the message was received by the server. The
subjectof this timeline event is always
mitter.mtet.DeliveredTimeThe time at which the message was delivered to a user. The
subjectof this event is the receiving user.
mitter.mtet.ReadTimeThe time at which the message was read by a user. The
subjectof this event is the receiving user.
POSTrequest. By default a message can be sent to a channel by any participant with the same user as the sender. This behavior can be overriden by using ACLs.
.systemcan send a message to any channel on behalf of any user.
auditfields, they will be ignored.
Messageobject itself. This is important because certain messages (like Image Message) undergo processing and modify the message object as is available from mitter.io past this request succeeding. A response to this message would look like:
mitter.mtet.SentTimepresent in the Message body. The example above includes this case.
aftercan be set. The
limitcan be set to any positive value lesser than 25. To make the first request, make a
GETrequest without any of this parameters:
beforewas set, the messages are sorted such that newer messages appear last in the list. If
afterwas set, newer messages appear first in the list. When neither is provided,
beforesemantics are applied. Following the request above, you can fetch any messages before this using:
beforecall, you can stop making any further calls. This method will never return any new messages. For an
aftercall, this is the URI you keep on polling for newer messages till one arrives.
DELETEcall. By default all Users can delete Messages that they have sent. Any deletion of a Message does not delete any delivered entities from any recipients end-device.
.systemcan delete any Message for any User on any Channel.
application/json. This contains the message request body, i.e. a JSON of the image model that is sent.
nameof this part is ignored.
mitter.mtet.SentTimemust be set.
thumbnailrepresentation is used to display a thumbnail image, mostly in messge bubbles on a UI.
standardis a reduced-size, compressed image that can be used to display the enlarged format, probably when the user clicks on the displayed thumbnail.
baseis created which contains the image AS-IS, but the support for this is subject to revocation.
linkin the image message returns a
200 OKwith the image data in the payload. Once it is uploaded to the CDN, the service returns a
301 PERMANENTLY MOVEDwith the link from the CDN.