moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-28 12:12:22 -05:00
Code Issues Releases Wiki Activity

summit notes

Browse Source
This commit is contained in:
Dave Cridland 2016-01-28 11:30:11 +01:00
parent 86c58f6a39
commit eb3870ccce
1 changed files with 13 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
inbox/pubsub-account.xml
View File

@ -36,7 +36,7 @@
</header> </header>
<section1 topic='Introduction'> <section1 topic='Introduction'>
<p>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.</p> <p>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.</p>
<p>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.</p> <p>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.</p>
</section1> </section1>
<section1 topic='User Stories' anchor='stories'> <section1 topic='User Stories' anchor='stories'>
<section2 topic='Device Agility'> <section2 topic='Device Agility'>
@ -58,6 +58,12 @@
<li>Further, it needs to be able to tell if new subscriptions have been added, or old ones removed.</li> <li>Further, it needs to be able to tell if new subscriptions have been added, or old ones removed.</li>
</ul></p> </ul></p>
</section2> </section2>
<section2 topic='PEP'>
<p><ul>
<li>A one-way subscription to a user should still allow PEP.</li>
<li>PEP should work the same way as now - users see filtered notifications about the things they care about.</li>
</ul></p>
</section2>
</section1> </section1>
<section1 topic='Protocol' anchor='protocol'> <section1 topic='Protocol' anchor='protocol'>
<section2 topic='Advertising Support' anchor='disco'> <section2 topic='Advertising Support' anchor='disco'>
@ -77,12 +83,13 @@
<p>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.</p> <p>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.</p>
</section2> </section2>
<section2 topic='Auto Subscriptions' anchor='autosub'> <section2 topic='Auto Subscriptions' anchor='autosub'>
<p>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.</p> <p>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.</p>
<p>Perhaps timing out node types which have not been requested for over a certain period?</p> <p>Perhaps timing out node types which have not been requested for over a certain period?</p>
<p>For legacy remote PEP services, the server needs to inject +notify caps into the presence.</p> <p>Clients can use +notify to handle auto-subscriptions between clients and their server.</p>
<p>The server also needs to remove +notify caps from legacy clients and spoof traffic?</p> <p>Servers receiving +notify from accounts known to support this protocol ignore them.</p>
<p>Probably use this to handle point 2 in Device Agility, too.</p> </section2>
<p>TL;DR: Clients explicitly request a set of nodes (but not domains) that are of interest. I'm calling this the "mask".</p> <section2 topic='Filtering' anchor='filter'>
<p>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).</p>
</section2> </section2>
<section2 topic='Interaction with MAM' anchor='mam'> <section2 topic='Interaction with MAM' anchor='mam'>
<p>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?</p> <p>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?</p>