Summary

  • The MIMI protocol draft, revision 07, updated 2 November 2026, is active working-group work. Section 5.10 describes encrypted attachments stored outside the message, with an HTTPS download URL carried in a content ExternalPart.
  • A direct download exposes the client's IP address and request timing to the asset host. A hub proxy hides that address from the host and hub, but the receiving provider can still associate the URL with its user and infer which room carried it.
  • An Oblivious HTTP relay and gateway split the view again. The draft requires a hub gateway and recommends relay support at other providers; its stated benefit here is keeping every asset-provider domain out of the downloading provider's direct view.

Picture a group chat spanning three services. One member sends a photograph as an encrypted asset, and the message contains its HTTPS retrieval address. A recipient taps the image. The photo remains encrypted in storage, but the act of fetching it produces a time, a destination and a request path. Which company can connect that event to the recipient or room depends on the route chosen for the download. The protocol can protect the file while leaving a map of who reached for it.

RFC 9420 supplies Messaging Layer Security for group messages. The MIMI draft builds a federation path around such messages and treats attached assets as separate encrypted objects. Its companion room-policy draft governs allowed asset locations through asset_policy. This is an operating choice, not a cosmetic preference: the storage domain determines which other service receives a request and what it can observe.

The shortest route tells the host the most

The first route is a direct client download from the asset host. The draft says that host sees the recipient's IP address and the time of the request. Repeated downloads of the same asset can help it infer which clients share a room or when they are online. For cross-provider retrieval the draft labels this route NOT RECOMMENDED. The file's ciphertext does its job; the network transaction still reveals a pattern. A sender's service that stores attachments can learn about recipients from other services if every reader fetches directly.

The second route puts the receiving provider and the room hub in front of the asset host. The receiving provider calls GET /proxyDownload/{downloadUrl} at the hub; the hub fetches the encrypted object from the host. The host sees the hub rather than the recipient's address. The hub also does not receive the client's IP as the origin of that fetch. It sees which provider asked for a URL, but the request carries neither a room identifier nor the individual requester. That is a real reduction in what the host and hub learn in one request.

The downloading provider has a different vantage point. It serves the recipient and knows the URL being requested. The draft says it can correlate URLs with users and infer which URLs were sent in which rooms. It can also compare the timing of room-associated incoming messages with outgoing proxy requests. Caching at the provider or hub can make that matching harder by aggregating or delaying requests. The draft requires hubs to implement the proxy, and it requires the hub to check that the target host matches a configured asset-server domain of a peer provider.

Without that check, a convenient attachment relay could become an open proxy to arbitrary hosts.

OHTTP moves the knowledge, then someone must operate it

The third route wraps the client's request in Oblivious HTTP. A relay at the receiving provider passes the encrypted request to the hub's gateway. The gateway opens the target and fetches the asset. RFC 9458 defines the split: the relay sees the client-facing connection but not the protected target request; the gateway sees the target request without the original client connection when the roles remain separated. MIMI requires the hub to implement the gateway and recommends that other providers offer a relay. The hub must restrict gateway targets to configured asset locations of its peers.

The MIMI draft identifies a specific payoff: the receiving provider no longer learns every asset-provider domain from its user's downloads. The gateway still needs the target to fetch the object. The provider still sees its user using a relay at a given time. Network timing and shared operating control can reconnect views that the protocol separates on paper. The useful operational question is not whether a label says “private”; it is which organisation runs each role, where logs persist, and whether the same administrator can join them.

The draft contains no measured rate at which hosts or providers can infer room membership. A controlled test would send known assets through direct, hub-proxy and OHTTP paths, with caches both on and off, then compare the logs available to each actor. That would show what the chosen deployment reveals. The design decision is already visible: encrypting the attachment protects its contents; the download architecture decides who receives the guest list. A service promising private cross-provider files should name that architecture before inviting the first click.

MIMI draft · RFC 9458 · RFC 9420 · MIMI room policy