Merge branch 'master' into module-voip

Conflicts:
	specification/modules/voip_events.rst

api/client-server/v1/sync.yaml

@@ -267,6 +267,12 @@ paths:
                       type: string
                       description: "The user's membership state in this room."
                       enum: ["invite", "join", "leave", "ban"]
+                    invite:
+                        type: object
+                        title: "InviteEvent"
+                        description: "The invite event if ``membership`` is ``invite``"
+                        allOf:
+                          - "$ref": "v1-event-schema/m.room.member"
                     messages:
                       type: object
                       title: PaginationChunk

event-schemas/schema/v1/m.room.member

@@ -32,6 +32,26 @@
         "type": {
             "type": "string",
             "enum": ["m.room.member"]
+        },
+        "invite_room_state": {
+            "type": "array",
+            "description": "A subset of the state of the room at the time of the invite, if ``membership`` is ``invite``",
+            "items": {
+                "type": "object",
+                "title": "StateEvent",
+                "description": "A stripped down state event, with only the ``type``, ``state_key`` and ``content`` keys.",
+                "properties": {
+                    "type": {
+                        "type": "string"
+                    },
+                    "state_key": {
+                        "type": "string"
+                    },
+                    "content": {
+                        "type": "object"
+                    }
+                }
+            }
         }
     }
 }

specification/0-feature_profiles.rst

@@ -1,3 +1,93 @@
 Feature Profiles
 ================
 
+.. sect:feature-profiles:
+
+Matrix supports many different kinds of clients: from embedded IoT devices to
+desktop clients. Not all clients can provide the same feature sets as other
+clients e.g. due to lack of physical hardware such as not having a screen.
+Clients can fall into one of several profiles and each profile contains a set
+of features that the client MUST support. This section details a set of
+"feature profiles". Clients are expected to implement a profile in its entirety
+in order for it to be classified as that profile.
+
+Summary
+-------
+
+===================================== ========== ========== ========== ========== ==========
+  Module / Profile                       Web       Mobile    Desktop       CLI     Embedded
+===================================== ========== ========== ========== ========== ==========
+ `Instant Messaging`_                  Required   Required   Required   Required   Optional
+ `Presence`_                           Required   Required   Required   Required   Optional
+ `Push Notifications`_                 Optional   Required   Optional   Optional   Optional
+ `Receipts`_                           Required   Required   Required   Required   Optional
+ `Typing Notifications`_               Required   Required   Required   Required   Optional
+ `VoIP`_                               Required   Required   Required   Optional   Optional
+ `Content Repository`_                 Required   Required   Required   Optional   Optional
+ `Managing History Visibility`_        Required   Required   Required   Required   Optional
+ `End-to-End Encryption`_              Optional   Optional   Optional   Optional   Optional
+===================================== ========== ========== ========== ========== ==========
+
+*Please see each module for more details on what clients need to implement.*
+
+.. _End-to-End Encryption: `module:e2e`_
+.. _Instant Messaging: `module:im`_
+.. _Presence: `module:presence`_
+.. _Push Notifications: `module:push`_
+.. _Receipts: `module:receipts`_
+.. _Typing Notifications: `module:typing`_
+.. _VoIP: `module:voip`_
+.. _Content Repository: `module:content`_
+.. _Managing History Visibility: `module:history-visibility`_
+
+Clients
+-------
+
+Stand-alone web (``Web``)
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This is a web page which heavily uses Matrix for communication. Single-page web
+apps would be classified as a stand-alone web client, as would multi-page web
+apps which use Matrix on nearly every page.
+
+Mobile (``Mobile``)
+~~~~~~~~~~~~~~~~~~~
+
+This is a Matrix client specifically designed for consumption on mobile devices.
+This is typically a mobile app but need not be so provided the feature set can
+be reached (e.g. if a mobile site could display push notifications it could be
+classified as a mobile client).
+
+Desktop (``Desktop``)
+~~~~~~~~~~~~~~~~~~~~~
+
+This is a native GUI application which can run in its own environment outside a
+browser.
+
+Command Line Interface (``CLI``)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This is a client which is used via a text-based terminal.
+
+Embedded (``Embedded``)
+~~~~~~~~~~~~~~~~~~~~~~~
+
+This is a client which is embedded into another application or an embedded
+device.
+
+Application
++++++++++++
+
+This is a Matrix client which is embedded in another website, e.g. using
+iframes. These embedded clients are typically for a single purpose
+related to the website in question, and are not intended to be fully-fledged
+communication apps.
+
+Device
+++++++
+
+This is a client which is typically running on an embedded device such as a
+kettle, fridge or car. These clients tend to perform a few operations and run
+in a resource constrained environment. Like embedded applications, they are
+not intended to be fully-fledged communication systems.
+

