MSC3813: Obfuscated events

proposals/3813-obfuscated-events.md

@@ -0,0 +1,186 @@
+# MSC3813: Obfuscated events
+
+<!--*Note: Text written in italics represents notes about the section or proposal process. This document
+serves as an example of what a proposal could look like (in this case, a proposal to have a template)
+and should be used where possible.*
+
+*In this first section, be sure to cover your problem and a broad overview of the solution. Covering
+related details, such as the expected impact, can also be a good idea. The example in this document
+says that we're missing a template and that things are confusing and goes on to say the solution is
+a template. There's no major expected impact in this proposal, so it doesn't list one. If your proposal
+was more invasive (such as proposing a change to how servers discover each other) then that would be
+a good thing to list here.*
+
+*If you're having troubles coming up with a description, a good question to ask is "how
+does this proposal improve Matrix?" - the answer could reveal a small impact, and that is okay.*
+
+There can never be enough templates in the world, and MSCs shouldn't be any different. The level
+of detail expected of proposals can be unclear - this is what this example proposal (which doubles
+as a template itself) aims to resolve.-->
+
+Currently, event content can be end-to-end encrypted, but the metadata cannot. This means that if
+someone inspects the Matrix homeservers, they can see in what rooms one is most active, and at what
+time they are most active.
+
+We propose that clients send "dummy" events from time to time, at random intervals and times, in
+random rooms to obfuscate the user's online times and relationships. It is mainly intended to
+imitate the structure of two-sided conversations.
+
+## Proposal
+
+<!--*Here is where you'll reinforce your position from the introduction in more detail, as well as cover
+the technical points of your proposal. Including rationale for your proposed solution and detailing
+why parts are important helps reviewers understand the problem at hand. Not including enough detail
+can result in people guessing, leading to confusing arguments in the comments section. The example
+here covers why templates are important again, giving a stronger argument as to why we should have
+a template. Afterwards, it goes on to cover the specifics of what the template could look like.*
+
+Having a default template that everyone can use is important. Without a template, proposals would be
+all over the place and the minimum amount of detail may be left out. Introducing a template to the
+proposal process helps ensure that some amount of consistency is present across multiple proposals,
+even if each author decides to abandon the template.
+
+The default template should be a markdown document because the MSC process requires authors to write
+a proposal in markdown. Using other formats wouldn't make much sense because that would prevent authors
+from copy/pasting the template.
+
+The template should have the following sections:
+
+* **Introduction** - This should cover the primary problem and broad description of the solution.
+* **Proposal** - The gory details of the proposal.
+* **Potential issues** - This is where problems with the proposal would be listed, such as changes
+  that are not backwards compatible.
+* **Alternatives** - This section lists alternative solutions to the same
+  problem which have been considered and dismsissed.
+* **Security considerations** - Discussion of what steps were taken to avoid security issues in the
+  future and any potential risks in the proposal.
+
+Furthermore, the template should not be required to be followed. However it is strongly recommended to
+maintain some sense of consistency between proposals.-->
+### Introduction
+
+### Events
+
+We add the following types of events:
+
+#### `m.obfuscate.request`
+
+Initiates a request to send obfuscated events to the other party.
+
+Content attributes:
+
+| Name | Type | Comments |
+|------|------|----------|
+| version | string | Must be `v0`. |
+| min_interval | number | Minimum interval, in seconds, between two keepalive events. |
+| max_interval | number | Maximum interval, in seconds, between two keepalive events. |
+| retries | number | The number of retries that can be sent in keepalive events if the other party does not respond in a timely manner. |
+| payload | string | Can be arbitrary content. |
+
+The attributes `min_interval`, `max_interval` and `retries` indicates the parameters this party will stick to, not the parameters it expects the other party to stick to.
+
+#### `m.obfuscate.accept`
+
+Indicates that this party is willing to exchange obfuscated events with the other party.
+
+| Name | Type | Comments |
+|------|------|----------|
+| version | string | Must be `v0`. |
+| min_interval | number | Minimum interval, in seconds, between two keepalive events. |
+| max_interval | number | Maximum interval, in seconds, between two keepalive events. |
+| retries | number | The number of retries that can be sent in keepalive events if the other party does not respond in a timely manner. |
+| payload | string | Can be arbitrary content. |
+
+The attributes `min_interval`, `max_interval` and `retries` indicates the parameters this party will stick to, not the parameters it expects the other party to stick to.
+
+#### `m.obfuscate.reject`
+
+Indicates that this party is not willing to exchange obfuscated events with the other party, or wants to stop doing so.
+
+| Name | Type | Comments |
+|------|------|----------|
+| version | string | Must be `v0`. |
+| duration | number | Tells the other party how long, in seconds, they should not send a request again. -1 means they should never send requests again. 0 means they can send again immediately. |
+| payload | string | Can be arbitrary content. |
+
+#### `m.obfuscate.keepalive`
+
+The keepalive message that imitates the structure of a conversation.
+
+| Name | Type | Comments |
+|------|------|----------|
+| version | string | Must be `v0`. |
+| payload | string | Can be arbitrary content. |
+
+### Client behaviour
+
+Clients MUST negotiate to exchange obfuscated events before sending the keepalive messages.
+
+### Server behaviour
+
+
+## Potential issues
+
+*Not all proposals are perfect. Sometimes there's a known disadvantage to implementing the proposal,
+and they should be documented here. There should be some explanation for why the disadvantage is
+acceptable, however - just like in this example.*
+
+Someone is going to have to spend the time to figure out what the template should actually have in it.
+It could be a document with just a few headers or a supplementary document to the process explanation,
+however more detail should be included. A template that actually proposes something should be considered
+because it not only gives an opportunity to show what a basic proposal looks like, it also means that
+explanations for each section can be described. Spending the time to work out the content of the template
+is beneficial and not considered a significant problem because it will lead to a document that everyone
+can follow.
+
+
+## Alternatives
+
+*This is where alternative solutions could be listed. There's almost always another way to do things
+and this section gives you the opportunity to highlight why those ways are not as desirable. The
+argument made in this example is that all of the text provided by the template could be integrated
+into the proposals introduction, although with some risk of losing clarity.*
+
+Instead of adding a template to the repository, the assistance it provides could be integrated into
+the proposal process itself. There is an argument to be had that the proposal process should be as
+descriptive as possible, although having even more detail in the proposals introduction could lead to
+some confusion or lack of understanding. Not to mention if the document is too large then potential
+authors could be scared off as the process suddenly looks a lot more complicated than it is. For those
+reasons, this proposal does not consider integrating the template in the proposals introduction a good
+idea.
+
+
+## Security considerations
+
+<!--*Some proposals may have some security aspect to them that was addressed in the proposed solution. This
+section is a great place to outline some of the security-sensitive components of your proposal, such as
+why a particular approach was (or wasn't) taken. The example here is a bit of a stretch and unlikely to
+actually be worthwhile of including in a proposal, but it is generally a good idea to list these kinds
+of concerns where possible.*
+
+By having a template available, people would know what the desired detail for a proposal is. This is not
+considered a risk because it is important that people understand the proposal process from start to end.
+-->
+
+The events MUST be sent in end-to-end encrypted rooms.
+
+
+The payload SHOULD be randomly generated, and with random lengths. It SHOULD ideally be similar in length to other non-obfuscated
+events in the room.
+
+## Unstable prefix
+
+<!--*If a proposal is implemented before it is included in the spec, then implementers must ensure that the
+implementation is compatible with the final version that lands in the spec. This generally means that
+experimental implementations should use `/unstable` endpoints, and use vendor prefixes where necessary.
+For more information, see [MSC2324](https://github.com/matrix-org/matrix-doc/pull/2324). This section
+should be used to document things such as what endpoints and names are being used while the feature is
+in development, the name of the unstable feature flag to use to detect support for the feature, or what
+migration steps are needed to switch to newer versions of the proposal.*-->
+
+Please use `moe.kazv.mxc.msc.obfuscated-events` as the unstable prefix.
+
+## Dependencies
+
+No hard dependencies.
+