MSC4248: Pull-based presence #4248
Conversation
turt2live
added
proposal
There was a problem hiding this comment.
I wonder if we could instead have servers signal that they don't want presence updates (for those that turn it off), as well as not sending presence to servers we haven't recently interacted with (ie. we dont have a message in the last 50 messages in a room's timeline).
I worry that making it pull based would ruin performance as you'll be dealing with large incomming (continuous) request volume rather than the spurious outgoing burst.
There was a problem hiding this comment.
For synapse, it might be worthwhile to limit outgoing presence to the result of select * from destinations where failure_ts is null;? (AKA servers we know are online)
There was a problem hiding this comment.
In this model, servers can respond with 403 to indicate that they do not federate their presence, and remote servers should not request it again (at least, for a very long time). This voids the need for indicating in the first place.
As for the performance, the requests would not be continuous. Servers would configure how often they request presence, how long it's cached locally for, etc etc, and as such would distribute the requests over time.
That "spurious outgoing burst" is more like a constant flat line for lower-end servers (often single-user or cloud-based) since they will be continuously sending presence updates to potentially tens of thousands of other servers, most of which will not be interested in the slightest. This is, as is noted, a waste of bandwidth, cpu, and other resources, meaning it's usually futile for lower-end/smaller servers to enable it, and just a waste of resources for higher end/larger servers.
At least with a pull-based model, the ability to bulk-fetch presence would be much ligher on the origin server than constantly hammering out new EDUs, especially when the homeserver can return down to an empty object when there's been no presence changes.
I'm yet to have a chance to means test anything similar to this, but I know that my servers can handle hundreds of thousands of inbound federation requests per minute just fine, I'm sure a few thousand extra presence requests would be of no harm (compared to the literally devastating effects of sending out thousands of EDUs instead)
There was a problem hiding this comment.
For synapse, it might be worthwhile to limit outgoing presence to the result of
select * from destinations where failure_ts is null;? (AKA servers we know are online)
This could indeed be an optimisation, but then what about when dead servers come back? They have then missed out on the previous presence by nature of EDUs. Pull-based presence would mean they can request it when they come back and have the most up-to-date presence immediately, rather than needing to wait for the next presence update.
There was a problem hiding this comment.
What about dead servers commig back
Wouldn't this be solved by them being marked as online when they process a new PDU?
Additionally, load distribution wise, presence doesn't need to be sent immediately, you could have a background task that does a small amount of concurrent pushing (ie. try 10 servers at a time), instead of trying to send it to all servers all at once?
There was a problem hiding this comment.
The "small background task" doesn't scale in any sort of desirable way here, and if we're scheduling outgoing sending, what's the point of even having the EDU anyway? because at that point, there's even less sense of urgency regarding keeping presence up to date.
|
Heard some very good arguments for both EDU and pull presence so I'm going to rework this MSC so that EDU presence compliments pull-based presence (or vice versa, whichever floats your boat) rather than pbp replacing EDUs. |
This alternative has a lot of privacy implications and would only further exacerbate the frequent complaint regarding membership updates in the timeline (i.e. "Why are avatar changes always sent to every room individually")
Rendered