specification/modules/content_repo.rst

@@ -1,6 +1,8 @@
 Content repository
 ==================
 
+.. _module:content:
+
 HTTP API
 --------
 

specification/modules/end_to_end_encryption.rst

@@ -1,6 +1,8 @@
 End-to-End Encryption
 =====================
 
+.. _module:e2e:
+
 .. TODO-doc
   - Why is this needed.
   - Overview of process

specification/modules/history_visibility.rst

@@ -1,6 +1,8 @@
 Room History Visibility
 -----------------------
 
+.. _module:history-visibility:
+
 Whether a member of a room can see the events that happened in a room from
 before they joined the room is controlled by the ``history_visibility`` key
 of the ``m.room.history_visibility`` state event. The valid values for

specification/modules/instant_messaging.rst

@@ -1,6 +1,8 @@
 Instant Messaging
 =================
 
+.. _module:im:
+
 Events
 ------
 

specification/modules/presence.rst

@@ -1,5 +1,7 @@
 Presence
 ========
+
+.. _module:presence:
  
 Each user has the concept of presence information. This encodes the
 "availability" of that user, suitable for display on other user's clients.

specification/modules/push_overview.rst

@@ -1,6 +1,8 @@
 Push Notifications
 ==================
 
+.. _module:push:
+
 Overview
 --------
 

specification/modules/receipts.rst

@@ -1,6 +1,8 @@
 Receipts
 --------
 
+.. _module:receipts:
+
 Receipts are used to publish which events in a room the user or their devices
 have interacted with. For example, which events the user has read. For
 efficiency this is done as "up to" markers, i.e. marking a particular event

specification/modules/typing_notifications.rst

@@ -1,6 +1,8 @@
 Typing Notifications
 --------------------
 
+.. _module:typing:
+
 Client APIs
 ~~~~~~~~~~~
 

specification/modules/voip_events.rst

@@ -1,6 +1,8 @@
 Voice over IP
 =============
 
+.. _module:voip:
+
 This module outlines how two users in a room can set up a Voice over IP (VoIP)
 call to each other. Voice and video calls are built upon the WebRTC 1.0 standard.
 Call signalling is achieved by sending `message events`_ to the room. As a result,

specification/targets.yaml

@@ -2,11 +2,11 @@ targets:
   main:  # arbitrary name to identify this build target
     files:  # the sort order of files to cat
       - 0-intro.rst
-      - { 1: 0-feature_profiles.rst }
       - 1-client_server_api.rst
       - { 1: 0-events.rst }
       - { 1: 0-event_signing.rst }
       - 2-modules.rst
+      - { 1: 0-feature_profiles.rst }
       - { 1: "group:modules" }  # reference a group of files
       - 3-application_service_api.rst
       - 4-server_server_api.rst

templating/build.py

@@ -122,7 +122,7 @@ def main(input_module, file_stream=None, out_dir=None, verbose=False):
 
     # check the input files and substitute in sections where required
     log("Parsing input template: %s" % file_stream.name)
-    temp_str = file_stream.read()
+    temp_str = file_stream.read().decode("utf-8")
     # do sanity checking on the template to make sure they aren't reffing things
     # which will never be replaced with a section.
     ast = env.parse(temp_str)
@@ -140,7 +140,7 @@ def main(input_module, file_stream=None, out_dir=None, verbose=False):
     with open(
             os.path.join(out_dir, os.path.basename(file_stream.name)), "w"
             ) as f:
-        f.write(output)
+        f.write(output.encode("utf-8"))
     log("Output file for: %s" % file_stream.name)
     check_unaccessed("units", units)