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 identifiables
is identified by a unique identifier, which can be overriden. The standard restrictions for an identifier apply as usual:[[email protected]#][[email protected]$#]*
messageId
contains the unique identifier of this message.messageType
holds 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 Standard
, OutOfBand
and Notification
. Currently, only Standard
and Notifcation
are supported.payloadType
defines 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 messageDatum
field. This value can be anything the developer wishes and can modify it to use custom payloads.senderId
field is the identifier of the user who sent this message. This is a mandatory field.textPayload
is the text representation of the image that is sent.messageData
field contains custom data in a list of MessageDatum
objects. This field is covered in detail in the upcoming sections.timelineEvents
field contains events associated with this message. This field is covered un detal in the upcoming sections.audit
field contains createdAt
(creation time) and updatedAt
(last update time) timestamps. These cannot be overridden in POST
calls and will be ignored if sent.mitter.mt.Text
mitter.mt.ImageMessage
mitter.mt.FileMessage
mitter.mt.EmptyMessage
mitter.mt.FormattedText
mitter.mt.LinkInsetText
payloadType
field, however no such type name can start with io.mitter.
or mitter.
.mitter.mt.Text
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.COMING SOON In the upcoming releases, we will be adding support fordeconstructed 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 themessageDatum
field.
mitter.mt.ImageMessage
ImageMessage
is handled much differently when sending messages, the link
field 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.text/uri-list
.data
field must contain a link
which is the URI of the hosted image. This URI contains a placeholder $repr
which would be one of the specified representations.mitter.mt.FileMessage
mitter.mtet.FormattedText
deconstructed
messages for Formatted Messages as well.mitter.mtet.SentTime
The time at which the message was sent. This timestamp is populated with the timestamp on the client device.mitter.mtet.ReceivedTime
The time at which the message was received by the server. The subject
of this timeline event is always .system
.mitter.mtet.DeliveredTime
The time at which the message was delivered to a user. The subject
of this event is the receiving user.mitter.mtet.ReadTime
The time at which the message was read by a user. The subject
of this event is the receiving user.io.mitter.
or mitter.
.POST
request. 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. .system
can send a message to any channel on behalf of any user.audit
fields, they will be ignored.Message
object 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.SentTime
present in the Message body. The example above includes this case.before
or after
can be set. The limit
can be set to any positive value lesser than 25. To make the first request, make a GET
request without any of this parameters:before
was set, the messages are sorted such that newer messages appear last in the list. If after
was set, newer messages appear first in the list. When neither is provided, before
semantics are applied. Following the request above, you can fetch any messages before this using:before
call, you can stop making any further calls. This method will never return any new messages. For an after
call, this is the URI you keep on polling for newer messages till one arrives.DELETE
call. 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. .system
can delete any Message for any User on any Channel.204
io.mitter.wire.requestbody
of type application/json
. This contains the message request body, i.e. a JSON of the image model that is sent.image/jpeg
, image/png
or image/gif
. The name
of this part is ignored.mitter.mtet.SentTime
must be set.standard
and thumbnail
.thumbnail
representation is used to display a thumbnail image, mostly in messge bubbles on a UI.standard
is a reduced-size, compressed image that can be used to display the enlarged format, probably when the user clicks on the displayed thumbnail.base
is created which contains the image AS-IS, but the support for this is subject to revocation.link
in the image message returns a 200 OK
with the image data in the payload. Once it is uploaded to the CDN, the service returns a 301 PERMANENTLY MOVED
with the link from the CDN.204
GET
callMessageTimelineEvent
objectsGET
call.