Matrix.org - Tech

Authentication changes on Matrix.org

2025-01-06T18:00:00+00:00

The Matrix.org homeserver will see changes related to authentication in Q1 2025. The team will turn off guest account access on Matrix.org on January 16th and roll out Matrix Authentication Service (MAS) to embrace Matrix 2.0 after February 10. Client developers need to ensure their clients support the required changes.

🔗</a>What is MAS</h2>
Matrix Authentication Service is Matrix's next-generation authentication stack. It allows for more flexible authentication journeys without requiring client developers to support every one of them.
You can find all the technical details in Quentin's Matrix Conf talk, Harder Better Faster Stronger Authentication with OpenID Connect</a>.

🔗</a>What's the impact</h2>
Client developers need to ensure that their projects support the requirements listed on areweoidcyet.com</a> and, more precisely, the requirements listed in MSC3824</a>.
Developers can already use beta.matrix.org to see if their clients are compatible with MAS. If you notice anything that doesn't work as intended, make sure to give your feedback on those MSCs</a>. If clients work on beta.matrix.org, they will be able to connect to matrix.org after the rollout.
Homeserver administrators from the public federation don't have to worry about this deployment. MAS only affects the APIs between the clients and the server, so this deployment only impacts clients connecting to matrix.org. Federation APIs, used for servers to talk to each other, remain unchanged.

🔗</a>Disabling guest accounts</h2>
Guest accounts are a legacy Matrix feature that allows clients to create temporary, limited technical accounts to participate in specific rooms that allow it.
The Matrix.org Foundation would have liked to find an efficient way to let people create guest accounts when joining a conversation and then turn them into fully fledged accounts later. Nobody in the ecosystem found resources to design and implement such a user journey, and guest accounts ended up being used for technical reasons, like displaying room previews or badges via shields.io.
Those accounts make up a significant load on the matrix.org homeserver. For that reason, the Matrix.org Foundation has decided to disable them at least temporarily to save precious resources and go ahead with the rollout of the new authentication stack.
The Matrix.org Foundation is open to re-enabling guests accounts once it has the financial capacity to support them. If guest accounts on matrix.org are important to you and your business, please join the Matrix.org Foundation as a supporting member</a> to contribute to its financial sustainability.
We encourage developers using guest access for room information, such as topics, aliases, or member counts, to utilize the endpoint proposed by MSC3266</a>. This endpoint is publicly accessible without authentication and can serve as an alternative resource until guest access is reinstated in a more robust form.
We appreciate your understanding as we take these steps to enhance the user experience on Matrix.org.

Sunsetting the Sliding Sync Proxy: Moving to Native Support

2024-11-14T16:00:00+00:00

We will be decommissioning the sliding sync proxy</a> next week (21/11/2024) and Element are removing client support in mid-January (17/01/2025).
Sliding Sync is designed to provide a significantly faster and more scalable sync experience in our clients. The initial implementation was first prototyped in Element Web backed by an entirely experimental server proxy. The implementation had half an eye on low bandwidth use cases, and the prototype led to MSC3575</a>. We then realised that a simpler approach would be beneficial, and reused the same (experimental) proxy concept to facilitate beta testing with Element X, this time making it available on matrix.org. In doing so, we learned valuable lessons, leading to a refined and simplified API design in MSC4186</a>. The proxy itself was only ever considered as a temporary arrangement to aid speed of development, rather than being a long term solution.
Simplified Sliding Sync MSC4186</a> (also known as native sliding sync), has since been implemented in Synapse, with encouraging results. Now that we don’t expect the API shape to change significantly, we recommend homeserver developers to implement MSC4186 natively.
The Matrix.org Foundation does not have the resources to keep up maintenance of the proxy service or its codebase, and plans to decommission the proxy from Mid-November and archive the sliding-sync repo.
Recognising that the community needs time to adopt sliding sync natively, Element will keep client support for the old API (MSC3575) until the 17th of January, 2025. 
🔗</a>The Timeline</h2>

Now: EX Apps support migrating from the proxy server to native Sliding Sync. The apps automatically detect when the homeserver supports native Sliding Sync and offers the option to migrate. If users choose to migrate, they will be prompted to log in again. This migration is optional, as the apps continue to support both native Sliding Sync and the proxy.</li>
November 21st: Service decommissioning. We plan to decommission the proxy service on Matrix.org and archive its codebase.</li>
January 17th: Element X stops supporting MSC3575. EX apps (and matrix-rust-sdk) will remove proxy support, fully shifting to native SS. The migration on EX apps will be forced. Users will get logged out so that they can log in again using native Sliding Sync. We encourage server developers to implement Sliding Sync natively by this point.</li> </ol> 🔗</a>What This Means for Users</h2>
To continue enjoying the speed of Sliding Sync your homeserver and client must support the native Sliding Sync implementation (MSC4186).
At the time of writing, the latest versions of Synapse support native Sliding Sync, as do the Element X clients. There may be other server / client implementations that also have or are in the process of adding support. If you do use Element X apps, native Sliding Sync is used for every new login. For those currently using Element X through the proxy service, the app will prompt you to log out to switch to native Sliding Sync. While this migration is optional for now, it will become mandatory on the 21st of November for those on Matrix.org, when the proxy will be decommissioned. Element X will discontinue support for the previous Sliding Sync implementation (MSC3575) entirely by January 17th.
🔗</a>Guidance for Server & Client Developers</h2>
Server & Client developers are encouraged to implement MSC4186 for native sliding sync. Server developers should be aware that by the 17th of January Element clients will drop support for MSC3575, marking a transition to the native system.
We appreciate your understanding as we take this step forward for the Matrix ecosystem.

Type coverage for Sydent: evaluation

2021-12-17T00:00:00+00:00

