Timestamp massaging for application services

[turt2live]

This needs a bit of thought before it can safely be in the spec. The intention behind timestamp massaging is that appservices can bridge in old history for a network into matrix seamlessly. The ?ts param is meant to apply to every endpoint that sends an event, such as /send, /ban, and /createRoom. the last one in that list, /createRoom, causes some problems though: the ?ts param seems too blunt to apply to all of the events in the request.

In addition, the section needs some work in terms of wording to reference that the ?ts param does not affect DAG ordering.

For reference, here's the original section: https://github.com/matrix-org/matrix-doc/blob/17e0ef4b91034b0cdb010416225ffac65b4107fc/specification/application_service_api.rst#232timestamp-massaging

[turt2live]

See also: #1394 (closed in favour of this)

[turt2live]

Duplicate of https://github.com/matrix-org/matrix-doc/issues/698

[martindale]

What's the current path to leveraging this feature?

[turt2live]

Synapse implements it and is considered an easter egg. A proper proposal is needed to have it land in the spec due to the concerns outlined here.

[Half-Shot]

Possibly not a duplicate of matrix-org/matrix-spec#193, as that issue is explictly about lazy backfilling history (solved via another feature/proposal). This issue is about setting a timestamp for events being sent into a room live (e.g. I want to set the true timestamp of an event arriving over the bridge). As such, this should probably be reopened @turt2live.

As it stands, #3316 is aiming to solve this.

[turt2live]

I'm not really understanding the nuance there, but it sounds like it's covered by MSCs so this doesn't need to be open.