matrix-spec/specification/modules/instant_messaging.rst

Instant Messaging
=================

.. _module:im:

This module adds support for sending human-readable messages to a room. It also
adds human-readable information to the room itself such as a room name and topic.

Events
------

{{m_room_message_event}}

{{m_room_message_feedback_event}}

{{m_room_name_event}}

{{m_room_topic_event}}

m.room.message msgtypes
~~~~~~~~~~~~~~~~~~~~~~~

.. TODO-spec
   How a client should handle unknown message types.


Each `m.room.message`_ MUST have a ``msgtype`` key which identifies the type
of message being sent. Each type has their own required and optional keys, as
outlined below.

{{msgtype_events}}


Client behaviour
----------------

Server behaviour
----------------

Security considerations
-----------------------
Add instant_messaging module; modify batesian section rules Previously, all `m.room.*` events were wodged into `{{room_events}}` which isn't great when you want to pull specific ones out. Batesian had a 1:1 mapping of `render_foo()` to a section `{{foo}}`, and having to constantly add functions for new types is a PITA. Batesian now supports returning a `dict` instead of a section `string` where the keys are the `{{foo}}` and the value is what will be inserted. Also add conflicting section key checks to avoid multiple definitions of the same `{{foo}}`. Define dicts for event schemata and swagger HTTP APIs. Using this new feature, split out the instant messaging stuff from the events section, and replace `{{room_events}}` with a list of specific events e.g. `{{m_room_member_event}}`. 9 years ago			`Instant Messaging`
			`=================`

Flesh out feature profiles section Add table detailing the profiles. Add anchors to link through to each module following a well-defined format (rather than the name of the module section). Allow UTF-8 in the spec. 9 years ago			`.. _module:im:`

Stub sections 9 years ago			`This module adds support for sending human-readable messages to a room. It also`
			`adds human-readable information to the room itself such as a room name and topic.`

Add instant_messaging module; modify batesian section rules Previously, all `m.room.*` events were wodged into `{{room_events}}` which isn't great when you want to pull specific ones out. Batesian had a 1:1 mapping of `render_foo()` to a section `{{foo}}`, and having to constantly add functions for new types is a PITA. Batesian now supports returning a `dict` instead of a section `string` where the keys are the `{{foo}}` and the value is what will be inserted. Also add conflicting section key checks to avoid multiple definitions of the same `{{foo}}`. Define dicts for event schemata and swagger HTTP APIs. Using this new feature, split out the instant messaging stuff from the events section, and replace `{{room_events}}` with a list of specific events e.g. `{{m_room_member_event}}`. 9 years ago			`Events`
			`------`

			`{{m_room_message_event}}`

			`{{m_room_message_feedback_event}}`

			`{{m_room_name_event}}`

			`{{m_room_topic_event}}`

			`m.room.message msgtypes`
Stub sections 9 years ago			`~~~~~~~~~~~~~~~~~~~~~~~`
Add instant_messaging module; modify batesian section rules Previously, all `m.room.*` events were wodged into `{{room_events}}` which isn't great when you want to pull specific ones out. Batesian had a 1:1 mapping of `render_foo()` to a section `{{foo}}`, and having to constantly add functions for new types is a PITA. Batesian now supports returning a `dict` instead of a section `string` where the keys are the `{{foo}}` and the value is what will be inserted. Also add conflicting section key checks to avoid multiple definitions of the same `{{foo}}`. Define dicts for event schemata and swagger HTTP APIs. Using this new feature, split out the instant messaging stuff from the events section, and replace `{{room_events}}` with a list of specific events e.g. `{{m_room_member_event}}`. 9 years ago
			`.. TODO-spec`
			`How a client should handle unknown message types.`


			Each `m.room.message`_ MUST have a ``msgtype`` key which identifies the type
			`of message being sent. Each type has their own required and optional keys, as`
			`outlined below.`

			`{{msgtype_events}}`

Stub sections 9 years ago
			`Client behaviour`
			`----------------`

			`Server behaviour`
			`----------------`

			`Security considerations`
			`-----------------------`