You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Synapse 0.27 includes the ability for appservices to do timestamp massaging, meaning that they can post messages that appear to be significantly in the past. This can (and should) be used in a few major ways:
Backfill room history for every puppetted room. For example, if a new version of a puppet bridge suddenly gains support for images, the next time it's run it should insert all messages that were previously sent and received in all rooms that it was unable to decode.
Delete messages that weren't ever sent to the other network. Right now it's possible to send messages to a pupppetted room and have them not go out to the network (if the bridge is offline, for example). Messages on matrix that weren't sent to the other network should be deleted if it's beyond a couple minutes (or possibly less, depending on what other people think).
The combination of these two should ensure that even if a bridge is restarted or goes down, at no point does the room history fall out of sync with the definitive copy on the other network.
The text was updated successfully, but these errors were encountered:
Synapse 0.27 includes the ability for appservices to do timestamp massaging, meaning that they can post messages that appear to be significantly in the past. This can (and should) be used in a few major ways:
Backfill room history for every puppetted room. For example, if a new version of a puppet bridge suddenly gains support for images, the next time it's run it should insert all messages that were previously sent and received in all rooms that it was unable to decode.
Delete messages that weren't ever sent to the other network. Right now it's possible to send messages to a pupppetted room and have them not go out to the network (if the bridge is offline, for example). Messages on matrix that weren't sent to the other network should be deleted if it's beyond a couple minutes (or possibly less, depending on what other people think).
The combination of these two should ensure that even if a bridge is restarted or goes down, at no point does the room history fall out of sync with the definitive copy on the other network.
The text was updated successfully, but these errors were encountered: