[Standards] MIX-PAM: private PEP node for joined channels

Jonas Schäfer jonas at wielicki.name
Mon Dec 9 10:09:49 UTC 2019

This is a length response. Table of contents:

1. Current state of archiving in PEP
2. Argument in favour of custom IQ-based wire protocol

On Donnerstag, 21. November 2019 21:20:30 CET Linus Jahn wrote:
> On Thu, 21 Nov 2019 11:51:11 +0100 Holger Weiß <holger at zedat.fu-berlin.de> 
> > * Daniel Gultsch <daniel at gultsch.de> [2019-11-20 21:49]:
> > > Am Mi., 20. Nov. 2019 um 20:45 Uhr schrieb Linus Jahn
> > > 
> > > <lnj at kaidan.im>:
> > > > Also the 'blocking command' way isn't so flexible. Ideally I
> > > > would like to send one request to the server to receive all
> > > > updates of all of my implicitly subscribed nodes after logging
> > > > in. (I'm not entirely sure whether this is currently possible
> > > > with PEP and MAM though?)
> > > 
> > > "Give me the delta" is currently not (properly?) specified in
> > > PubSub.
> > 
> > There's XEP-0312 (PubSub Since), but that's timestamp-based.
> > 
> > I guess you wouldn't want to base queries on item IDs, as items may be
> > overwritten.  So maybe you'd want PubSub-MAM indeed?  Or just make
> > sure notifications end up in the user archive?
> > 
> > Holger
> How is archiving currently working with other PEP nodes?
> I can't image that a client has to e.g. load all avatar metadata (User
> Avatar) from all contacts at login to not miss updates that happened while
> it was offline.

1. Current state of archiving in PEP

It does not have to, but the crucial difference is that avatar metadata is 
only a single item.

You get a notification of the last published item when you come online (if you 
subscribe to that using XEP-0115), but you may not get notifications of all 
items which were published while your client was offline. This is handled by 
the PEP service itself.

The delta transmission can not be initiated by the PEP service itself; the PEP 
service can, in general, not recognize your client (since your resource may 
change), and it probably also doesn’t want to store the last known state of 
every client forever. In addition, in face of s2s outages or otherwise lost 
stanzas, this would be error-prone and fragile.

So the state transfer must be initiated by the client (with the client telling 
whichever entity keeps the history what its last state was). This is like 
roster versioning.

This could be via a MAM archive which holds the notifications of the PubSub 
node (either the user’s archive, but see what Holger said, or an archive on 
the PEP node itself, which is unheard of so far, as far as I know). Note 
however that MAM silently treats the case of "the last stanza you saw expired 
from the archive" as "fetch everything since beginning of archives", which 
means you won’t notice that you lost notifications when using MAM (with 
expiry) for sync.

2. Argument in favour of custom IQ-based wire protocol

I think what Daniel says is sound. I also think that we don’t have to solve 
versioning *right now*. We should provision this, by adding a `ver` attribute 
with the following (initial semantics):

- Clients MUST NOT set the attriubte. Servers MUST ignore the attribute if set 
and send the full roster list. Clients MUST NOT rely on this server behaviour, 
as it may be changed in the future.
- Servers SHOULD NOT set the ver attribute. Clients MUST ignore the ver 
attribute if it is set.

This wording should allow us to add roster versioning-like semantics on top of 
this without requiring a namespace bump.

Note that we’re only talking about wire format here. Wire format is cheap. 
Implementations are not.

If a server chooses to implement all of this with a hidden PEP-like node with 
MAM backing and later implement the versioning stuff by querying the MAM 
archive using the ver value, so be it. There is no reason why they should not 
be able to re-use those facilities; the only thing which changes is how the 
abstract data and events are serialised on the wire.

And I’d argue that using a separate wire format is the right thing because it 
helps to immediately trigger the right subsystem, as special handling of all 
commands related to this magic PEP node would be required.

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191209/51e22f76/attachment.sig>

More information about the Standards mailing list