From e7aed3da269387a28ed43b79c9d3eef66436845c Mon Sep 17 00:00:00 2001
From: Travis Ralston <travpc@gmail.com>
Date: Fri, 17 Aug 2018 09:16:39 -0600
Subject: [PATCH] Remove poll/unpoll from presence

---
 .../definitions/event-schemas/m.presence.yaml | 31 +------------------
 specification/server_server_api.rst           |  8 +----
 2 files changed, 2 insertions(+), 37 deletions(-)

diff --git a/api/server-server/definitions/event-schemas/m.presence.yaml b/api/server-server/definitions/event-schemas/m.presence.yaml
index bebf8211..6d83b967 100644
--- a/api/server-server/definitions/event-schemas/m.presence.yaml
+++ b/api/server-server/definitions/event-schemas/m.presence.yaml
@@ -16,8 +16,6 @@ type: object
 title: Presence EDU
 description: |-
   An EDU representing presence updates for users of the sending homeserver.
-  Can also be used to request additional presence updates for users of the
-  receiving homeserver.
 allOf:
   - $ref: ../edu.yaml
   - type: object
@@ -35,7 +33,7 @@ allOf:
             type: array
             description: |-
               A list of presence updates that the receiving server is likely
-              to be interested in, or is subscribed to.
+              to be interested in.
             items:
               type: object
               title: User Presence Update
@@ -67,31 +65,4 @@ allOf:
                     Defaults to false.
                   example: true
               required: ['user_id', 'presence', 'last_active_ago']
-          poll:
-            type: array
-            description: |-
-              New user IDs that the sending server would like to subscribe to the
-              presence of. The sending server should not include users it has already
-              requested to be subscribed to.
-
-              The receiving server should ensure the sending server has reasonable
-              interest in subscribing to the provided users. The receiver may ignore 
-              a request to subscribe to a user the sender does not have reasonable
-              interest in. Reasonable interest may be residing in a room with the user,
-              being subscribed to a presence list, or some other requirement.
-
-              If non-empty, the receiving server should immediately send the presence
-              updates to the sender for the users requested.
-            items:
-              type: string
-            example: ["@alice:elsewhere.org"]
-          unpoll:
-            type: array
-            description: |-
-              New user IDs the sending server is no longer interested in receiving
-              presence updates for. The sending server should not include users it
-              has previously requested to be unsubscribed from.
-            items:
-              type: string
-            example: ["@bob:elsewhere.org"]
         required: ['push']
diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst
index d5177a04..6cc04d95 100644
--- a/specification/server_server_api.rst
+++ b/specification/server_server_api.rst
@@ -841,13 +841,7 @@ EDUs. There are no PDUs or Federation Queries involved.
 Servers should only send presence updates for users that the receiving server
 would be interested in. This can include the receiving server sharing a room
 with a given user, or a user on the receiving server has added one of the 
-sending server's users to their presence list. 
-
-Servers may also request additional users by including them in the ``poll``
-array on an ``m.presence`` update. The receiving server may ignore users
-requested in this array. The receiving server should maintain a list of
-subscribed users for the sending server, which is appended to by the ``poll``
-array and deleted from by the ``unpoll`` array.
+sending server's users to their presence list.
 
 .. TODO-doc
   - Explain the timing-based round-trip reduction mechanism for presence