From 62cc11eee658ead69eb18cad153193a4082daa1f Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Fri, 30 Aug 2019 13:49:54 +0100 Subject: [PATCH 1/7] add missing github-labels file --- README.rst | 2 +- meta/github-labels.rst | 91 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 92 insertions(+), 1 deletion(-) create mode 100644 meta/github-labels.rst diff --git a/README.rst b/README.rst index b8847bfb..ace8ebdd 100644 --- a/README.rst +++ b/README.rst @@ -138,4 +138,4 @@ Issue tracking Issues with the Matrix specification are tracked in `GitHub `_. -See `meta/labels.rst `_ for notes on what the labels mean. +See `meta/github-labels.rst `_ for notes on what the labels mean. diff --git a/meta/github-labels.rst b/meta/github-labels.rst new file mode 100644 index 00000000..f674b81b --- /dev/null +++ b/meta/github-labels.rst @@ -0,0 +1,91 @@ +The following labels are used to help categorize issues: + +`spec-omission `_ +-------------------------------------------------------------------------------- + +Things which have been implemented but not currently specified. These may range +from entire API endpoints, to particular options or return parameters. + +Issues with this label will have been implemented in `Synapse +`_. Normally there will be a design +document in Google Docs or similar which describes the feature. + +Examples: + +* `Spec PUT /directory/list `_ +* `Unspec'd server_name request param for /join/{roomIdOrAlias} + `_ + +`clarification `_ +-------------------------------------------------------------------------------- + +An area where the spec could do with being more explicit. + +Examples: + +* `Spec the implicit limit on /syncs + `_ + +* `Clarify the meaning of the currently_active flags in presence events + `_ + +`spec-bug `_ +---------------------------------------------------------------------- + +Something which is in the spec, but is wrong. + +Note: this is *not* for things that are badly designed or don't work well +(for which see 'improvement' or 'feature') - it is for places where the +spec doesn't match reality. + +Examples: + +* `swagger is wrong for directory PUT + `_ + +* `receipts section still refers to initialSync + `_ + +`improvement `_ +---------------------------------------------------------------------------- + +A suggestion for a relatively simple improvement to the protocol. + +Examples: + +* `We need a 'remove 3PID' API so that users can remove mappings + `_ +* `We should mandate that /publicRooms requires an access_token + `_ + +`feature `_ +-------------------------------------------------------------------- + +A suggestion for a significant extension to the matrix protocol which +needs considerable consideration before implementation. + +Examples: + +* `Peer-to-peer Matrix `_ +* `Specify a means for clients to "edit" previous messages + `_ + + +`wart `_ +-------------------------------------------------------------- + +A point where the protocol is inconsistent or inelegant, but which isn't really +causing anybody any problems right now. Might be nice to consider fixing one +day. + + +`question `_ +---------------------------------------------------------------------- + +A thought or idea about the protocol which we aren't really sure whether to +pursue or not. + +Examples: + +* `Should we prepend anti-eval code to our json responses? + `_ From 5acac5a44e0d4fb04010ed166069e96fc369c3e9 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Fri, 30 Aug 2019 09:12:02 -0600 Subject: [PATCH 2/7] Try bumping golang version --- .circleci/config.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.circleci/config.yml b/.circleci/config.yml index 659380b0..b37478bf 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -97,7 +97,7 @@ jobs: command: DOCS_URL="${CIRCLE_BUILD_URL}/artifacts/${CIRCLE_NODE_INDEX}/${CIRCLE_WORKING_DIRECTORY/#\~/$HOME}/api/client-server/index.html"; echo $DOCS_URL build-dev-scripts: docker: - - image: golang:1.8 + - image: golang:1.10 steps: - checkout - run: From 6d71a41e225f1f0cc227e3528c917f6042d4f148 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sat, 31 Aug 2019 16:01:04 +0100 Subject: [PATCH 3/7] Proposal for ignoring invites --- proposals/2270-ignore-invites.md | 47 ++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 proposals/2270-ignore-invites.md diff --git a/proposals/2270-ignore-invites.md b/proposals/2270-ignore-invites.md new file mode 100644 index 00000000..c6e51e70 --- /dev/null +++ b/proposals/2270-ignore-invites.md @@ -0,0 +1,47 @@ +# Proposal for ignoring invites + +## Problem + +There is currently no way to ignore an invite in Matrix without explicitly +rejecting it and informing the inviter of the rejection. There are many social +situations where a user may want to silently ignore the invite instead. + +The closest you can currently get is to ignore the user who sent the invite - +but this will then ignore all activity from that user, which may not be +desirable. + +## Solution + +Currently we support ignoring users by maintaining an `m.ignored_user_list` event in +account_data, as per https://matrix.org/docs/spec/client_server/r0.5.0#id189. + +We could do also silently ignore rooms (including invites) with an equivalent +`m.ignored_room_list` event, with precisely the same semantics but listing +room IDs rather than user IDs. + +## Tradeoffs + + * We're limited to ~65KB worth of room IDs (although we could change the + limits for account_data 'events', given they're more freeform JSON than + events) + * We waste initial sync bandwidth with account_data info for ignored rooms + which we may never care about ever again. + * The list will grow unbounded over time (unless the user occasionally + unignores and explicitly rejects the invites), especially if invite spam + accelerates. + * We could instead have a dedicated API for this: + * `PUT /user/{userId}/ignore/{txnId}` + * `PUT /rooms/{roomId}/ignore/{txnId}` + * `GET /user/{userId}/ignore` + * `GET /rooms/{roomId}/ignore` + * `GET /ignore` (for querying the current lists) + * ...and a custom block in `/sync` responses to synchronise ignore changes + * ...except it feels that yet another custom API & custom response block + is even more complicated and clunky than making account_data a bit more + flexible. + * Alternatively, we could extend `/leave` with a `silent` parameter of some kind, + and rely on the invitee's HS to track these 'silent' leaves and ignore the + room on behalf of the invitee. However, it may be nice to let the user track + ignored invites cross-client so they can undo if necessary, which account_data + gives us for free. Plus semantically it seems a bit wrong to use `/leave` + to describe the act of ignoring an invite, when you're not actually leaving it. \ No newline at end of file From a805d2b77961816f6f15ce0a44ee3dfde838fb37 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sat, 31 Aug 2019 16:04:55 +0100 Subject: [PATCH 4/7] oops, premature merge --- proposals/2270-ignore-invites.md | 47 -------------------------------- 1 file changed, 47 deletions(-) delete mode 100644 proposals/2270-ignore-invites.md diff --git a/proposals/2270-ignore-invites.md b/proposals/2270-ignore-invites.md deleted file mode 100644 index c6e51e70..00000000 --- a/proposals/2270-ignore-invites.md +++ /dev/null @@ -1,47 +0,0 @@ -# Proposal for ignoring invites - -## Problem - -There is currently no way to ignore an invite in Matrix without explicitly -rejecting it and informing the inviter of the rejection. There are many social -situations where a user may want to silently ignore the invite instead. - -The closest you can currently get is to ignore the user who sent the invite - -but this will then ignore all activity from that user, which may not be -desirable. - -## Solution - -Currently we support ignoring users by maintaining an `m.ignored_user_list` event in -account_data, as per https://matrix.org/docs/spec/client_server/r0.5.0#id189. - -We could do also silently ignore rooms (including invites) with an equivalent -`m.ignored_room_list` event, with precisely the same semantics but listing -room IDs rather than user IDs. - -## Tradeoffs - - * We're limited to ~65KB worth of room IDs (although we could change the - limits for account_data 'events', given they're more freeform JSON than - events) - * We waste initial sync bandwidth with account_data info for ignored rooms - which we may never care about ever again. - * The list will grow unbounded over time (unless the user occasionally - unignores and explicitly rejects the invites), especially if invite spam - accelerates. - * We could instead have a dedicated API for this: - * `PUT /user/{userId}/ignore/{txnId}` - * `PUT /rooms/{roomId}/ignore/{txnId}` - * `GET /user/{userId}/ignore` - * `GET /rooms/{roomId}/ignore` - * `GET /ignore` (for querying the current lists) - * ...and a custom block in `/sync` responses to synchronise ignore changes - * ...except it feels that yet another custom API & custom response block - is even more complicated and clunky than making account_data a bit more - flexible. - * Alternatively, we could extend `/leave` with a `silent` parameter of some kind, - and rely on the invitee's HS to track these 'silent' leaves and ignore the - room on behalf of the invitee. However, it may be nice to let the user track - ignored invites cross-client so they can undo if necessary, which account_data - gives us for free. Plus semantically it seems a bit wrong to use `/leave` - to describe the act of ignoring an invite, when you're not actually leaving it. \ No newline at end of file From 1f2acbcf29ecfe4495cf53a7d9f749e9ec0f37c3 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sat, 31 Aug 2019 16:45:53 +0100 Subject: [PATCH 5/7] RST is not MD --- specification/proposals_intro.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/proposals_intro.rst b/specification/proposals_intro.rst index 20cfd48d..de65ba27 100644 --- a/specification/proposals_intro.rst +++ b/specification/proposals_intro.rst @@ -79,7 +79,7 @@ their proposed changes to the Matrix protocol: * Pragmatism rather than perfection * Proof rather than conjecture -Please see [MSC1779](https://github.com/matrix-org/matrix-doc/blob/matthew/msc1779/proposals/1779-open-governance.md) +Please see `MSC1779 `_ for full details of the project's Guiding Principles. Technical notes From d346099cf70282c1db82ed7821b58c3e8a2bd915 Mon Sep 17 00:00:00 2001 From: Ben Parsons Date: Tue, 3 Sep 2019 18:30:05 +0100 Subject: [PATCH 6/7] deduplicate MSC1779 ref in proposals list --- specification/proposals_intro.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/proposals_intro.rst b/specification/proposals_intro.rst index de65ba27..06bd6dfd 100644 --- a/specification/proposals_intro.rst +++ b/specification/proposals_intro.rst @@ -79,7 +79,7 @@ their proposed changes to the Matrix protocol: * Pragmatism rather than perfection * Proof rather than conjecture -Please see `MSC1779 `_ +Please `see MSC1779 `_ for full details of the project's Guiding Principles. Technical notes From 2b8c8ad5126260ab7a3326f69a7fa881e62c4120 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 3 Sep 2019 13:49:25 -0600 Subject: [PATCH 7/7] MSC1779 is actually merged now --- specification/proposals_intro.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/proposals_intro.rst b/specification/proposals_intro.rst index 06bd6dfd..82a4225b 100644 --- a/specification/proposals_intro.rst +++ b/specification/proposals_intro.rst @@ -79,7 +79,7 @@ their proposed changes to the Matrix protocol: * Pragmatism rather than perfection * Proof rather than conjecture -Please `see MSC1779 `_ +Please `see MSC1779 `_ for full details of the project's Guiding Principles. Technical notes