From d73e57058b88230f6fd0a8f6cd9f90ebf27f4c33 Mon Sep 17 00:00:00 2001 From: Neil Alexander Date: Wed, 5 Jan 2022 15:06:58 +0000 Subject: [PATCH] Update wording around "receiving homeservers" --- proposals/3618-simplify-federation-send.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/proposals/3618-simplify-federation-send.md b/proposals/3618-simplify-federation-send.md index cba69d08f..ab2641b61 100644 --- a/proposals/3618-simplify-federation-send.md +++ b/proposals/3618-simplify-federation-send.md @@ -46,16 +46,16 @@ per the spec: > The sending server must wait and retry for a 200 OK response before sending a > transaction with a different txnId to the receiving server. -With this proposal, blocking becomes optional rather than required. Servers that do not -want to durably persist transactions before processing them can continue to perform all -work in-memory by continuing to block on `/send` as is done today. Additionally, a server -that is receiving too many transactions from a given homeserver may wish to block for -an arbitrary period of time for rate-limiting purposes, but this is not necessarily -required. - -Another benefit is that homeservers no longer need to parse the response body at -all and can instead just determine whether the transaction was accepted successfully -by the HTTP status code. +With this proposal, blocking becomes optional rather than required. Receiving servers that +do not want to durably persist transactions before processing them can continue to perform +all work in-memory by continuing to block on `/send` as is done today. Additionally, a +receiving server that is receiving too many transactions from a remote homeserver may wish to +block for an arbitrary period of time for rate-limiting purposes, but this is an implementation +specific detail and not strictly required. + +Another benefit is that sending homeservers no longer need to parse the response body at +all and can instead just determine whether the transaction was accepted successfully by +observing the HTTP status code. ## Potential issues