From eb3870ccce6333f61235448c1f0968a892cd3a1c Mon Sep 17 00:00:00 2001 From: Dave Cridland Date: Thu, 28 Jan 2016 11:30:11 +0100 Subject: [PATCH] summit notes --- inbox/pubsub-account.xml | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/inbox/pubsub-account.xml b/inbox/pubsub-account.xml index fd45a4be..eac589fe 100644 --- a/inbox/pubsub-account.xml +++ b/inbox/pubsub-account.xml @@ -36,7 +36,7 @@

The XMPP way is to have "disposable", or at least easily substituted, clients, maintaining long-term state on the server, and allowing it to be synchronized between clients. In particular, this can be seen on how the roster and presence fan-out operate - clients defer the operation of such things to the server, which manages the shared state and allows servers to access and manipulate it.

-

Historically, however, we hav enot done this for some more recently services, including Multi User Chat and PubSub. In both cases, different clients may be unaware of what chatrooms (etc) are joined (etc) by which other clients. This causes practical difficulty in seamlessly switching between devices and/or clients.

+

Historically, however, we have not done this for some more recently services, including Multi User Chat and PubSub. In both cases, different clients may be unaware of what chatrooms (etc) are joined (etc) by which other clients. This causes practical difficulty in seamlessly switching between devices and/or clients.

 @@ -58,6 +58,12 @@
  • Further, it needs to be able to tell if new subscriptions have been added, or old ones removed.

    •  + +

      +
    • A one-way subscription to a user should still allow PEP.
      • +
    • PEP should work the same way as now - users see filtered notifications about the things they care about.
      • +

    +     @@ -77,12 +83,13 @@

    XEP-0237 FTW. Needs a new construct, since the subscriptions element in XEP-0060ยง5.6 will only list the user's local subscriptions (ie, to their PEP nodes). Maybe just the new namespace defaults to everything instead? But we'd still need the XEP-0237 model.

     -

    Servers need to subscribe to remote PEP services with a "mask" containing those nodes which are of interest. Interest needs to be detirmined by the client issuing a request; but this implies that servers would gradually acrue any node type which the user has had a capable client at any time.

    +

    Servers need to subscribe to remote PEP services explicitly those nodes which are of interest. Interest needs to be detirmined by the client issuing a request; but this implies that servers would gradually acrue any node type which the user has had a capable client at any time.

    Perhaps timing out node types which have not been requested for over a certain period?

    -

    For legacy remote PEP services, the server needs to inject +notify caps into the presence.

    -

    The server also needs to remove +notify caps from legacy clients and spoof traffic?

    -

    Probably use this to handle point 2 in Device Agility, too.

    -

    TL;DR: Clients explicitly request a set of nodes (but not domains) that are of interest. I'm calling this the "mask".

    +

    Clients can use +notify to handle auto-subscriptions between clients and their server.

    +

    Servers receiving +notify from accounts known to support this protocol ignore them.

    +     + +

    Clients filter subscriptions using a specific stanza (iq, probably), containing a list of nodes. This can be used instead of the odler +notify (which is broadcast).

    We probably want to say that events are now archived by MAM, but this may imply that clients need to filter out such events (or explicitly include them). Maybe the mask above affects MAM queries?