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:[[email protected]#][[email protected]$#]*
.broadcast
Channel used for an application wide broadcast..control
Channel used for control messages to co-ordinate front-end clients.channelId
contains the unique identifier for the channel.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.participation
is a list of ChannelParticipation
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.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).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.io.mitter.ruleset.chats.DirectMessage
io.mitter.ruleset.chats.GroupChat
io.mitter.ruleset.chats.SystemChannel
io.mitter.ruleset.chats.SingleParticipantChannel
io.mitter.ruleset.chats.DirectMessage
io.mitter.ruleset.chats.GroupChat
io.mitter.ruleset.chats.SystemChannel
.system
is automatically added to this channel..system
) may or may not have access to the messages from the channel (to use to send upstream-only messages).io.mitter.ruleset.chats.SingleParticipantChannel
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:Active
participants are returned.Active
and ReadOnly
participants.Disabled
or a ReadOnly
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.POST
request. By default, any authenticated user can create a Channel. This behavior can be overriden using ACLs.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.204
GET
call.204
GET
callChannelTimelineEvent
objectsGET
call..system
can add any user as a participant to any channel. This behavior can be modified using ACLs.204
.system
can remove any user./participants/
is the user identifier of the participant that is to be removed. On successful execution, the service returns a 204
GET
call. By default any participant for a Channel can fetch the list of participants and .system
can do so for any Channel.ChannelParticipation
objects:expandParticipants
query paramater: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.ParticipatedChannel
objects.