participantfor a given channel has special semantics in certain contexts, for example, by default only a
participantcan 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:
.broadcastChannel used for an application wide broadcast.
.controlChannel used for control messages to co-ordinate front-end clients.
channelIdcontains the unique identifier for the channel.
defaultRuleSetspecifies 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.
participationis a list of
ChannelParticipationobjects 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.
systemChanneldefines 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).
createdAt(creation time) and
updatedAt(last update time) timestamps. These cannot be overridden in
POSTcalls and will be ignored if sent.
.systemis 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).
Disabled. This status while mainly intended for application developers to build the logic on, mitter.io centrally uses it to establish the following semantics:
Activeparticipants are returned.
ReadOnlyparticipant 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.
POSTrequest. By default, any authenticated user can create a Channel. This behavior can be overriden using ACLs.
DELETEcall. By default only
.systemcan delete channels. In the future the defaults will be enforced by the ruleset. This behavior can also be modified using ACLs.
.systemcan add any user as a participant to any channel. This behavior can be modified using ACLs.
.systemcan remove any user.
/participants/is the user identifier of the participant that is to be removed. On successful execution, the service returns a
GETcall. By default any participant for a Channel can fetch the list of participants and
.systemcan do so for any Channel.
GETcall. By default any user can fetch their own participating Channels and
.systemcan do so for any User. This behavior can be modified by using ACLs.