This is the third in a series of three posts which discuss recent work to improve type annotations in Sydent</a>, the reference Matrix Identity server. Last time</a> we discussed the mechanics of how we added type coverage. Now I want to reflect on how well we did. What information and guarantees did we gain from mypy</code>? How could we track our progress and measure the effect of our work? And lastly, what other tools are out there apart from mypy</code>?
🔗</a>The best parts of --strict</code></h2> While the primary goal was to improve Sydent's coverage and robustness, to some extent this was an experiment too. How much could we get out of typing and static analysis, if we really invested in thorough annotations? Sydent is a small project that would make for a good testbed! I decided my goal would be to get Sydent passing mypy under --strict mode</a>. This is a command line option which turns on a number of extra checks (though not everything); it feels similar to passing -Wall -Wextra -Werror</code> to gcc</code>. It's a little extreme, but Sydent is a small project and this would be a good chance to see how hard it would be. In my view, the most useful options implied by strict mode were as follows. 🔗</a>--check-untyped-defs</a></h3> By default, mypy will only analyze the implementation of functions that are annotated. On the one hand, without annotations for inputs and the return type, it's going to be hard for mypy to thoroughly check the soundness of your function. On the other, it can still do good work with the type information it has from other sources. Mypy can infer the type of literals, e.g. deducing x: str</code> from x = "hello"</code>;</li> lookup the return types of standard library calls, via typeshed</code>; and similarly</li> lookup the return types of any annotated functions in your code or dependencies.</li> </ul> The information is already available for free: we may as well try to use it to spot problems. 🔗</a>--disallow-untyped-defs</a> and friends</a></h3> This flag forces you to fully annotate every function. There are less extreme versions available, e.g. --disallow-incomplete-defs</code>; but I think this is a good option to ensure full coverage of your module. It means you can rely on mypy's error output as a to-do list. One downside to this: sometimes I felt like I was writing obvious boilerplate annotations, e.g. def __str__(self) -> str: ... </code></pre> There was one particular example of this that crops up a lot. Mypy has a special exception for a class's __init__</code> and __init_subclass__</code> methods. If a return type annotation is missing, it will assume these functions return None</a> instead of Any</code>. (See here for its implementation</a>.) This is normally compatible with --disallow-untyped-defs</code> and --disallow-incomplete-defs</code>, with one exception. If your __init__</code> function takes no arguments other than self</code>, mypy won't consider it annotated, and you'll need to write -> None</code> explicitly. It's also worth mentioning --disallow-untyped-calls</a>, which will cause an error if an annotated function calls an unannotated function. Again, it helps to ensure that mypy has a complete picture of the types in your function's implementation. It also helps to highlight dependencies—if you see errors from this, it might be more practical to annotate the functions and modules it's calling first. 🔗</a>--warn-return-any</a></h3> If I've written a function and annotated it to return an int</code>, mypy will rightly complain if its implementation actually goes on to return a str</code>. def foo() -> int: # error: Incompatible return value type (got "str", expected "int") return "hello" </code></pre> If mypy isn't sure what type I'm returning though, i.e. if I'm returning an expression of type Any</code>, then by default mypy will trust that we've done the right thing. def i_promise_this_is_an_int(): return "hello" def bar() -> int: reveal_type(i_promise_this_is_an_int()) # Any return i_promise_this_is_an_int() </code></pre> Enabling --warn-return-any</code> will disable this behaviour; to make this error pass we'll have to prove to mypy that i_promise_this_is_an_int()</code> really is an int</code>. Sometimes that will be the case, and an extra annotation will provide the necessary proof. At other times (like in this example), investigation will prove that there really is a bug! 🔗</a>--strict-equality</a></h3> This is a bit like a limited form of gcc's -Wtautological-compare</a>. Mypy will report and reject equality tests between incompatible types. If mypy can spot that an equality is always False</code>, there's a good chance of there being a bug in your program, or else an incorrect annotation. I'm not sure how general this check is, since users can define their own types with their own rules for equality by overriding eq</a>. Perhaps it only applies to built-in types? 🔗</a>Quantifying coverage</h2> It was important to have some way to numerically evaluate our efforts to improve type coverage. It's a fairly abstract piece of work: there's nothing user-visible about it, unless we happen to discover a bug and fix it. The most obvious metric is the number of total errors reported by mypy. Before the recent sprint, we had roughly 600 errors total. dmr on titan in sydent on  HEAD (3dde3ad) via 🐍 v3.9.7 (env) 2021-11-08 12:35:37 ✔ $ mypy --strict sydent Found 635 errors in 59 files (checked 78 source files) </code></pre> This is a decent way to measure your progress when working on a particular module or package, but it's not perfect, because the errors aren't independent. Fixing one could fix another ten or reveal another twenty—the numeric value can be erratic. 🔗</a>Reports</h3> I found mypy's various reports</a> to be a better approach here. There were three reports I found particularly useful. 🔗</a>--html-report</code></h4> This produces a main index page showing the "imprecision" of each module. At the bottom of the table is a total imprecision value across the entire project. The precision for each module is broken down line-by-line and colour-coded accordingly, which is useful for getting an intuition for what makes a line imprecise. More on that shortly. 🔗</a>--txt-report</code></h4> This reproduces the index page from the html</code> report as a plain text file. It's slightly easier to parse—that's how I got the data for the precision line graphs in part one</a> of this series. That was a quick and dirty hack, though; a proper analysis of precision probably ought to read from the json or xml output formats. Here's a truncated sample: +-----------------------------------+-------------------+----------+ | Module | Imprecision | Lines | +-----------------------------------+-------------------+----------+ | sydent | 0.00% imprecise | 1 LOC | | sydent.config | 0.00% imprecise | 266 LOC | | sydent.config._base | 0.00% imprecise | 31 LOC | | sydent.config.crypto | 15.94% imprecise | 69 LOC | | ... | ... | ... | | sydent.validators | 0.00% imprecise | 61 LOC | | sydent.validators.common | 7.35% imprecise | 68 LOC | | sydent.validators.emailvalidator | 1.30% imprecise | 154 LOC | | sydent.validators.msisdnvalidator | 1.34% imprecise | 149 LOC | +-----------------------------------+-------------------+----------+ | Total | 5.95% imprecise | 9707 LOC | +-----------------------------------+-------------------+----------+ </code></pre> 🔗</a>--any-exprs-report</code></h4> Selecting this option generate two reports: any-exprs.txt</code> and types-of-anys.txt</code>. The latter is interesting to understand where the Anys</code> come from, but the former is more useful for quantifying the progress of typing. Another sample: Name Anys Exprs Coverage ------------------------------------------------- sydent 0 2 100.00% sydent.config 0 185 100.00% sydent.config._base 0 3 100.00% sydent.config.crypto 34 80 57.50% sydent.config.database 0 8 100.00% sydent.config.email 0 86 100.00% ... ... ... ... ------------------------------------------------- Total 544 11366 95.21% </code></pre> The breakdown in types-of-anys.txt</code> has more gory detail. I found the "Unimported" column particularly interesting: it lets us see how exposed we are to a lack of typing in our dependencies. Name Unannotated Explicit Unimported Omitted Generics Error Special Form Implementation Artifact ------------------------------------------------------------------------------------------------------------------------------------------- sydent 0 0 0 0 0 0 0 sydent.config 0 3 0 0 0 0 0 sydent.config._base 0 0 0 0 0 0 0 ... ... ... ... ... ... ... ... sydent.util.versionstring 0 80 0 0 0 0 0 sydent.validators 0 4 0 0 0 0 0 sydent.validators.common 0 20 0 0 0 0 0 sydent.validators.emailvalidator 0 8 0 0 0 0 0 sydent.validators.msisdnvalidator 0 8 0 0 0 0 0 ------------------------------------------------------------------------------------------------------------------------------------------- Total 9 1276 273 0 37 0 17 </code></pre> 🔗</a>The meaning of precision</h3> There are two metrics I chose to focus on: the proportion of "imprecise" lines across the project; I also used the complement, precision = 100% - imprecision</code>, and</li> the proportion of expressions whose type is not Any</code>.</li> </ul> These are plotted in the graph at the top of this writeup. I could see that precision and the proportion of typed expressions were correlated, but I didn't understand how they differed. I couldn't see an explanation in the mypy docs, so I went digging</a> into the mypy source code. My understanding is as follows. There are five kinds of precision</a>. Full details are visible in the --lineprecision-report</code>.</li> Two kinds of precision, EMPTY</code> and UNANALYZED</code> convey no information, because there's nothing to analyze.</li> A line is marked as precise, imprecise or any based on the expressions it uses. An expression that has type Any</code> leads to precision ANY</code>.</li> I think an expression that involves Any</code> but is not Any</code></a> counts as imprecise. For instance, Dict[str, Any]</code>.</li> Remaining expressions have precision PRECISE</code>.</li> </ul> </li> A line's precision is the worst of all its expressions' precisions. ANY</code> is worse than IMPRECISE</code>, which is worse than PRECISE</code>.</li> </ul> </li> </ol> The "imprecision" number reported by mypy counts the number of lines classified as IMPRECISE</code> or ANY</code></a>. On balance, my preferred metric is the line-level (im)precision percentage. There wasn't much difference between the two in my experience, but the colour-coded visualisation in the HTML report is a neat feature to have. Maybe in the future there could be a version of the HTML report that colour-codes each expression? 🔗</a>The larger typing ecosystem</h2> There are plenty of articles out there about the typing. As well as the mypy blog itself</a>, see Daniele Varrazzo's post on psycopg3</code> (2020)</a>, Dropbox's blog post (2019)</a>, Zulip's blog post (2016)</a>, Glyph's blog post on Protocols</code> (2020)</a> and a follow-up comparing them to zope.interface</code> (2021)</a> and Nylas's blog (2019)</a>. I'm sure there's plenty more out there. It's worth highlighting the typeshed</code> project, which maintains stubs for the standard library, plus popular third-party libraries. I submitted a PR</a> to add a single type hint—it was a very pleasant experience! Microsoft has an incubator</a> of sorts for stubs too. 🔗</a>Other typecheckers</h3> After the sprint to improve coverage, I spent a short amount of time trying the alternative type checkers out there. Mypy isn't the only typechecker out there—other companies have built and open-sourced their own tools, with different strengths, weaknesses and goals. This is by no means an authoritative, exhaustive survey—just my quick notes. 🔗</a>Pyre</a> (Facebook)</h4> I couldn't work out how to configure paths to resolve import errors; in the end, I wasn't able to process much of Sydent's source code.</li> Couldn't get it to process annotations like syd: "Sydent"</code> where "Sydent" is an import guarded by TYPE_CHECKING</a>.</li> No plugin system that I could see. That said, it has a separate mode/program for running "Taint Analysis"</a> to spot security issues.</li> Seemed stricter by default compared to mypy: there was less inference of types.</li> Also has its own strict mode.</li> </ul> 🔗</a>Pyright</a> (Microsoft)</h4> Didn't seem to recognise getLogger</code> as being imported from logging</code>. Not sure what happened there—maybe something wrong with its bundled version of typeshed</code>? </li> In a few places, Sydent uses urllib.parse.quote</code> but only imports urllib</code>. We must be unintentionally relying on our dependencies to import urllib.parse</code> somewhere! Mypy didn't complain about this; pyright did. </li> Seemed to give a better explanations of why complex types were incompatible. For example: /home/dmr/workspace/sydent/sydent/replication/pusher.py /home/dmr/workspace/sydent/sydent/replication/pusher.py:77:16 - error: Expression of type "DeferredList" cannot be assigned to return type "Deferred[List[Tuple[bool, None]]]" TypeVar "_DeferredResultT@Deferred" is contravariant TypeVar "_T@list" is invariant Tuple entry 2 is incorrect type Type "None" cannot be assigned to type "_DeferredResultT@_DeferredListResultItemT" (reportGeneralTypeIssues) /home/dmr/workspace/sydent/sydent/sms/openmarket.py /home/dmr/workspace/sydent/sydent/sms/openmarket.py:93:13 - error: Argument of type "dict[_KT@dict, list[bytes]]" cannot be assigned to parameter "rawHeaders" of type "Mapping[AnyStr@__init__, Sequence[AnyStr@__init__]] | None" in function "__init__" Type "dict[_KT@dict, list[bytes]]" cannot be assigned to type "Mapping[AnyStr@__init__, Sequence[AnyStr@__init__]] | None" TypeVar "_KT@Mapping" is invariant Type "_KT@dict" is incompatible with constrained type variable "AnyStr" Type cannot be assigned to type "None" (reportGeneralTypeIssues) </code></pre> This would have been really helpful when interpreting mypy's error reports; I'd love to see something like it in mypy. Here's another example where I tried running against a Synapse file. /home/dmr/workspace/synapse/synapse/storage/databases/main/cache.py /home/dmr/workspace/synapse/synapse/storage/databases/main/cache.py:103:53 - error: Expression of type "list[tuple[Unknown, Tuple[Unknown, ...]]]" cannot be assigned to declared type "List[Tuple[int, _CacheData]]" TypeVar "_T@list" is invariant Tuple entry 2 is incorrect type Tuple size mismatch; expected 3 but received indeterminate number (reportGeneralTypeIssues) </code></pre> This is really valuable information. It's worth considering Pyright as an option to get a second opinion! </li> It looks like Pyright's name for Any</code> is Unknown</code>. I think that does a better job of emphasising that Unknown</code> won't be type checked. I'd certainly be more reluctant to type x: Unknown</code> versus x: Any</code>! </li> Pyright is the machinery behind Pylance</a>, which drives VS Code's Python extension</a>. That alone probably makes it worthy of more eyes. </li> Seemed like it was the best-placed alternative typechecker to challenge mypy (the de-facto standard). </li> </ul> 🔗</a>Pytype</a> (Google)</h4> Google internal? Seems to be maintained by one person semiregularly by "syncing" from Google.</li> Apparently contains a script merge-pyi</a> to annotate a source file given a stub file.</li> No support for TypedDict: as soon as it saw one in Sydent, it stopped all analysis.</li> No Python 3.10 support (according to the README anyway).</li> I think it might use a different kind of typing semantics; its typing FAQ</a> speaks of "descriptive typing" and a more lenient approach.</li> </ul> 🔗</a>PyCharm</a></h4> PyCharm has its own means to typechecking code as you write it. It's definitely caught bugs before, and having the instant feedback as you type is really nice! I have seen it struggle with zope.interface</code> and some uses of Generic</code>s though. 🔗</a>Runtime uses of annotations</h3> When annotations were first introduced</a>, they were a generic means to associate Python objects with parts of a program. (It was only later that the community agreed that we really want to use them to annotate types). These annotations are available at runtime in the __annotations__</code> attribute. There's also a helper function in typing</code> which will help resolve forward references. >>> from typing import get_type_hints >>> def foo(x: int) -> str: pass ... >>> get_type_hints(foo) {'x': <class 'int'>, 'return': <class 'str'>} </code></pre> Programs and libraries are free to use these annotations at runtime as they see fit. The most well-known examples are probably dataclasses</a>, attrs</a> with auto_attribs=True</a> and Pydantic</a>. I'd be interested to learn if anyone else is consuming annotations at runtime! 🔗</a>Summary</h2> All in all, in a two-week sprint we were able to get Sydent's mypy coverage from a precision of 83% up to 94%. Our work would have spotted the bytes-versus-strings bug</a>; we understand why the missing await</a> wasn't detected. We fixed</a> other</a> small</a> bugs</a> too as part of the process. As well as fix bugs, I've hopefully made the source code clearer for future readers (but that one is hard to quantify). There's room to spin out contributions upstream too. I submitted two</a> PRs</a> to twisted upstream; have started to work on annotations for pynacl</a> in my</a> spare time</a>; and submitted a quick fix to typeshed</a>. Looking forward, I think we'd get a quick gain from ensuring that our smaller libraries (signedjson</a>, canonicaljson</a>) are annotated. We'll be sticking with mypy for now—the mypy-zope</code> plugin is crucial given our reliance on twisted. We're also working to improve Sygnal and Synapse—though not to the extreme standard of --strict</code> across everything. I'd say the biggest outstanding hole is our processing of JSON objects. There's too much Dict[str, Any]</code> flying around. The ideal for me would be to define dataclass</code> or attr.s</code> class C</code>, and be able to deserialise a JSON object to C</code>, including automatic (deep) type checking. Pydantic</a> sounds really close to what we want, but I'm told it will by default gladly interpret the json string "42"</code> as the Python integer 42</code>, which isn't what we'd like. More investigation needed there. There are other avenues to explore too, like jsonschema-typed</a>, typedload</a> or attrs-strict</a>. To end, I'd like to add a few personal thoughts. Having types available in the source code is definitely A Good Thing. But there is a part of me that wonders if it might have been worth writing our projects in a language which incorporates types from day one. There are always trade-offs, of course: runtime performance, build times, iteration speed, ease of onboarding new contributors, ease of deployment, availability of libraries, ability to shoot yourself in the foot... the list goes on. On a more upbeat note, adding typing is a great way to get familiar with new source code. It involves a mixture of reading, cross-referencing, deduction, analysis, all across a wide variety of files. It'd be a lot easier to type as you write from the get-go, but typing after the fact is still a worthy use of time and effort. Many thanks for reading! If you've got any corrections, comments or queries, I'm available on Matrix at @dmrobertson:matrix.org</a>.
Type coverage for Sydent: annotation 2021-12-10T00:00:00+00:00 This is the second in a series of three posts which discuss recent work to improve type annotations in Sydent</a>, the reference Matrix Identity server. Last time</a> we discussed the motivation for doing this work in the first place: the why. Now I want to talk about the how. How did we add annotations to individual files, and across the project as whole? What common idioms did we learn on the way? 🔗</a>The process of improving coverage</h2> From experience adding typing to Synapse, we decided to annotate one module at a time. We configured a list of files in pyproject.toml</code> which we knew passed mypy's checks. We could run mypy</code> in CI to check that new PRs didn't introduce type problems in modules already covered. From there, the workflow was Choose a new module to annotate. Add it to the list of files</code> in mypy's configuration.</li> Run mypy</code>. See how many errors you get.</li> Choose an error. Fix it. Re-run mypy</code>.</li> Repeat until no errors remaining.</li> Submit for review.</li> </ol> There are two parts in there which involve a choice. Being honest, I made those choices unscientifically: I tried to choose the easy tasks to do first. My first target was actually the entire sydent.util</a> subpackage. Probably a bit too large for a first bite! My thinking was that util</code> sounded like something with few dependencies that would have impact across the whole source tree. Within a given module, I'd try to fix easier errors first: partly for confidence, partly to build up momentum, and partly to get myself familiar with that piece of source code. For example, I'd often start by telling mypy that mylist = []</code> was actually was a List[str]</code> (rather than the generic List[Any]</code> which it would use otherwise). Picking and choosing easy targets works fairly well, but sometimes that means you end up fixing an error that's really a symptom of an earlier one. Other times fixing one error, e.g. by giving a return type annotation to a function—would solve a series of other errors throughout the file. Watching the total number of errors mypy reports bob up and down was intriguing! In retrospect, I think it would be smoother to generate some kind of dependency graph for the package. I'm imagining a DAG</a> where whose vertices are modules, and there's an edge A -> B</code> if A</code> imports from B</code>. The sinks of this DAG (i.e. modules which don't depend on any others in the package) are the ideal place to start: you can get something strictly typechecked there without having to annotate a long chain of dependencies across other files. Another strategy would be to see which modules were the least precise according to mypy's reports—but more on those next time</a>. 🔗</a>You're at the mercy of your dependencies</h3> I think this is my single biggest takeaway from the process of adding annotations to Sydent. I'll admit the phrasing is melodramatic, but I think it rings true. Improving coverage boils down to giving the typechecker more information about your program. The more information it has, the more it can check—and the more errors it can spot. (Hopefully this doesn't make typing come across like a pyramid scheme.) If your dependencies aren't typed, mypy can't validate you're correctly providing inputs and correctly consuming outputs. You might have a bigger impact on overall typing coverage by annotating a dependency (directly or via stubs). I have a hunch that bugs are more likely in code that uses an external dependency: we're much more familiar with the details of our own source code compared to that of a third party we trust. It's worth looking to see if your dependencies have a newer version including type annotations. Failing that, they may have a stub package added to typeshed</a> and published on PyPI. I saw example of both cases when choosing how to configure mypy for Sydent. If some of your dependencies are under your control, consider annotating them—you'll feel the benefits across multiple projects pretty quickly. 🔗</a>Annotations when working with twisted</h3> Twisted is Sydent's biggest dependency, and I certainly felt at its mercy! In particular, it has a few quirks which make it trickier to annotate applications using it. Here's a summary of the work we had to do to get those annotations working. 🔗</a>Partially typed modules and stubs</h4> Early into the process, mypy reported that calling the function twisted.python.log.err</a> was an error. It did so because I was running mypy in --strict mode</a>. We'll talk more about why I did so and what this means next time</a>; for now, it's enough to know that calling a function that isn't fully annotated from within a function that is constitutes an error under strict mode. twisted</code> is partially annotated: many key modules and functions have type annotations, but others don't. I was reluctant to give up on --strict</code>. Instead, I decided to stub the err</code> function myself. A stub is a cut-down version of a python function, class or module which lives in a .pyi</code> file. All implementation details are removed; only type annotations remain. Stubs are useful when you want to write annotations for code you don't control. The typeshed</a> library is probably the best example: a collection of third party stubs for the standard library, plus some popular third party packages. Microsoft's python-type-stubs</a> is another example. They'd also solve the problem I mentioned at the end of the first part</a>: I could use a stub to teach mypy that IResponse.headers</code> was a Headers</code> object. Writing a stub for log.err</code> was straightforward, thanks mainly to Twisted's thorough documentation. I chose to write it by hand, rather than use stubgen</a>. I'd heard of the latter, but was reluctant to use it for a few reasons. Twisted is a big project with many big files. I didn't want to commit huge stub files for me and my colleagues to maintain.</li> The more our stubs cover, the larger the risk of a stub becoming out-of-date with twisted itself. Upstream twisted is the best place for these annotations.</li> We only need annotations for the bits of twisted that we're using.</li> And, being honest: I wanted the low-level experience of writing stubs, cross-referencing between the source and working how to best capture its type semantics.</li> </ul> I think this decision to write a targeted stub made sense at the time. After all, twisted.python.logging.err</code> is just one simple function! But for the project as a whole, I regret not using stubgen</code> to generate module-level stubs. The reason for this is that a .pyi</code> stub file accounts for an entire module: no more and no less</a>. This means that the stubs I was writing for parts of twisted only covered the functions and classes I'd stubbed. Any existing annotations in the twisted source code would be ignored, along with any types that mypy was able to infer for itself. I think it would have been more efficient to use stubgen</code> to generate stubs and patch them up, rather than writing them. That would have helped avoid a few cases I encountered where stubbing one function would cause additional typechecking failures (because mypy was no longer examining the twisted source for that file). It would also have meant that I could just faithfully stub Twisted as it is; in practice, I would sometimes hesitate to stub to avoid having to cover another module. sydent.http</code> was the most painful part of the source tree for this: that's where we make the most use of Twisted. 🔗</a>defer.inlineCallbacks</a></h4> This is a decorator which allows us to write code in the style of async</code>/await</code> without actually using that syntax. (Twisted predates asyncio</code> and the async</code>/await</code> syntax, introduced in Python 3.4 and 3.5 respectively. It was originally released in 2002, back when Python had released version 2.2.) We only use it in one place in Sydent</a> nowadays, but I've seen used across Synapse too. I mention it here because it was a bit fiddly to annotate. Here's its use in Sydent: @defer.inlineCallbacks def request( self, method: bytes, uri: bytes, headers: Optional["Headers"] = None, bodyProducer: Optional["IBodyProducer"] = None, ) -> Generator["defer.Deferred[Any]", Any, IResponse]: </code></pre> Here, request</code> is a generator function</a> because its body uses the yield</code> keyword. Yielding allows the function to relinquish control back to twisted's reactor, only for its execution to be resumed asynchronously in the future. The Generator</a> type takes three parameters: a YieldType</code>, Deferred[Any]</code>;</li> a SendType</code>, Any</code>; and</li> a ReturnType</code>, IResponse</code>.</li> </ul> Why have I opted to use Any</code> here, when we've seen (and will see) that this limits mypy's ability to run checks? The answer is that we yield two different types within the function. Firstly a routing result</a>: routing: _RoutingResult routing = yield defer.ensureDeferred(self._route_matrix_uri(parsed_uri)) </code></pre> and later, the IResponse</a> we go on to return: res: IResponse res = yield agent.request(method, uri, headers, bodyProducer) </code></pre> In this example: </li> We yield a value y: Deferred[Any]</code>. </li> That will later be resolved by twisted to an x: Any</code> value. Twisted will send that value to request</code>, and the execution continues. </li> This repeats, until we eventually return an IResponse</code>. </li> </ul> I could more correctly annotate the YieldType</code> as Deferred[Union[_RoutingResult, IResponse]]</code> so that the SendType</code> was Union[_RoutingResult, IResponse]</code>. But this would mean we end up having some kind of type check at each yield point: a cast</code>, or a type: ignore</code>, or a runtime isinstance</code> check. It didn't feel like it was worth the boilerplate, especially since I could narrow e.g. res: Any</code> to res: IResponse</code> with minimal effort. This problem doesn't arise with using the async/await</code> syntax: async def foo() -> int: return 1 async def bar() -> None: x = await foo() reveal_type(foo()) reveal_type(x) </code></pre> $ mypy example.py example.py:6: note: Revealed type is "typing.Coroutine[Any, Any, builtins.int]" example.py:7: note: Revealed type is "builtins.int*" </code></pre> Behind the scenes, I think that x = await foo()</code> is really using the same mechanism as the inlineCallbacks</code> approach. An async def</code> function is really a generator function behind the scenes.</li> When we await foo()</code>, we yield the expression foo()</code></li> Then the machinery running our coroutine c</code> will call c.send(x)</code> to resume execution, where x</code> is the value produced by waiting for foo()</code>.</li> </ul> With the await</code> form, mypy knows two things: the value foo()</code> which was yielded should be Awaitable[T]</code>, and</li> the value x</code> send to the coroutine should come from awaiting foo()</code>, and therefore be of type T</code>.</li> </ul> Mypy can't assume or enforce these rules for the yield form, which can yield and send whatever it likes. There's no reason why the send type should be related to the yield type. Here's a toy example: from typing import Any, Dict, Generator def generator_function() -> Generator[int, str, Dict[str, Any]]: y: int = 10 x: str = yield y print("Coroutine was sent", x) # -> Coroutine was sent hello return {"got": x, "done": True} coroutine = generator_function() y = next(coroutine) try: coroutine.send("hello") except StopIteration as e: return_value = e.value print(return_value) # -> {'got': 'hello', 'done': True} </code></pre> All in all, the handling of inlineCallbacks</code> is a situation specific to working with (older?) twisted code. It's still nice to understand what's going on behind the scenes though! 🔗</a>zope.interface.Interface</code></h4> Twisted makes use of zope</code>'s Interface</code> to define a number of abstract interface classes. Speaking personally, I've not seen it used outside twisted, and I think that means it's not supported by much of the typechecking tooling. For example, I've definitely seen PyCharm struggle to realise that it's okay to pass a Response</code> to a function which expects an IResponse</code>! Here's a more complicated example where PyCharm</code> isn't happy with me widening the type LoggingHostnameEndpoint</code> to IStreamClientEndpoint</code>, even though the latter implements the former</a>. Mypy out of the box doesn't play well with a zope Interface</code> (nor does any other typechecker I tried). Fortunately, the excellent mypy-zope</a> plugin helps here: it teaches mypy that any class like Response</code> which @implements(IResponse)</code> can be passed in place of an IResponse</code>. 🔗</a>Tricks of the trade</h3> At this point I'd like to share a few generic lessons about typing I'd picked up. Nothing ground-breaking here: I think these are all fairly well-known. Hopefully they're the start of a good cheat sheet for annotating—though it pales in comparison to the Mypy cheat sheet</a>. 🔗</a>Annotating decorators</h4> Annotating decorators is fiddly, but it's also vitally important. An unannotated decorator will mask or throw away your decoratee's annotations! The way to write the annotation is best explained by the mypy docs</a>, but briefly: it involves a TypeVar</code> and sometimes a cast</code> too. Here's an example. from typing import TypeVar, Callable, Any, cast F = TypeVar("F", bound=Callable[..., Any]) def decorator(input: F) -> F: def wrapped(*args: Any, **kwargs: Any) -> Any: print(f"Calling {f.__name__}") return input_func(*args, **kwargs) return cast(F, wrapped) </code></pre> The idea here is Use Callable[..., Any]</code> to describe a generic function with no particular signature.</li> Use that as a bound on a type variable F</code>. At each usage of @decorator</code>, mypy will deduce a more specific version of F</code>, e.g. Callable[[int], str]</code>.</li> Within that usage of @decorator</code>, F</code> is fixed to that specific type. We use -> F</code> to express that "we return a function with the same signature as the decoratee".</li> Unfortunately, we don't have a good way to tell mypy</code> that wrapped</code> also has that signature F</code>. We resort to a cast</code> to force mypy to accept this without proof.</li> </ol> This might change in the future, e.g. when ParamSpec</a> is fully understood</a> by mypy. 🔗</a>Prefer object</code> over Any</code></h4> Both of these are general types for expressing "I don't know anything about this expression". But only the former will undergo static type checks. We want those type checks to guard against bugs accidentally introduced in the future. For instance, imagine a class with an Any</code> attribute. from typing import Any import dataclasses @dataclasses.dataclass class C: label: Any </code></pre> Imagine in the future we add a new method which assumes that label</code> is a string: def greeting(self) -> str: return "My name is " + self.label </code></pre> Mypy will consider this valid, because no type-checking is done on an Any</code> value. It will complain that it can't prove that greeting</code> returns a str</code>, if --warn-return-any</code> is enabled; but putting that aside, it can't identify the call site as a bug. The bug slips through to runtime. C(123).greeting() # TypeError: can only concatenate str (not "int") to str </code></pre> Replacing the Any</code> with object</code> does allow mypy to spot the problem. error: Unsupported operand types for + ("str" and "object") [operator] </code></pre> 🔗</a># type: ignore</code> and cast</code> sparingly</h4> There's a good chance that mypy knows better than we do, so we should only overrule it if there's no better option. There are two techniques for this. One option is to tell mypy to just silence the error, by appending a # type: ignore</code> comment to the erroneous line. The other is to force it to accept that a certain expression has a given type: that's what cast</a> is for. I never like using either of these, but sometimes they're the most practical choice. I'd recommend two best practices for their use, however: Only ignore a specific error code, e.g. # type: ignore[assignment]</code>. Those codes can be displayed by passing --show-error-codes</code> to mypy.</li> Leave a comment before every #type: ignore[...]</code> and every cast</code> to justify their correctness. I don't think this is a widely-held practice. I picked it up from the Rust world, where it's encouraged</a> as a way to justify unsafe</code> source code.</li> </ol> 🔗</a>There's good stuff in typing</code></h4> It's worth a read through the module documentation</a>—plenty of things in there I wish I'd known about sooner. There's lots in the toolkit to chose from. Some bits I use fairly often include: Protocol</a>: lets you formalise duck typing. To use it, define a class that inherits from Protocol</code>. Its methods and attributes are all stubs which describe what you require of objects belonging to this type. It's like an abstract base class</a> or interface, but purely at typecheck time.</li> Generic</a>: define your own generic types. A bit of a slippery slope to type mania!</li> Optional</a>: I use this all the time. It's always good to make your None</code>s explicit!</li> NewType</a>: I haven't had a chance to use it much. As I understand it, it's a way to define a "strong typedef". For example, we can use it to distinguish lengths from durations, even if they're both represented by a float</code> at runtime.</li> </ul> I want to call out two parts of typing</code> in particular: 🔗</a>overload</a></h4> overload</code> is a way to provide extra information about a function depending on how it's called. For instance, consider this function which takes a str</code> or bytes</code> as input and returns its uppercase version. def upper(x: Union[bytes, str]) -> Union[bytes, str]: return x.upper() </code></pre> The problem with this annotation is that we'll have to check at every call site to see if the return value was a bytes</code> or a str</code> object. But we know that uppercasing a str</code> gives us a str</code>, and uppercasing a bytes</code> gives us a bytes.</code> We can use overload</code> to express this. from typing import overload @overload def upper(x: str) -> str: ... @overload def upper(x: bytes) -> bytes: ... def upper(x: Union[bytes, str]) -> Union[bytes, str]: return x.upper() </code></pre> The first two @overload</code> definitions are like stubs: they're purely used for their annotations. The actual runtime implementation is specified at the end, undecorated. (NB: this specific example is better expressed without overloads, by using AnyStr</a>.) I was really impressed to see how mypy</code> could use this overloading information. Here's an example: from typing import overload, Literal @overload def f(x: int) -> Literal[1]: ... @overload def f(x: str) -> Literal[2]: ... def f(x: object) -> int: if isinstance(x, int): return 1 elif isinstance(x, str): return 2 return 3 if f(10) == 2: print("potato") </code></pre> We can see that f(10) == 1</code> and so the equality is always False</code>: we'll never print the word "potato". Mypy can reason through this too, if we ask it nicely. $ mypy example.py Success: no issues found in 1 source file $ mypy --strict-equality --warn-unreachable example.py example.py:16: error: Non-overlapping equality check (left operand type: "Literal[1]", right operand type: "Literal[2]") example.py:17: error: Statement is unreachable Found 2 errors in 1 file (checked 1 source file) </code></pre> 🔗</a>TypedDict</a></h4> I mentioned this in last week's post</a>) when talking about the missing await</code> bug. Subclassing from TypedDict</code> allows us to define a new type whose values are dictionaries with a fixed set of keys (some mandatory, some not), and</li> a fixed type for each key's value.</li> </ul> PEP 589</a> can best describe the motivation, but in short: there's a lot of source code out there that passes dictionaries around. TypedDict</code> is a way to gradually add typechecking to that code, without having to refactor it to use e.g. a dataclass</a> or a NamedTuple</a>. Let's have a quick example. from typing import List, TypedDict class Person(TypedDict): full_name: str nicknames: List[str] age: int p: Person = { "full_name": "David Matthew Robertson", "nicknames": ["dmr"], "age": 29, } </code></pre> Mypy will detect if you delete or omit a required key, or if you insert a key that's not part of the type. # error: Key "age" of TypedDict "Person" cannot be deleted del p["age"] # error: Missing keys ("full_name", "nicknames", "age") for TypedDict "Person" p2: Person = {} # error: TypedDict "Person" has no key "eye_colour" p["eye_colour"] = "brown" </code></pre> TypedDict</code> is a useful tool, but there are a few important gotchas to be aware of. In my view, these are all minor and worth putting up with, to benefit from the extra type information that a TypedDict</code> provides. Let's take a look. 🔗</a>TypedDict</code> is incompatible with Dict</code></h5> This one surprised me at first. Why can't I pass my TypedDict</code> to a function that accepts a generic dictionary? import json from typing import Dict, TypedDict class Foo(TypedDict): bar: str def print_size(d: Dict[object, object]) -> None: print(len(d)) f: Foo = {"bar": "baz"} # error: Argument 1 to "print_size" has incompatible type "Foo"; expected "Dict[object, object]" print_size(f) </code></pre> The answer is that it wouldn't be type-safe! For all we know, the function print_size</code> might mutate its argument d</code>. It might add a key, remove a key, or change the type of a value. Each of those would break the contract that TypedDict</code> is supposed to enforce, so mypy is correct to flag this as an error. This GitHub issue</a> has more discussion. There are few workarounds for this kind of problem. The function might be able to accept a TypedDict</code> directly.</li> The function could accept a Mapping</code> instead of a Dict</code>. This is type-safe because the Mapping</code> type does not offer mutating methods such as pop</code>, __setitem__</code>, __del__</code>; but it only works if the function does not mutate the dictionary.</li> A more drastic approach would discard the TypedDict</code> information with a cast</code> to Dict[str, object]</code> or similar. If so, I'd strongly recommend a comment explaining why the cast is correct and safe.</li> </ul> 🔗</a>Mixing mandatory and required fields</h5> Secondly, defining a TypedDict</code> with a mixture of optional and required keys is a little fiddly. All keys can be made optional by passing total=False</code> in the class definition. To have some keys optional and others mandatory, we have to make two TypedDicts. Say for instance we wanted to allow a potentially-missing favourite_colour</code> field to Person</code>. We can't add an annotation favourite_colour: Optional[str]</code> to the first class body. That's optional in a different sense: it would mean that favourite_colour</code> is a mandatory field which is allowed to be None</code>. Instead, we apply total=False</code> to a subclass: from typing import List, TypedDict class _PersonRequired(TypedDict): full_name: str nicknames: List[str] age: int class Person(_PersonRequired, total=False): favourite_colour: str </code></pre> This means that a valid Person</code> dictionary may have no favourite_colour</code> key. If it is present, it must be a str</code>. The syntax is unfortunately a little clunky. PEP 655</a> acknowledges this and proposes an alternative. 🔗</a>TypedDict</code> is typecheck-time only</h5> One final note: a TypedDict</code> does no validation or conversion whatsoever. If mypy can't know the keys and values a dictionary will have a typecheck-time, you'll need to validate it by hand at runtime. We see this a lot because when deserialising json objects into a dictionary. Here's an example. import json from typing import TypedDict class Foo(TypedDict): bar: str # note: Revealed type is "Any" reveal_type(json.loads("{}")) # no error. mypy can't do analysis on Any. f: Foo = json.loads("{}") </code></pre> 🔗</a>Next time</h2> This covers a lot of the machinery and the day-to-day process of annotating Sydent. The last part of this series</a> will give us a chance to quantify our efforts and reflect on the wider typing ecosystem. Many thanks for reading! If you've got any corrections, comments or queries, I'm available on Matrix at @dmrobertson:matrix.org</a>. Type coverage for Sydent: motivation 2021-12-03T00:00:00+00:00 This is the first of three posts on improving type coverage in Sydent. Join us next Friday for the second part</a>! Sydent</a> is the reference Matrix Identity server. It provides a lookup service</a>, so that you can find a Matrix user via their email address or phone number (if they've chosen to share it). We recently worked on improving Sydent's type coverage</a>: the proportion of its source code with explicit annotations denoting the kind of data that each variable, expression and return value is expected to hold. These annotations are optional, but if present, they allow tools like mypy</a> to analyze your programs and spot entire classes of bugs before you ship them! In this instance, we aimed to make Sydent pass mypy --strict</code>, which it now does</a>. Here's what the process looked like: Two lines show two different measures of how well-typed the project is. The grey region covers our two-week sprint towards improving coverage; the earliest data point is from just before previous efforts to improve typing earlier in the year. In a series of posts, I'd like to reflect on this sprint and share what we've learned. In particular, I aim to: explain why we wanted to improve type coverage now;</li> work through examples to see how (if?) mypy could have spotted bugs;</li> describe the annotation process;</li> illustrate common patterns I learned along the way;</li> discuss the checks that mypy</code> provides; and finally</li> reflect on the state of Python's typing ecosystem.</li> </ul> In this first part, we'll concentrate on the first two topics; the second</a> covers the middle two; and the third</a> the last two. 🔗</a>Why do this now?</h2> It took us a long time (too long) to notice that the Sydent instance serving matrix.org</code> was failing to send SMS messages for verification</a>. We suspected that something was going wrong with our API call to OpenMarket</a>. Our first step was to improve logging</a>, so we could start to deduce what was going wrong and why. Whilst trawling through logs, we spotted one problem</a> which meant we weren't actually sending off the API request in the first place. Further investigation revealed a strings-versus-bytes confusion</a> which meant that we would always (incorrectly) interpret the API response as having failed. All in all, phone number verification was unknowingly broken in the 2.4.0 release, to be fixed in 2.4.6 a month later. How could we do better? Better test coverage is (as ever) one answer. But it struck me</a> that the two bugs we'd encountered might be ripe for automatic detection: we created an Awaitable</a> but didn't await</code> it or use it in any way, and</li> we tried to look up a str</code> key in a dictionary which mapped bytes</code> to bytes</code>.</li> </ul> Could a static analysis tool like mypy</code> detect these? How much work would it take to do so? Are there other bugs and problems we could spot with it? I was curious to answer these questions and learn more about the tools that Python's typing ecosystem provides. 🔗</a>Could typing have spotted these problems?</h2> Let's start with the first of question: what can mypy</code> detect? 🔗</a>The missing await</code></h3> Instead of writing x = await foo()</code>, we simply had x = foo()</code> and didn't then go on to await x</code>. Mypy doesn't have means to detect this at present. There was interest in this issue</a> on such a feature, with related threads here</a> and here</a>. Are there other opportunities to spot the error? Here's the relevant bit of source code from before the fix</a>. sid = self.sydent.validators.msisdn.requestToken( phone_number_object, clientSecret, sendAttempt, brand ) resp = { "success": True, "sid": str(sid), "msisdn": msisdn, "intl_fmt": intl_fmt, } </code></pre> The call to requestToken</code> produces a value of type Awaitable[int]</code>. If we tried to assign that to an expression of type int</code> we'd get an error that mypy can spot. $ cat example.py async def foo() -> int: return 1 async def bar(): x = foo() # no error y: int = foo() # error: rhs is Awaitable[int], but lhs expects int $ mypy --check-untyped-defs example.py example.py:6: error: Incompatible types in assignment (expression has type "Coroutine[Any, Any, int]", variable has type "int") Found 1 error in 1 file (checked 1 source file) </code></pre> Note that we have to specifically ask mypy to typecheck the body of bar</code> by passing --check-untyped-defs</a>; by default, mypy</code> will only typecheck annotated code. We might also have been able to detect the error by looking at how we used sid</code>. Unfortunately, the only use of was in a conversion str(sid)</code>, which is a perfectly type-safe call for both sid: int</code> and sid: Awaitable[int]</code>. But let's put that aside for a second—suppose we added "sid": sid</code> directly into the resp</code> dictionary. Could mypy have spotted there was a problem with that? Unfortunately not. Because resp</code> has no annotation, we have to rely on how it's used to spot any type inconsistencies. There's only one use of resp</code>: as the return value from its enclosing function, render_POST</code>. Mypy's only chance to spot a type problem would be to compare the mypy's inferred type for resp</code> to the return type of render_POST</code>. What are those types? We can use reveal_type</code> to see the former is Dict[str, object]</code>. For the latter: @jsonwrap def render_POST(self, request: Request) -> JsonDict: </code></pre> The return type is JsonDict</code>, which is an alias</a> for Dict[str, Any]</code>. This is bad news, because Dict[str, object]</code> and Dict[str, Any]</code> are compatible. Digging a level deeper, this is because sid: Any</code> holds true for both sid: int</code> and sid: Awaitable[int]</code>—so there's no error to spot here. The Any</code> type is compatible with any other type whatsoever! Mypy uses Any</code> as a way to defer all type checking to runtime</a>; mypy won't (and can't!) statically analyse the usage of an expression of type Any</code>. Indeed, mypy's reports will tell you how many Any</code>s you're working with, and offer a variety of options to warn or error on usages of Any</code></a>. If we were inserting sid</code> directly into a dictionary, we could do better by annotating the dictionary (or the function's return type) as a TypedDict</a>. This is a way to specify a dictionary with a fixed set of keys, each with a fixed type. It comes in really handy for Sydent, Sygnal and Synapse—all of the Matrix APIs</a> exchange JSON dictionaries, so anything we can do to teach mypy about their shape and types is gold dust. In short, there were options for detecting this with some code changes, but no magic wand that would have spotted the error in the code as written. 🔗</a>The strings/bytes confusion</h3> Our error</a> was here: headers = dict(resp.headers.getAllRawHeaders()) request_id = None if "X-Request-Id" in headers: request_id = headers["X-Request-Id"][0] </code></pre> In this sample, resp.headers</code> is a twisted.web.http_headers.Headers</a> instance. getAllRawHeaders</code> is documented</a> as returning an iterable of (bytes, Sequence[bytes])</code> pairs. Even better, mypy can see this because getAllRawHeaders</code> is annotated</a> (many thanks to the twisted authors for this). Mypy should be able to deduce that we build a dictionary headers: Dict[bytes, Sequence[bytes]</code>. We can check this using reveal_type</code></a>: headers = dict(resp.headers.getAllRawHeaders()) reveal_type(headers) </code></pre> $ mypy sydent/sms/openmarket.py:110: note: Revealed type is "builtins.dict[builtins.bytes*, typing.Sequence*[builtins.bytes]]" </code></pre> (The *</code> in builtins.bytes*</code> here means mypy has inferred</a> that the dictionary's keys are bytes, rather than being told explicitly that they must be bytes.) That's all fine and dandy. But why didn't we spot this before if the annotations were all in place in twisted? Let's put aside the fact that, erm, we weren't running mypy in Sydent's CI until the recent sprint</a>, unlike our other</a> projects</a>. Checking out the problematic version, we can run mypy on the file we know to contain the bug. $ git checkout v2.4.0 $ mypy --strict sydent/sms/openmarket.py sydent/sms/openmarket.py:82: error: Dict entry 0 has incompatible type "str": "int"; expected "str": "str" [dict-item] </code></pre> Huh. Mypy spots something, but not the error we were hoping for. What's going on here? We can ask mypy to show its working with reveal_type</code> again. resp = await self.http_cli.post_json_get_nothing( API_BASE_URL, send_body, {"headers": req_headers} ) reveal_type(resp) headers = dict(resp.headers.getAllRawHeaders()) reveal_type(resp.headers) reveal_type(resp.headers.getAllwRawHeaders()) reveal_type(headers) </code></pre> This yields: $ mypy sydent/sms/openmarket.py sydent/sms/openmarket.py:82: error: Dict entry 0 has incompatible type "str": "int"; expected "str": "str" [dict-item] sydent/sms/openmarket.py:102: note: Revealed type is "twisted.web.iweb.IResponse*" sydent/sms/openmarket.py:104: note: Revealed type is "Any" sydent/sms/openmarket.py:105: note: Revealed type is "Any" sydent/sms/openmarket.py:106: note: Revealed type is "builtins.dict[Any, Any]" Found 1 error in 1 file (checked 1 source file) </code></pre> Ahh, the Any</code> type. As mentioned above, this represents a value whose type can't be statically determined. We're left to runtime checks to detect the problem. But we won't detect it at runtime, because dictionaries don't enforce any kind of type requirements on their keys and values. The problem here is that mypy can't see that resp.headers</code> is a twisted Headers</code> object. If we could inform it of this, mypy would spot our bug: import twisted.web.http_headers raw_headers: twisted.web.http_headers.Headers = resp.headers reveal_type(resp) headers = dict(raw_headers.getAllRawHeaders()) reveal_type(raw_headers) reveal_type(raw_headers.getAllRawHeaders()) reveal_type(headers) </code></pre> $ mypy sydent/sms/openmarket.py sydent/sms/openmarket.py:82: error: Dict entry 0 has incompatible type "str": "int"; expected "str": "str" [dict-item] sydent/sms/openmarket.py:104: note: Revealed type is "twisted.web.iweb.IResponse*" sydent/sms/openmarket.py:106: note: Revealed type is "twisted.web.http_headers.Headers" sydent/sms/openmarket.py:107: note: Revealed type is "typing.Iterator[Tuple[builtins.bytes, typing.Sequence[builtins.bytes]]]" sydent/sms/openmarket.py:108: note: Revealed type is "builtins.dict[builtins.bytes*, typing.Sequence*[builtins.bytes]]" sydent/sms/openmarket.py:114: error: Invalid index type "str" for "Dict[bytes, Sequence[bytes]]"; expected type "bytes" [index] sydent/sms/openmarket.py:114: error: Argument 1 to "split" of "bytes" has incompatible type "str"; expected "Optional[bytes]" [arg-type] Found 3 errors in 1 file (checked 1 source file) </code></pre> There it is, on line 114: Invalid index type "str" for "Dict[bytes, Sequence[bytes]]"; expected type "bytes"</code>. Unfortunately it'd be a pain to annotate our application code to mark every use of IResponse.headers</code> as a Headers</code> object. We'll see a better way to do things in this the next post</a>, which discusses the nitty-gritty details of adding annotations file-by-file. Many thanks for reading! If you've got any corrections, comments or queries, I'm available on Matrix at @dmrobertson:matrix.org</a>. How the UK's Online Safety Bill threatens Matrix 2021-05-19T15:47:03+00:00 Last week the UK government published a draft of the proposed Online Safety Bill,</a> after having initially introduced formal proposals for said bill in early 2020</a>. With this post we aim to shed some light on its potential impacts and explain why we think that this bill - despite having great intentions - may actually be setting a dangerous precedent when it comes to our rights to privacy, freedom of expression and self determination. The proposed bill aims to provide a legal framework to address illegal and harmful content online. This focus on “not illegal, but harmful” content is at the centre of our concerns - it puts responsibility on organisations themselves to arbitrarily decide what might be harmful, without any legal backing. The bill itself does not actually provide a definition of harmful, instead relying on service providers to assess and decide on this. This requirement to identify what is “likely to be harmful” applies to all users, children and adults. Our question here is - would you trust a service provider to decide what might be harmful to you and your children, with zero input from you as a user? Additionally, the bill incentivises the use of privacy-invasive age verification processes which come with their own set of problems. This complete disregard of people’s right to privacy is a reflection of the privileged perspectives of those in charge of the drafting of this bill, which fails to acknowledge how actually harmful it would be for certain groups of the population to have their real life identity associated with their online identity. Our view of the world, and of the internet, is largely different from the one presented by this bill. Now, this categorically does not mean we don’t care about online safety (it is quite literally our bread and butter) - we just fundamentally disagree with the approach taken. Whilst we sympathise with the government’s desire to show action in this space and to do something about children’s safety (everyone’s safety really), we cannot possibly agree with the methods. Back in October of 2020 we presented our proposed approach to online safety</a> - ironically also in response to a government proposal, albeit about encryption backdoors. In it, we briefly discussed the dangers of absolute determinations of morality from a single cultural perspective: As uncomfortable as it may be, one man’s terrorist is another man’s freedom fighter, and different jurisdictions have different laws - and it’s not up to the Matrix.org Foundation to play God and adjudicate.</a> </blockquote> We now find ourselves reading a piece of legislation that essentially demands these determinations from tech companies. The beauty of the human experience lies with its diversity and when we force technology companies to make calls about what is right or wrong - or what is “likely to have adverse psychological or physical impacts” on children - we end up in a dangerous place of centralising and regulating relative morals. Worst of all, when the consequence of getting it wrong is criminal liability for senior managers what do we think will happen? Regardless of how omnipresent it is in our daily lives, technology is still not a solution for human problems. Forcing organisations to be judge and jury of human morals for the sake of “free speech” will, ironically, have severe consequences on free speech, as risk profiles will change for fear of liability. Forcing a “duty of care” responsibility on organisations which operate online will not only drown small and medium sized companies in administrative tasks and costs, it will further accentuate the existing monopolies by Big Tech. Plainly, Big Tech can afford the regulatory burden - small start-ups can’t. Future creators will have their wings clipped from the offset and we might just miss out on new ideas and projects for fear of legal repercussions. This is a threat to the technology sector, particularly those building on emerging technologies like Matrix. In some ways, it is a threat to democracy and some of the freedoms this bill claims to protect. These are, quite frankly, steps towards an authoritarian dystopia. If Trust & Safety managers start censoring something as natural as a nipple on the off chance it might cause “adverse psychological impacts” on children, whose freedom of expression are we actually protecting here? More specifically on the issue of content moderation: the impact assessment provided by the government alongside this bill</a> predicts that the additional costs for companies directly related to the bill will be in the billions, over the course of 10 years. The cost for the government? £400k, in every proposed policy option. Our question is - why are these responsibilities being placed on tech companies, when evidently this is a societal problem? We are not saying it is up to the government to single-handedly end the existence of Child Sexual Abuse and Exploitation (CSAE) or extremist content online. What we are saying is that it takes more than content filtering, risk assessments and (faulty) age verification processes for it to end. More funding for tech literacy organisations and schools, to give children (and parents) the tools to stay safe is the first thing that comes to mind. Further investment in law enforcement cyber units and the judicial system, improving tech companies’ routes for abuse reporting and allowing the actual judges to do the judging seems pretty sensible too. What is absolutely egregious is the degradation of the digital rights of the majority, due to the wrongdoings of a few. Our goal with this post is not to be dramatic or alarmist. However, we want to add our voices to the countless digital rights campaigners</a>, individuals and organisations that have been raising the alarm since the early days of this bill. Just like with coercive control and abuse, the degradation of our rights does not happen all at once. It is a slippery slope that starts with something as (seemingly) innocuous as mandatory content scanning for CSAE content and ends with authoritarian surveillance infrastructure</a>. It is our duty to put a stop to this before it even begins. Twitter card image credit from Brazil</a>, which feels all too familiar right now. The Matrix Space Beta! 2021-05-17T17:50:17+00:00 Hi all, As many know, over the years we've experimented with how to let users locate and curate sets of users and rooms in Matrix. Back in Nov 2017</a> we added 'groups' (aka 'communities') as a custom mechanism for this - introducing identifiers beginning with a + symbol to represent sets of rooms and users, like +matrix:matrix.org</a>. However, it rapidly became obvious that Communities had some major shortcomings. They ended up being an extensive and entirely new API surface (designed around letting you dynamically bridge the membership of a group through to a single source of truth like LDAP) - while in practice groups have enormous overlap with rooms: managing membership, inviting by email, access control, power levels, names, topics, avatars, etc. Meanwhile the custom groups API re-invented the wheel for things like pushing updates to the client (causing a whole suite of problems</a>). So clients and servers alike ended up reimplementing large chunks of similar functionality for both rooms and groups. And so almost before Communities were born, we started thinking about whether it would make more sense to model them as a special type of room, rather than being their own custom primitive. MSC1215</a> had the first thoughts on this in 2017, and then a formal proposal emerged at MSC1772</a> in Jan 2019. We started working on this in earnest at the end of 2020, and christened the new way of handling groups of rooms and users as... Spaces! Spaces work as follows: You can designate specific rooms as 'spaces', which contain other rooms.</li> You can have a nested hierarchy of spaces.</li> You can rapidly navigate around that hierarchy using the new 'space summary' (aka space-nav) API - MSC2946</a>.</li> Spaces can be shared with other people publicly, or invite-only, or private for your own curation purposes.</li> Rooms can appear in multiple places in the hierarchy.</li> You can have 'secret' spaces where you group your own personal rooms and spaces into an existing hierarchy.</li> </ul> Today, we're ridiculously excited to be launching Space support as a beta in matrix-react-sdk and matrix-android-sdk2 (and thus Element Web/Desktop and Element Android) and Synapse 1.34.0</a> - so head over to your nearest Element, make sure it's connected to the latest Synapse (and that Synapse has Spaces enabled in its config) and find some Space to explore! #community:matrix.org</a> might be a good start :) The beta today gives us the bare essentials: and we haven't yet finished space-based access controls such as setting powerlevels in rooms based on space membership (MSC2962</a>) or limiting who can join a room based on their space membership (MSC3083</a>) - but these will be coming asap. We also need to figure out how to implement Flair on top of Spaces rather than Communities. This is also a bit of a turning point in Matrix's architecture: we are now using rooms more and more as a generic way of modelling new features in Matrix. For instance, rooms could be used as a structured way of storing files (MSC3089</a>); Reputation data (MSC2313</a>) is stored in rooms; Threads can be stored in rooms (MSC2836</a>); Extensible Profiles are proposed as rooms too (MSC1769</a>). As such, this pushes us towards ensuring rooms are as lightweight as possible in Matrix - and that things like sync and changing profile scale independently of the number of rooms you're in. Spaces effectively gives us a way of creating a global decentralised filesystem hierarchy on top of Matrix - grouping the existing rooms of all flavours into an epic multiplayer tree of realtime data. It's like USENET had a baby with the Web! For lots more info from the Element perspective, head over to the Element blog</a>. Finally, the point of the beta is to gather feedback and fix bugs - so please go wild in Element reporting your first impressions and help us make Spaces as awesome as they deserve to be! Thanks for flying Matrix into Space; Matthew & the whole Spaces (and Matrix) team. Introducing the Pinecone overlay network 2021-05-06T00:00:00+00:00 Since the end of 2019, we have spent quite a bit of time thinking about and exploring different technologies whilst building various demos for P2P Matrix. Our mission for P2P Matrix is to evolve Matrix into a hybrid between today's server-oriented network and a pure P2P network - empowering users to have total autonomy and privacy over their data if they want (by storing it in P2P Matrix, by embedding their server into their Matrix client), while also letting users store their data in serverside nodes if they so desire. The goal is to protect metadata much better (as users no longer have to depend on a server run by someone else to communicate), as well as drive new features such as account portability, multi-homed accounts, low-bandwidth Matrix and smarter federation transports - and provide support for internet-less mesh communication via Matrix which can also interoperate with the wider network. You can read more about it in our Introducing P2P Matrix</a> blog post from last summer, or watch our FOSDEM 2021 talk</a> where we previewed Pinecone. It's important to note that this has been a small but important long-term project for Matrix, and has been progressing entirely outside our business-as-usual work of improving the core protocol and reference implementations. As the project has progressed, we've built a variety of prototypes using existing libraries (go-libp2p</a>, js-libp2p</a> and Yggdrasil</a>), demonstrating what an early P2P Matrix might feel like if it were running on a mobile device, in the web browser and so on using such an overlay network. Each of these demos has taught us something new, and so in October 2020 we decided to take this knowledge to build an experimental new overlay network of our own. Pinecone is designed to provide end-to-end encrypted communications between devices, regardless of how they are connected to one another, in a lightweight and self-arranging fashion. The routing protocol is a hybrid, taking inspiration from Yggdrasil</a> by building a global spanning tree, but rather than forwarding all traffic using the spanning tree topology, we use it as a bootstrap routing mechanism for a line/snake topology, ordered by their ed25519 public keys, which we have affectionately named SNEK (Sequentially Networked Edwards Key) routing. Nodes seek out their closest keyspace neighbours on the network and paths are built between these pairs of nodes, similar to how a Chord DHT functions, populating the routing tables of intermediate nodes in the process. These paths are then used to forward traffic without having to perform up-front searches, allowing for very fast connection setups between overlay nodes. These paths are resilient to network topology changes and handle node mobility considerably better than any other name-independent routing scheme that we have seen — early results are very promising so far. We have also been experimenting with a combination of the μTP (Micro Transport Protocol) and TLS to provide stateful connection setup, congestion control and end-to-end encryption for all federation traffic carried over the Pinecone network. If Pinecone works out, our intention is to collaborate with the libp2p and IPFS team to incorporate Pinecone routing into libp2p (if they'll have us!) while incorporating their gossipsub routing to improve Matrix federation... and get the best of both worlds :) Today we're releasing the source code for our current early implementation of Pinecone — you can get it from GitHub</a> right now! It's very experimental still and not very well optimised yet, but it is the foundation of our latest mobile P2P Matrix demos, which support P2P Matrix over both Bluetooth Low Energy mesh networks, multicast DNS discovery within a LAN, and/or by routing through static Pinecone peers on the Internet: Android: https://appdistribution.firebase.dev/i/394600067ea8ba37</a></li> iOS: https://testflight.apple.com/join/Tgh2MEk6</a></li> </ul> Building a routing overlay is only the first step in the journey towards P2P Matrix. We will also be looking closely in the coming months at improving the Matrix federation protocol to work well in mixed-connectivity scenarios (rather than the full mesh approach used today) as well as decentralised identities, hybrid deployments with existing homeservers and getting Dendrite (the Matrix homeserver which is embedded into the current P2P demos) more stable and feature-complete. The long-term plan could look something like this: Most discussion around P2P Matrix takes place in #p2p:matrix.org</a>, so if you are interested in what's going on, please join us there! Privacy improvements in Synapse 1.4 and Riot 1.4 2019-09-27T00:00:00+00:00 Hi all, Back in June we wrote about our plans to tighten up data privacy</a> in Matrix after some areas for improvement were brought to our attention. To quickly recap: the primary concern was that the default config for Riot specifies identity servers and integration managers run by New Vector (the company which the original Matrix team set up to build Riot and fund Matrix dev) - and so folks using a standalone homeserver may end up using external services without realising it. There were some other legitimate issues raised too (e.g. contact information should be obfuscated when checking if your contacts are on Matrix; Riot defaulted to using Google for STUN (firewall detection) if no TURN server had been set up on their server; Synapse defaults to using matrix.org as a key notary server). We’ve been working away at this fairly solidly over the last few months. Some of the simpler items shipped quickly (e.g. Riot/Web had a stupid bug</a> where it kept incorrectly loading the integration manager; Riot/Android wasn’t clear enough</a> about when contact discovery was happening; Riot/Web wasn’t clear enough</a> about the fact device names are publicly visible; etc) - but other bits have turned out to be incredibly time-consuming to get right. However, we’re in the process today of releasing Synapse 1.4.0 and Riot/Web 1.4.0 (it’s coincidence the version numbers have lined up!) which resolve the majority of the remaining issues. The main changes are as follows: Riot no longer automatically uses identity servers by default. Identity servers are only useful when inviting users by email address, or when discovering whether your contacts are on Matrix. Therefore, we now wait until the user tries to perform one of these operations before explaining that they need an identity server to do so, and we prompt them to select one if they want to proceed. This makes it abundantly clear that the user is connecting to an independent service, and why. </li> Integration Managers and identity servers now have the ability to force users to accept terms of use before using them. This means they can explicitly spell out the data privacy & usage policy of the server as required by GDPR, and it should now be impossible for a user to use these services without realising it. This was particularly fun in the case of identity servers, which previously had no concept of users and so couldn’t track whether users had agreed to their terms & conditions or not… and because homeservers sometimes talk to the identity server on behalf of users rather than the user talking direct, the privacy policy flow gets even hairier. But it’s solved now, and a nice side-effect of this is that users can now explicitly select their Integration Manager in Riot, in case they want to use Dimension</a> or similar rather than the default provided by Modular</a>. </li> Synapse no longer uses identity servers for verifying registrations or verifying password reset. Originally, Synapse made use of the fact that the Identity Service contains email/msisdn verification logic to handle identity verification in general on behalf of the homeserver. However, in retrospect this was a mistake: why should the entity running your identity server have the right to verify password resets or registration details on your homeserver? So, we have moved this logic into Synapse. This means Synapse 1.4.0 requires new configuration for email/msisdn verification to work - please see the upgrade notes for full details. </li> Sydent now supports discovering contacts based on hashed identifiers. MSC2134</a> specifies entirely new IS APIs for discovering contacts using a hash of their identifier rather than directly exposing the raw identifiers being searched for. This is implemented in Riot/iOS</a> and Riot/Android</a> and should be in the next major release; Riot/Web</a> 1.4.0 has it already. </li> Synapse now warns in its logs</a> if you are using matrix.org as a default trusted key server, in case you wish to use a different server to help discover other servers’ keys. </li> Synapse now garbage collects redacted messages</a> after N days (7 days by default). (It doesn’t yet garbage collect attachments referenced from redacted messages; we’re still working on that). </li> Synapse now deletes account access data</a> (IP addresses and User Agent) after N days (28 days by default) of a device being deleted. </li> Riot warns before falling back to using STUN (and defaults to turn.matrix.org rather than stun.google.com) for firewall discovery (STUN) when placing VoIP calls, and makes it clear that this is an emergency fallback for misconfigured servers which are missing TURN support. (We originally deleted the fallback entirely, but this broke things for too many people, so we’ve kept it but warn instead). </li> </ol> All of this is implemented in Riot/Web 1.4.0 and Synapse 1.4.0. Riot/Web 1.4.0 shipped today (Fri Sept 27th) and we have a release candidate for Synapse 1.4 (1.4.0rc1) today which fully ship on Monday. For full details please go check out the Riot 1.4.0</a> and Synapse 1.4.0</a> blog posts. Riot/Mobile is following fast behind - most of the above has been implemented and everything should land in the next release. RiotX/Android doesn’t really have any changes to make given it hadn’t yet implemented Identity Service or Integration Manager APIs. This has involved a surprisingly large amount of spec work; no fewer than 9 new Matrix Spec Changes (MSC) have been required as part of the project. In particular, this results in a massive update to the Identity Service API, which will be released very shortly with the new MSCs. You can see the upcoming changes on the unstable branch</a> and compare with the previous 0.2.1 stable release</a>, as well as checking the detailed MSCs as follows: MSC1961: Integration manager authentication APIs</a></li> MSC2078: Sending Third-Party Request Tokens via the Homeserver</a></li> MSC2134: Identity Hash Lookups</a></li> MSC2140: Terms of Service for ISes and IMs</a></li> MSC2229: Allowing 3PID Owners to Rebind</a></li> MSC2230: Store Identity Server in Account Data</a></li> MSC2263: Give homeservers the ability to handle their own 3PID registrations/password resets</a></li> MSC2264: Add an unstable feature flag to MSC2140 for clients to detect support</a></li> MSC2290: Separate Endpoints for Threepid Binding</a></li> </ul> This said, there is still some work remaining for us to do here. The main things which haven’t made it into this release are: Preferring to get server keys from the source server rather than the notary server by default (https://github.com/matrix-org/synapse/pull/6110</a>). This almost made it in, but we need to test it more first - until then, your specified notary server will see roughly what servers your servers are trying to talk to. In future this will be mitigated properly by MSC1228 (removing mxids from events)</a>.</li> Configurable data retention periods for rooms. We are tantalisingly close with this - https://github.com/matrix-org/synapse/pull/5815</a> is an implementation that the French Govt deployment is using; we need to port it into mainline Synapse.</li> Authenticating access to the media repository - for now, we still rely on media IDs being almost impossible to guess to protect the data rather than authenticating the user.</li> Deleting items from the media repository - we still need to hook up deletion APIs.</li> Garbage collecting forgotten rooms. If everyone leaves & forgets a room, we should delete it from the DB.</li> Communicating erasure requests over federation</a></li> </ul> We’ll continue to work on these as part of our ongoing maintenance backlog. Separately to the data privacy concerns, we’ve had a separate wave of feedback</a> regarding how we handle GDPR Data Subject Access Requests (DSARs). Particularly: whether DSAR responses should contain solely the info your have directly keyed by the requesting Matrix ID - or if we should provide all the data “visible” to that ID (i.e. the history of the conversations they’ve been part of). We went and got professional legal advice on this one, and the conclusion is that we should keep our responses to DSARs as tightly scoped as possible. We updated Matrix.org’s privacy policy</a> and DSAR tools to reflect the new legal input. Finally, it’s really worth calling out the amount of effort that went into this project. Huge huge thanks to everyone involved (given it’s cut across pretty much every project & subteam we have working on the core of Matrix) who have soldiered through the backlog. We’ve been tracking progress using our feature-dashboard</a> tool which summarises Github issues based on labels & issue lifecycle, and for better or worse it’s ended up being the biggest project board we’ve ever had. You can see the live data here</a> (warning, it takes tens of seconds to spider Github to gather the data) - or, for posterity and ease of reference, I’ve included the current issue list below. The issues which are completed have “done” after them; the ones still in progress say “in progress”, and ones which haven’t started yet have nothing. We split the project into 3 phases - phases 1 and 2 represent the items needed to fully solve the privacy concerns, phase 3 is right now a mix of "nice to have" polish and some more speculative items. At this point we’ve effectively finished phase 1 on Synapse & Riot/Web, and Riot/Mobile is following close behind. We're continuing to work on phase 2, and we’ll work through phase 3 (where appropriate) as part of our general maintenance backlog. I hope this gives suitable visibility on how we’re considering privacy; after all, Matrix is useless as an open communication protocol if the openness comes at the expense of user privacy. We’ll give another update once the remaining straggling issues are closed out; and meanwhile, now the bulk of the privacy work is out of the way on Riot/Web, we can finally get back to implementing the UI E2E cross-signing verification and improving first time user experience. Thanks for your patience and understanding while we’ve sorted this stuff out; and thanks once again for flying Matrix :) In the absence of comments on the current blog, please feel free to discuss over at HN</a>, or alternatively come ask stuff in our AMA over at /r/privacy</a> (starting ~5pm GMT+1 (UK) on Friday Sept 27th). 🔗</a>The Privacy Project Dashboard Of Doom</h3> phase:1 vector-im/riot-web 5846 Riot duplicates calls to Scalar</a> (done)</li> 5921 Ability to disable all identity server functionality via the config file</a> (done)</li> 6802 riot shouldn't try to load integrations from an integration manager unless the user has accepted that manager's privacy policies</a> (done)</li> 10088 Prompt to accept integration manager polices on use</a> (done)</li> 10090 Make sure there are no ugly edge cases running Riot without an integrations manager</a> (done)</li> 10091 Decouple setting an email for password reset from publishing your threepid to the identity server and support choice of identity server (on registration)</a> (done)</li> 10092 Prompt to accept Identity Server policies on registration</a> (done)</li> 10093 Prompt to accept identity server policies before inviting them to a room</a> (done)</li> 10094 Store identity server in Account Data and support choosing identity server integration in User Settings</a> (done)</li> 10159 Enable toggling a threepid's association with the current IS in User Settings</a> (done)</li> 10173 VoIP: Stop falling back to Google for STUN</a> (done)</li> 10216 We should make it clear in the UI that device names are publicly readable</a> (done)</li> 10386 Terms modal prompt should appear without a flash of the integration manager portal first</a> (done)</li> 10408 Identity server v2 API authentication</a> (done)</li> 10423 Deploy a develop environment for t's and c's flows for IM and IS</a> (done)</li> 10424 Remove the bind true flag from 3PID calls on registration</a> (done)</li> 10425 Ability to disconnect from the identity server by pressing buttons in user settings.</a> (done)</li> 10452 Test IS v2 access tokens for validity</a> (done)</li> 10497 Integration manager terms hides terms that need signing</a> (done)</li> 10510 Remove the bind true flag from 3PID adds in settings</a> (done)</li> 10519 Update discovery and account 3PID sections when either changes</a> (done)</li> 10522 Handle terms agreement in the Discovery section of settings</a> (done)</li> 10525 IS interactions proxied through the HS also need terms agreement</a> (done)</li> 10528 don't try & show threepids in discovery section if we don't have an ID server</a> (done)</li> 10539 Inline terms agreement on change IS and IM</a> (done)</li> 10540 When using Riot without an IS, identity requests are sent to server hosting Riot</a> (done)</li> 10546 Prompt for fallback VOIP should only happen when the user tries to make a call</a> (done)</li> 10550 warn when disconnecting ID server if there are any current bindings</a> (done)</li> 10552 Allow email registration, password reset & adding 3pids when no IS</a> (done)</li> 10553 Remove the ability to set an IS at login/registration</a> (done)</li> 10556 Use the hashed v2 lookup API for 3PIDs</a> (done)</li> 10561 Scalar should serve a .well-known file</a> (done)</li> 10566 Use nicer APIs for toggling a 3PID's shared status</a> (done)</li> 10571 Allow email registration when no IS</a> (done)</li> 10572 Allow password reset when no IS</a> (done)</li> 10573 Allow adding 3pids when no IS</a> (done)</li> 10574 Placeholder issue for MSCs that should land prior to the privacy release</a> (done)</li> 10593 Placeholder issue for privacy migration path</a> (done)</li> 10597 Ensure IS in account data is read / written as specced</a> (done)</li> 10599 Send IS for adding MSISDNs only when required by HS</a> (done)</li> 10603 Getting a terms prompt when inviting an email address clears the address picker</a> (done)</li> 10619 Handle the case of no IS in features that require IS to lookup</a> (done)</li> 10620 Change auth flows so that you default to no IS</a> (done)</li> 10634 Changing to vector.im IS in Settings fails because /terms 404s</a> (done)</li> 10635 Inline terms agreement in Discovery should still show change and do not use</a> (done)</li> 10636 The UX is a little confusing if you haven't accepted the terms of the default identity server.</a> (done)</li> 10637 Unable to add email address to HS account without IS set</a> (done)</li> 10660 Sydent implementation: Unauthed v1, clone all endpoints, auth v2</a> (done)</li> 10666 In login/register, riot freezes if you go to Advanced, remove the IS url and click next</a> (done)</li> 10669 Checking email invite account is unclear when no IS set</a> (done)</li> 10674 Email help text on registration should be updated without binding</a> (done)</li> 10677 Change text about other users being able to invite you by email on registration page</a> (done)</li> 10744 Only set terms URLs in the account when they change</a> (done)</li> 10749 Changing from one IS to another does not trigger bound 3PID warning</a> (done)</li> 10750 Bound 3PIDs warning should better explain what's being left behind</a> (done)</li> 10754 Lowercase emails during IS lookup calls</a> (done)</li> 10755 Terms account data is meant to be additive, but currently sets only new URLs</a> (done)</li> 10756 After changing IS to termstest.matrix.org the text field isn't cleared and the button remains active</a> (done)</li> 10757 After changing IS back to vector.im the text field isn't cleared and the button remains active</a> (done)</li> 10758 Revoke may be too vague for unbinding a 3PID</a> (done)</li> 10779 When publishing a threepid to an IS, if you click 'continue' before clicking the link in your email, we delete your threepid from the HS.</a> (done)</li> 10800 Community invite should not talk about ISes at all.</a> (done)</li> 10823 IS with unagreed terms will block you from adding even unshared 3PIDs to your HS</a> (done)</li> 10839 Use the new backend APIs for adding-3pid-to-homeserver and binding-3pid-on-identity-server when they exist.</a> (done)</li> 10878 UX regression when trying to invite by email if no IS is configured</a> (done)</li> 10883 Riot should check for r0.6.0 server support alongside feature flags</a> (done)</li> 10923 Send validation tokens to submit_url from HS</a> (done)</li> 10933 Do not include ID server or access token when HS supports MSC2290</a> (done)</li> 10939 Registration with MSISDN needs to use submit_url</a> (done)</li> 10941 threepid_creds for registration and password reset still include id_server</a> (done)</li> 10959 Remove id_server from email threepid_creds</a> (done)</li> 10604 QA: Re-test ALL of the identity server interactions</a> (in progress)</li> 10958 Terms of Service nitpicks</a> (in progress)</li> 10704 We treat an empty string identity server as not having one</a></li> </ul> </li> vector-im/riot-ios 2518 Make sure there are no ugly edge cases running Riot without an integrations manager</a> (done)</li> 2521 Privacy: Improve wording on contact upload UI</a> (done)</li> 2532 VoIP: Stop falling back to Google for STUN</a> (done)</li> 2600 Prompt to accept integration manager polices on use</a> (done)</li> 2601 Decouple setting an email for password reset from publishing your threepid to the identity server and support choice of identity server (on registration)</a> (done)</li> 2602 Prompt to accept identity server policies before inviting them to a room</a> (done)</li> 2603 Identity server v2 API authentication</a> (done)</li> 2606 Settings: Add a Discovery section</a> (done)</li> 2608 Registration: Update consents flow</a> (done)</li> 2643 Ability to disable all identity server functionality via the config file</a> (done)</li> 2646 VoIP: Fallback to matrix.org STUN server with a confirmation dialog</a> (done)</li> 2647 MXRestClient: Move IS API to its own</a> (done)</li> 2648 Remove the bind true flag from 3PID calls on registration</a> (done)</li> 2650 Remove the bind true flag from 3PID adds in settings</a> (done)</li> 2651 Store identity server in Account Data and support choosing identity server integration in User Settings</a> (done)</li> 2652 Use the hashed v2 lookup API for 3PIDs</a> (done)</li> 2653 Allow email registration, password reset & adding 3pids when no IS</a> (done)</li> 2654 Use nicer APIs for toggling a 3PID's shared status</a> (done)</li> 2657 Allow email registration when no IS</a> (done)</li> 2658 Allow password reset when no IS</a> (done)</li> 2659 Allow adding 3pids when no IS</a> (done)</li> 2660 Handle terms agreement in the Discovery section of settings</a> (done)</li> 2661 Remove the ability to set an IS at login/registration</a> (done)</li> 2662 We should make it clear in the UI that device names are publicly readable</a> (done)</li> 2664 Placeholder issue for privacy migration path</a> (done)</li> 2665 Ensure IS in account data is read / written as specced</a> (done)</li> 2672 Handle the case of no IS in features that require IS to lookup</a> (done)</li> 2675 Email help text on registration should be updated without binding</a> (done)</li> 2682 Send IS for adding MSISDNs only when required by HS</a> (done)</li> 2686 Use wellknown to discover the IS of a custom HS</a> (done)</li> 2696 Lowercase emails during IS lookup calls</a> (done)</li> 2704 Use id_access_token</code> in CS API when required</a> (done)</li> 2604 Settings: Ability to change the identity server</a> (in progress)</li> 2649 Ability to disconnect from the identity server by pressing buttons in user settings</a> (in progress)</li> 2713 Use the new backend APIs for adding-3pid-to-homeserver and binding-3pid-on-identity-server when they exist.</a> (in progress)</li> 2718 Riot should check for r0.6.0 server support alongside feature flags</a> (in progress)</li> 2683 Checking email invite account is unclear when no IS set</a></li> 2731 Send validation tokens to submit_url from HS</a></li> 2732 Do not include ID server or access token when HS supports MSC2290</a></li> 2736 IS terms cannot be accepted anymore</a></li> </ul> </li> vector-im/riot-android 3223 VoIP: Stop falling back to Google for STUN</a> (done)</li> 3224 Make sure there are no ugly edge cases running Riot without an integrations manager</a> (done)</li> 3225 Prompt to accept integration manager polices on use</a>(done)</li> 3226 Decouple setting an email for password reset from publishing your threepid to the identity server and support choice of identity server (on registration)</a> (done)</li> 3227 Prompt to accept identity server policies before inviting them to a room</a> (done)</li> 3228 Identity server v2 API authentication</a> (done)</li> 3229 Settings: Ability to change the identity server</a> (done)</li> 3230 Settings: Add a Discovery section</a> (done)</li> 3231 Registration: Update consents flow</a> (done)</li> 3252 Remove the bind true flag from 3PID calls on registration</a> (done)</li> 3253 Ability to disconnect from the identity server by pressing buttons in user settings</a> (done)</li> 3254 Remove the bind true flag from 3PID adds in settings</a> (done)</li> 3256 Store identity server in Account Data and support choosing identity server integration in User Settings</a> (done)</li> 3257 Use the hashed v2 lookup API for 3PIDs</a> (done)</li> 3258 Allow email registration, password reset & adding 3pids when no IS</a> (done)</li> 3260 Allow email registration when no IS</a> (done)</li> 3261 Allow password reset when no IS</a> (done)</li> 3262 Allow adding 3pids when no IS</a> (done)</li> 3263 Handle terms agreement in the Discovery section of settings</a> (done)</li> 3264 Remove the ability to set an IS at login/registration</a> (done)</li> 3265 We should make it clear in the UI that device names are publicly readable</a> (done)</li> 3268 Placeholder issue for privacy migration path</a> (done)</li> 3269 Ensure IS in account data is read / written as specced</a> (done)</li> 3277 Handle the case of no IS in features that require IS to lookup</a> (done)</li> 3278 Email help text on registration should be updated without binding</a> (done)</li> 3281 Send IS for adding MSISDNs only when required by HS</a> (done)</li> 3283 Use wellknown to discover the IS of a custom HS</a> (done)</li> 3289 Lowercase emails during IS lookup calls</a> (done)</li> 3295 Use id_access_token</code> in CS API when required</a> (done)</li> 3300 Use the new backend APIs for adding-3pid-to-homeserver and binding-3pid-on-identity-server when they exist.</a>(done)</li> 3312 Riot should check for r0.6.0 server support alongside feature flags</a> (done)</li> 3316 Implement MSC2290</a> (done)</li> 3324 id_server param sent when registering an email on server that does not requires one</a> (done)</li> 3326 Discovery Settings / infinite loading if terms not signed on existing IS</a> (done)</li> 3327 vector.im is seen as having no terms, but it does</a> (done)</li> 3251 VoIP: Fallback to matrix.org STUN server with a confirmation dialog</a> (in progress)</li> 3248 Ability to disable all identity server functionality via the config file</a></li> 3318 Send validation tokens to submit_url from HS</a></li> 3322 Do not include ID server or access token when HS supports MSC2290</a></li> </ul> </li> vector-im/riotX-android 490 Allow email registration, password reset & adding 3pids when no IS</a> (done)</li> 432 Prompt to accept integration manager polices on use</a> (in progress)</li> 431 Make sure there are no ugly edge cases running Riot without an integrations manager</a></li> 433 Decouple setting an email for password reset from publishing your threepid to the identity server and support choice of identity server (on registration)</a></li> 434 Prompt to accept identity server policies before inviting them to a room</a></li> 435 Identity server v2 API authentication</a></li> 436 Settings: Ability to change the identity server</a></li> 438 Settings: Add a Discovery section</a></li> 439 Registration: Update consents flow</a></li> 489 Use the hashed v2 lookup API for 3PIDs</a></li> </ul> </li> matrix-org/matrix-doc 1961 MSC1961: Integration manager authentication APIs</a> (done)</li> 2078 MSC2078: Sending Third-Party Request Tokens via the Homeserver</a> (done)</li> 2130 Identity service should do lookups based on hashed 3PIDs, not plaintext ones.</a> (done)</li> 2134 MSC2134: Identity Hash Lookups</a> (done)</li> 2139 Method for ISes and Integration managers to provide terms of service</a> (done)</li> 2140 MSC2140: Terms of Service for ISes and IMs</a> (done)</li> 2229 MSC2229: Allowing 3PID Owners to Rebind</a> (done)</li> 2230 MSC2230: Store Identity Server in Account Data</a> (done)</li> 2263 MSC2263: Give homeservers the ability to handle their own 3PID registrations/password resets</a> (done)</li> 2264 MSC2264: Add an unstable feature flag to MSC2140 for clients to detect support</a> (done)</li> 2290 MSC2290: Separate Endpoints for Threepid Binding</a> (in progress)</li> </ul> </li> matrix-org/sydent 178 Support for MSC2140</a> (done)</li> 179 Support testing with matrix-is-tester</a> (done)</li> 180 Support for MSC2140</a> (done)</li> 181 Deny bindings to anything other than the mxid you're authed as</a> (done)</li> 184 Hash 3PID lookups</a> (done)</li> 186 Don't fail the unbind request if the binding doesn't exist</a> (done)</li> 187 Add more tweaks to terms branch</a> (done)</li> 189 Redact looked-up threepids from the application logs.</a> (done)</li> 191 Add OpenID auth to 3PID hash lookup</a> (done)</li> 197 Have 'mappings' contain medium as well as address</a> (done)</li> 198 Throw exception on bad args & catch in wrapper</a> (done)</li> 199 Return algorithm, lookup_pepper in M_INVALID_PEPPER response</a> (done)</li> 200 Support MSC2140 register/terms endpoints</a> (done)</li> 201 Port v1 endpoints to v2</a> (done)</li> 202 Deny bindings to anything other than the mxid you're authed as</a> (done)</li> 204 Fix the signing servlet</a> (done)</li> 205 Correct API v1 path check in get_args</a> (done)</li> 206 Fix terms POST</a> (done)</li> 207 Deploy policy file</a> (done)</li> 208 Remove PII logging from log-level INFO</a> (done)</li> 213 Delete threepid assocs on unbind and remove existing with migration</a> (done)</li> 217 Allow non-matrix.org MXIDs via v2 only once terms are enabled</a> (done)</li> 218 Unbind fails to remove the binding on matrix.org IS</a> (done)</li> 220 Unbind fails to work for bindings where it was attempted with #213</a> (done)</li> 192 Sydent doesn't delete 3PIDs from DB on unbind</a> (in progress)</li> </ul> </li> matrix-org/synapse 1287 We need to actually censor redactions from the DB (SYN-284)</a> (done)</li> 5751 Make homeservers able to handle registration-with-email without depending on an Identity Server</a> (done)</li> 5786 Support IS v2 API with authentication for requests proxied to the IS</a> (done)</li> 5827 Add 3PID unbind API for MSC2140</a> (done)</li> 5835 [1/2] Allow homeservers to send registration emails | Sending the email</a> (done)</li> 5861 Use the v2 lookup API for 3PID invites</a> (done)</li> 5862 Allow account owners to rebind 3PIDs as in MSC2229</a> (done)</li> 5868 Add flag in /versions for whether clients should send id_server params</a> (done)</li> 5874 Placeholder issue for privacy migration path</a> (done)</li> 5875 Remove trusted_third_party_id_servers functionality</a> (done)</li> 5876 Replace trust_identity_server_for_password_resets with account_threepid_delegate</a> (done)</li> 5892 Switch to using v2 Identity Service APIs other than lookup (MSC 2140)</a> (done)</li> 5897 Use the v2 lookup API for 3PID invites</a> (done)</li> 5927 Add a m.id_access_token flag to unstable_features</a> (done)</li> 5928 Split account_threepid_handler into a msisdn and email versions</a> (done)</li> 5929 Use account_threepid_delegate for sending SMS</a> (done)</li> 5930 Add m.id_access_token flag</a> (done)</li> 5934 Censor redactions in DB after a month</a> (done)</li> 5935 Use federation blacklist for requests to identity servers</a> (done)</li> 5937 Revert "Use the v2 lookup API for 3PID invites"</a> (done)</li> 5940 [2/2] Allow homeservers to send registration emails | Accepting the verification</a> (done)</li> 5945 Revert "Add m.id_access_token flag"</a> (done)</li> 5948 Support v2 Identity Server APIs</a> (done)</li> 5964 Remove bind_email and bind_msisdn</a> (done)</li> 5968 Set m.require_identity_server to always be False</a> (done)</li> 5969 Change account_threepid_delegate to a dictionary</a> (done)</li> 5972 Add m.require_identity_server to /versions unstable_flags</a> (done)</li> 5974 Add m.id_access_token to /versions unstable_features (MSC2264)</a> (done)</li> 5976 Use the v2 Identity Service API for lookups (MSC2134 + MSC2140)</a> (done)</li> 5979 v2 3PID Invites (part of MSC2140)</a> (done)</li> 5980 Add POST /_matrix/client/r0/account/3pid/unbind (MSC2140)</a> (done)</li> 5987 Allow Synapse to send registration emails + choose Synapse or an external server to handle 3pid validation</a> (done)</li> 5996 Allow users to rebind 3pids they own (MSC2229)</a> (done)</li> 6000 Use the federation blacklist for requests to untrusted Identity Servers</a> (done)</li> 6011 Use account_threepid_delegate for 3pid validation</a> (done)</li> 6013 Fix existing v2 identity server calls (MSC2140)</a> (done)</li> 6042 Allow HS to send emails when adding an email to the HS</a> (done)</li> 6043 Implement MSC2290</a> (done)</li> 6044 Add an unstable feature flag for separate add/bind 3pid APIs</a> (done)</li> 6062 Use unstable prefix for 3PID unbind API</a> (done)</li> 6067 Drop support for bind param on POST /account/3pid (MSC2290)</a> (done)</li> 6076 Synapse doesn't give clients a submit_url on requestToken breaking msisdn adding</a> (done)</li> 6078 Add POST submit_token endpoint for MSISDN</a> (done)</li> 6079 Add submit_url response parameter to msisdn /requestToken</a> (done)</li> 6087 Remove hardcoded defaults of matrix.org and vector.im in configuration</a> (done)</li> 6090 Explicitly log when a homeserver does not have a trusted key server configured</a>(done)</li> 6096 Riot Web expects the email validation next_link to have the sid appended</a> (done)</li> 6100 Remove email from registration flows if it’s unsupported</a> (done)</li> 6103 _check_threepid in auth.py incorrect for MSISDN</a> (done)</li> 6045 Support Client-Server API r0.6.0</a> (in progress)</li> 1263 When we redact events, any mxc content they refer to should be redacted too (SYN-216)</a></li> 4565 Metadata resistance.</a></li> 6086 Fetch signing-keys directly from servers before falling back to the trusted_key_servers</a></li> </ul> </li> </ul> </li> phase:2 vector-im/riot-web 4913 Option for homeservers to set a default integration manager</a> (done)</li> 10161 Store Integration Manager preferences in account data and allow user to change them somewhere sensible</a> (done)</li> 10967 Disconnect from identity server fails</a> (done)</li> 10443 Remove v1 IS API fallbacks once servers are updated</a></li> 10557 Prompt users each time before sending data to an Identity Server that doesn't have a terms of service (unless you have actively set that IS in your account data).</a></li> 10696 Allow users to disconnect from an integration manager entirely in the same way that we support doing this for identity servers</a></li> 10909 Unable to disconnect from IS if the server is unavailable</a></li> 10936 Refine submit_url handling to only activate with separate add and bind</a></li> </ul> </li> vector-im/riot-ios 2711 Provide a better UX for users considering sharing their contact list with an IS to discover people they know already using Matrix</a></li> </ul> </li> vector-im/riot-android 3282 Checking email invite account is unclear when no IS set</a></li> 3323 Post MSC2290 bug / Clicking on the validation mail link fails registration</a></li> </ul> </li> matrix-org/matrix-doc 1957 MSC1957: Integration manager discovery</a> (done)</li> </ul> </li> matrix-org/sydent 196 Remove the lookup_hash field from local_threepid_associations</a> (in progress)</li> </ul> </li> matrix-org/synapse 5881 Remove trust_identity_server_for_password_resets and account_threepid_delegate options</a></li> </ul> </li> </ul> </li> phase:3 vector-im/riot-web 10563 Add better domain for turn.matrix.org use as STUN server</a> (done)</li> 10087 Prompt to accept integration manager policies on registration</a></li> 10167 Present an aggregated terms of service dialogue at registration if possible</a></li> 10168 If a user has disabled the identity server integration on their account, we should make invite user handle this nicely</a></li> 10401 Invite new users to publish their threepids to the identity server</a></li> 10422 Use more contextual prompt for integration manager polices on use</a></li> 10453 Log out from IM on Riot log out and IM removal</a></li> 10455 Log out from IS on Riot log out and IS removal</a></li> 10487 Store the date of users having read and accepted the IM policies in the IM db</a></li> 10488 Store the date of users having read and accepted the IS policies in the IS db</a></li> 10498 Terms test scalar requires the legacy ?v query param on the new account route</a></li> 10575 We should show the 'must configure TURN' warning when a call fails, even after using the fallback turn.matrix.org</a></li> 10615 Change all IS access token APIs to use getIdentityAccessToken only</a></li> 10671 riot submits sign-ed25519 requests as POST requests with params in query string and empty body</a></li> 10746 /invite doesn't force terms with older homeservers</a></li> 10830 Show IS policy links in user settings somewhere.</a></li> 10950 Unhelpful 400 error when adding MSISDN and server doesn’t delegate</a></li> </ul> </li> vector-im/riot-ios 2710 Show IS policy links in user settings somewhere.</a></li> </ul> </li> matrix-org/matrix-doc 447 We need a way to be able to expire data from a HS. (SPEC-141)</a></li> </ul> </li> matrix-org/synapse 5830 pushers</code> table contains user device names, which may include user real names</a></li> </ul> </li> </ul> </li> </ul> Publishing the Backend Roadmap 2019-02-15T00:00:00+00:00 Good people, 2019 is a big year for Matrix, in the next month we will have shipped: Matrix spec 1.0 (including the first stable release of the Server to Server Spec) </li> Synapse 1.0 </li> Riot 1.0 </li> </ul> This is huge in itself, but is really only the beginning, and now we want to grow the ecosystem as quickly as possible. This means landing a mix of new features, enhancing existing ones, some big performance improvements as well as generally making life easier for our regular users, homeserver admins and community developers. Today we are sharing the Matrix core team's backend roadmap. The idea is that this will make it easier for anyone to understand where the project is going, what we consider to be important, and why. To see the roadmap in its full glory, take a look here</a>. 🔗</a>What is a roadmap and why is it valuable?</h3> A roadmap is a set of high level projects that the team intend to work on and a rough sense of the relative priority. It is essential to focus on specific goals, which inevitably means consciously not working on other initiatives. Our roadmap is not a delivery plan - there are explicitly no dates. The reason for this is that we know that other projects will emerge, developers will be needed to support other urgent initiatives, matrix.org use continues to grow exponentially and will require performance tweaking. So simply, based on what we know now, this is the order we will work on our projects. 🔗</a>Why are we sharing it?</h3> We already share our day to day todo list</a>, and of course our commit history, but it can be difficult for a casual observer to see the bigger picture from such granular data. The purpose of sharing is that we want anyone from the community to understand where our priorities lie. We are often asked ‘Why are you not working on X, it is really important' where the answer is often ‘We agree that X is really important, but A, B and C are more important and must come first'. The point of sharing the roadmap is to make that priority trade off more transparent and consumable. 🔗</a>How did we build it?</h3> The core contributors to Synapse and Dendrite are 6 people, of 5 nationalities spread across 3 locations. After shipping the r0 release of the Server to Server spec</a> last month we took some time to step back and have a think about what to do after Synapse 1.0 lands. This meant getting everyone in one place to talk it through. We also had Ben (benpa) contribute from a community perspective and took input from speaking to so many of you at FOSDEM. In the end we filled a wall with post-its, each post-it representing a sizeable project. The position of the post-it was significant in that the vertical axis being a sense of how valuable we thought the task would be, and the horizontal axis being a rough guess on how complex we considered it to be. We found this sort of grid approach to be really helpful in determining relative priority. After many hours and plenty of blood, sweat and tears we ended up with something we could live with and wrote it up in the shared board</a>. </a></a> 🔗</a>And this is written in blood right?</h3> Not at all (it's written in board marker). This is simply a way to express our plan of action and we are likely to make changes to it dynamically. However, this means that at any given moment, if someone wants to know what we are working on then the roadmap is the place to go. 🔗</a>But wait I want to know more!</h3> Here is a video of myself and Matthew to talk you through the projects

🔗</a>Reports</h3>
I found mypy's various reports</a> to be a better approach here. There were three reports I found particularly useful.</p>

🔗</a>But wait I want to know more!</h3>
Here is a video of myself and Matthew to talk you through the projects</p>

Matrix.org - Tech

Authentication changes on Matrix.org

Sunsetting the Sliding Sync Proxy: Moving to Native Support

Type coverage for Sydent: evaluation

Type coverage for Sydent: annotation

Type coverage for Sydent: motivation

How the UK's Online Safety Bill threatens Matrix

The Matrix Space Beta!

Introducing the Pinecone overlay network

Privacy improvements in Synapse 1.4 and Riot 1.4

Publishing the Backend Roadmap

Matrix.org - Tech

Authentication changes on Matrix.org

Sunsetting the Sliding Sync Proxy: Moving to Native Support

Type coverage for Sydent: evaluation

🔗</a>The meaning of precision</h3> There are two metrics I chose to focus on:</p> the proportion of "imprecise" lines across the project; I also used the complement, precision = 100% - imprecision</code>, and</li>

🔗</a>Pyre</a> (Facebook)</h4> I couldn't work out how to configure paths to resolve import errors; in the end, I wasn't able to process much of Sydent's source code.</li>

🔗</a>Pytype</a> (Google)</h4> Google internal? Seems to be maintained by one person semiregularly by "syncing" from Google.</li>

Type coverage for Sydent: annotation

Type coverage for Sydent: motivation

How the UK's Online Safety Bill threatens Matrix

The Matrix Space Beta!

Introducing the Pinecone overlay network

Privacy improvements in Synapse 1.4 and Riot 1.4

Publishing the Backend Roadmap