Specifications about state storage in the scope

On Starlette, we store a lot of information on the scope. Outside the extensions scope key. See our auditing: https://github.com/encode/starlette/discussions/1511.

Also, right now I’m writing a documentation on how to write “pure ASGI middlewares” on Starlette: https://github.com/encode/starlette/pull/1656. And a topic related to this appeared: “how should we store context in the scope”?

Should we just use any custom key? If yes, should we add it to the specifications? If no, is extensions the right key? It doesn’t look like, as it seems, that we only use extensions if the ASGI server is participating.

In summary, how should we instruct our users about this topic?

cc @florimondmanca @tomchristie

[andrewgodwin]

I had always envisaged the scope as something that was just opaquely passed down through each layer - the schema says what keys you can expect to find in it, but doesn’t say that it should not have any others.

However, in the interests of not name-colliding with future scope items, it may be prudent to place all application scope and data under one specific key? Maybe private, or something like that?

[adriangb]

I’d suggest using top-level keys: it’s much easier to propagate / copy the dict if you can do a shallow copy instead of having to be aware of nested data structures to copy. So I would suggest a structure like {"starlette.router": ...} instead of {"starlette": {"router": ...}}.

The main con to this is that it’s harder to make a TypedDict describing the framework specific state.