Yet more bullet points on various sections.
parent
1bc05aef20
commit
ab0637c2c3
|
@ -287,7 +287,13 @@ Modifying aliases
|
||||||
|
|
||||||
Permissions
|
Permissions
|
||||||
-----------
|
-----------
|
||||||
- TODO : Room permissions / config / power levels. What they are. How do they work. Examples.
|
- TODO: What is a power level? How do they work? Defaults / required levels for X. How do they change
|
||||||
|
as people join and leave rooms? What do you do if you get a clash? Examples.
|
||||||
|
- TODO: List all actions which use power levels (sending msgs, inviting users, banning people, etc...)
|
||||||
|
- TODO: Room config - what is the event and what are the keys/values and explanations for them.
|
||||||
|
Link through to respective sections where necessary. How does this tie in with permissions, e.g.
|
||||||
|
give example of creating a read-only room.
|
||||||
|
|
||||||
|
|
||||||
Joining rooms
|
Joining rooms
|
||||||
-------------
|
-------------
|
||||||
|
@ -403,9 +409,11 @@ Banning users in a room
|
||||||
actually been banned."?
|
actually been banned."?
|
||||||
|
|
||||||
A user may decide to ban another user in a room. 'Banning' forces the target user
|
A user may decide to ban another user in a room. 'Banning' forces the target user
|
||||||
to leave the room and prevents them from re-joining the room. In order to ban
|
to leave the room and prevents them from re-joining the room. A banned user will
|
||||||
someone, the user performing the ban MUST have the required power level. To ban
|
not be treated as a joined user, and so will not be able to send or receive events
|
||||||
a user, a request should be made to ``/rooms/<room id>/ban`` with::
|
in the room. In order to ban someone, the user performing the ban MUST have the
|
||||||
|
required power level. To ban a user, a request should be made to
|
||||||
|
``/rooms/<room id>/ban`` with::
|
||||||
|
|
||||||
{
|
{
|
||||||
"user_id": "<user id to ban"
|
"user_id": "<user id to ban"
|
||||||
|
@ -540,14 +548,27 @@ There are several APIs provided to ``GET`` events for a room:
|
||||||
Example:
|
Example:
|
||||||
TODO
|
TODO
|
||||||
|
|
||||||
|
``/rooms/<room id>/messages``
|
||||||
|
Description:
|
||||||
- ``/rooms/<room id>/messages`` : Get all ``m.room.message`` events.
|
Get all ``m.room.message`` events.
|
||||||
- ``/rooms/<room id>/initialSync`` : Get all relevant events for a room.
|
Response format:
|
||||||
|
``{ TODO }``
|
||||||
|
Example:
|
||||||
|
TODO
|
||||||
|
|
||||||
|
``/rooms/<room id>/initialSync``
|
||||||
|
Description:
|
||||||
|
Get all relevant events for a room. This includes state events, paginated non-state
|
||||||
|
events and presence events.
|
||||||
|
Response format:
|
||||||
|
`` { TODO } ``
|
||||||
|
Example:
|
||||||
|
TODO
|
||||||
|
|
||||||
|
|
||||||
Room Events
|
Room Events
|
||||||
===========
|
===========
|
||||||
|
- voip events?
|
||||||
|
|
||||||
This specification outlines several standard event types, all of which are
|
This specification outlines several standard event types, all of which are
|
||||||
prefixed with ``m.``
|
prefixed with ``m.``
|
||||||
|
@ -654,8 +675,6 @@ prefixed with ``m.``
|
||||||
``read`` (sent when the event has been observed by the end-user). The ``target_event_id``
|
``read`` (sent when the event has been observed by the end-user). The ``target_event_id``
|
||||||
should reference the ``m.room.message`` event being acknowledged.
|
should reference the ``m.room.message`` event being acknowledged.
|
||||||
|
|
||||||
- voip?
|
|
||||||
|
|
||||||
m.room.message msgtypes
|
m.room.message msgtypes
|
||||||
-----------------------
|
-----------------------
|
||||||
Each ``m.room.message`` MUST have a ``msgtype`` key which identifies the type of
|
Each ``m.room.message`` MUST have a ``msgtype`` key which identifies the type of
|
||||||
|
@ -824,11 +843,23 @@ presence information in a user list for a room.
|
||||||
|
|
||||||
Typing notifications
|
Typing notifications
|
||||||
====================
|
====================
|
||||||
|
- what is the event type. Are they bundled with other event types? If so, which.
|
||||||
|
- what are the valid keys / values. What do they represent. Any gotchas?
|
||||||
|
- Timeouts. How do they work, who sets them and how do they expire. Does one
|
||||||
|
have priority over another? Give examples.
|
||||||
|
|
||||||
TODO : Leo
|
TODO : Leo
|
||||||
|
|
||||||
Voice over IP
|
Voice over IP
|
||||||
=============
|
=============
|
||||||
|
- what are the event types.
|
||||||
|
- what are the valid keys/values. What do they represent. Any gotchas?
|
||||||
|
- In what sequence should the events be sent?
|
||||||
|
- How do you accept / decline inbound calls? How do you make outbound calls?
|
||||||
|
Give examples.
|
||||||
|
- How does negotiation work? Give examples.
|
||||||
|
- How do you hang up?
|
||||||
|
- What does call log information look like e.g. duration of call?
|
||||||
|
|
||||||
TODO : Dave
|
TODO : Dave
|
||||||
|
|
||||||
|
@ -1321,7 +1352,10 @@ Content repository
|
||||||
|
|
||||||
Address book repository
|
Address book repository
|
||||||
=======================
|
=======================
|
||||||
- format
|
- format: POST(?) wodges of json, some possible processing, then return wodges of json on GET.
|
||||||
|
- processing may remove dupes, merge contacts, pepper with extra info (e.g. matrix-ability of
|
||||||
|
contacts), etc.
|
||||||
|
- Standard json format for contacts? Piggy back off vcards?
|
||||||
|
|
||||||
|
|
||||||
Glossary
|
Glossary
|
||||||
|
|
Loading…
Reference in New Issue