Document a v2 api for setting tags on rooms #132
Conversation
| @@ -332,6 +337,16 @@ paths: | |||
| description: |- | |||
| Whether this room is visible to the ``/publicRooms`` API | |||
| or not." | |||
| private_user_data: | |||
|
This LGTM modulo comments above - thanks :) |
…ll as v2 sync. Only add the room_id for v1 /events since it is redundant in v1 /initialSync
…in the m.tag events
|
Final query here was whether to use m.roomtag or m.room.tag to avoid "m.tag" colliding horribly with message tag names etc in future. Unless we keep m.tag for rooms, and m.room.message.tag or something for message tags in future. |
| { | ||
| "type": "m.tag", | ||
| "content": { | ||
| "tags": { |
There was a problem hiding this comment.
shouldn't this be a list of tags? Or if it's a single tag, shouldn't the key be called "tag"? Any chance we can show an example of metadata for the tag - e.g. { order: 1 } rather than {}.
| name: access_token | ||
| in: query | ||
| paths: | ||
| "/user/{userId}/rooms/{roomId}/tags": |
There was a problem hiding this comment.
What's the rationale for forcing clients to know their own userId in the path? We can completely infer this from the token.
There was a problem hiding this comment.
To match the /user/user_id/filter APIs
Conflicts: api/client-server/v1/rooms.yaml specification/targets.yaml
|
in vector this is implemented with java style namespacing for the tag names - eg m.favourite. i still think we should name the tag events themselves m.room.tag rather than m.tag but implemented as the latter for now. |
|
How does vector handle tags it doesn't know about? |
Conflicts: api/client-server/v2_alpha/sync.yaml
| "account_data": { | ||
| "events": [ | ||
| { | ||
| "type": "m.tags", |
There was a problem hiding this comment.
I am tempted to use "m.tags" too but the chosen terminology is "m.tag", no?
There was a problem hiding this comment.
Fixed d39494b
Document a v2 api for setting tags on rooms
Todo: