@mononym Yes, essentially. A federated room is not stored only on the homeserver where it was created. Each homeserver with participating users receives and stores its own copy of the room events for its local members. The originating server is not a central or authoritative host for the room.
A newly joining homeserver does not necessarily receive every historical event immediately, but it can request available history from other participating servers, subject to the room's history visibility and federation rules.
Therefore, Synapse retention is not a remote-delete mechanism. Your default_policy controls only what your own homeserver serves to clients and eventually keeps in its database. If matrix.org, or another participating homeserver, does not enforce equivalent retention, it may retain its own copy of the history. In an encrypted room that copy is ciphertext, but clients that still have the encryption keys may be able to decrypt it.
A room-level m.room.retention state event is federated and can communicate the intended policy to participating servers, but enforcement still depends on each homeserver supporting and honoring it. It should not be treated as a guarantee that every copy disappears everywhere.
Small correction to my previous reply: current Synapse versions use a default purge-job configuration when retention is enabled and no explicit purge_jobs section is provided. Adding purge_jobs is useful when you want to control the purge interval, but it is not strictly required.
