Channels
A Channel acts as a delivery target for Messages. A Channel also associates certain users to it called participants
. A participant
for a given channel has special semantics in certain contexts, for example, by default only a participant
can send messages to a Channel (with ACLs this behavior can be overriden). Fetching a list of participants for a channel is also a common use-case for most of the applications. A channel is uniquely identified by an identifier and can be overriden by the creator of the channel. The standard restrictions for an identifier apply as usual:
The identifier can use alphanumeric characters.
The identifier can use from a set of symbols (- _ @ $ #)
The first character can only be alphanumeric, @ or #
The identifier must be between 8 and 72 characters
This is the regex: [a-zA-Z0-9@#][a-zA-Z0-9-_@$#]*
Reserved Channels
While these APIs and features are planned for a future release, certain channel ids are employed for specific purposes and are reserved:
.broadcast
Channel used for an application wide broadcast..control
Channel used for control messages to co-ordinate front-end clients.
The Channel Model
The model of a Channel looks as below:
A quick overview of the relevant fields:
The
channelId
contains the unique identifier for the channel.The
defaultRuleSet
specifies the default rule set that is applied to the Channel. A ruleset constraints the operations that can be performed on the Channel. Refer to the section on Rulesets in this page for more details.The
participation
is a list ofChannelParticipation
objects which contain the user identifier of the participant and the status of the participant. Refer to the Participation section in the page for more details.The
systemChannel
defines whether this is a system channel or not. While one can create system channels, this is ideally used for messages that are for communication between machine/software components and are not enlisted when fetching a list of channels (unless explicitly requested for).The
audit
field containscreatedAt
(creation time) andupdatedAt
(last update time) timestamps. These cannot be overridden inPOST
calls and will be ignored if sent.
Rulesets
A ruleset defines the constraints on a Channel in terms of messaging, participation etc. mitter.io frontend SDKs also use the ruleset identifier for directing behavior (or in some cases the default behavior) on these Channels. As of now, Channels can only select from a set list of rulesets and the ability to define and set custom rulesets is planned for the near future.
The rulesets provided out of the box are:
io.mitter.ruleset.chats.DirectMessage
io.mitter.ruleset.chats.GroupChat
io.mitter.ruleset.chats.SystemChannel
io.mitter.ruleset.chats.SingleParticipantChannel
Direct Message
TYPE io.mitter.ruleset.chats.DirectMessage
A direct message channel has the following constraints:
This channel must have exactly two distinct participants at any given point of time.
Participants cannot be added/removed/replaced at any point of time in this channel.
Only the involved participants can send messages to this channel.
Both the participants in this channel must be provided and set at the time of creation
This type of a channel is used to facilitate a communication between two people, as is the use-case of instant messaging applications.
Group Chat
TYPE io.mitter.ruleset.chats.GroupChat
A group chat has the following constraints/provisions:
It can have any number of participants, even zero.
Participants can be added/removed to it at any point of time.
All participants of this Channel can send Messages to this Channel.
This Channel can be deleted, at which point all participations are also revoked.
All participants of this channel can read a Message from this channel.
No User that is not a participant of this channel can send a message or read from this Channel.
System Channel
TYPE io.mitter.ruleset.chats.SystemChannel
This kind of a channel has the following constraints/provisions:
At the time of creation, exactly one participant must be provided.
The application-level user
.system
is automatically added to this channel.Neither of the two participants can be deleted/replaced.
The user (other than
.system
) may or may not have access to the messages from the channel (to use to send upstream-only messages).
This is used generally for control-type messages to be pushed to users from a central co-ordination system. Messages on this channel are not intended to be read by humans, i.e. they are not intended to be in a human readable format.
Single Participant Channel
TYPE io.mitter.ruleset.chats.SingleParticipantChannel
This channel has the following constraints/provisions:
At the time of creation exactly one user can be provided.
This user cannot be removed/replaced.
No new participants can be added to this channel.
This channel is also not intended to contain human readable messages. This channel is intended to be used by different endpoints (devices) used by the same user to co-ordinate information amongst each other.
Participation
A participation defines an association of a user with a channel. A participation also contains a status of the participation that may take upon one of the three values Active
, ReadOnly
and Disabled
. This status while mainly intended for application developers to build the logic on, mitter.io centrally uses it to establish the following semantics:
When fetching a list of participants, by default only
Active
participants are returned.Messages sent to a channel are delivered only to
Active
andReadOnly
participants.When using your own ACLs, a
Disabled
or aReadOnly
participant is essentially the same as any other participant, and it acts purely as a way to narrow down your ACL rules by participation classes. This is an effect of mitter not assigning any default ACLs when you are using your custom rules.
Participants to a channel can be added/removed after channel creation if the ruleset permits that operation.
Channel API Reference
The APIs around channels can be categorized as:
Operations on Channels
Operations on Channel participation
Operations on Channel
Creating a Channel
To create a channel, make a POST
request. By default, any authenticated user can create a Channel. This behavior can be overriden using ACLs.
Note that the audit field, if sent, will be ignored.
On successful creation, the server returns the identifier of the Channel.
Deleting a Channel
To delete a Channel, make a DELETE
call. By default only .system
can delete channels. In the future the defaults will be enforced by the ruleset. This behavior can also be modified using ACLs.
On successful deletion the server returns a 204
Get a Channel
To get a channel, make a GET
call.
The server returns the channel object.
Do note that the GET call DOES NOT populate the participants of a channel. It always returns an empty array.
Timeline events
Adding a timeline event to a channel
To add a timeline event to a channel, make a POST call
Unlike the timeline event operations for messages, timeline events on channels do not support adding timeline events to multiple channels in a single request. In the URI only one channel id can be specified.
On successful execution, the server returns a 204
Getting Timeline Events for a Channel
To get timeline events for a message, make a GET
call
This returns a list of ChannelTimelineEvent
objects
If you want to fetch events of only a certain type, a timeline event filter can be passed to the GET
call.
Timeline Events one set cannot be deleted even if custom types are used.
Participation APIs
Add a Participant to a Channel
To add a participant to a channel, make a POST call. By default, any authenticated user can add themselves to a channel and .system
can add any user as a participant to any channel. This behavior can be modified using ACLs.
On successful execution, the server returns a 204
Remove a Participant from a Channel
To remove a participant from a channel, make a DELETE call. By default, any authenticated User can remove themselves as a participant from a Channel and .system
can remove any user.
The parameter after /participants/
is the user identifier of the participant that is to be removed. On successful execution, the service returns a 204
Get all Participants for a Channel
To get all participants for a Channel, make a GET
call. By default any participant for a Channel can fetch the list of participants and .system
can do so for any Channel.
The server returns a list of ChannelParticipation
objects:
By default the server returns the entire object of participants. If you want the identifiers, you can set the expandParticipants
query paramater:
Get all Channels the User is a Participant in
To get all the Channels in which a user is a participant, make a GET
call. By default any user can fetch their own participating Channels and .system
can do so for any User. This behavior can be modified by using ACLs.
On successful execution, the server returns a list of ParticipatedChannel
objects.
Last updated