XSF Discussion - 2018-09-04

Link Mauve do we have something like "public bookmarks" in XMPP ?

Like a shared PEP node? I don't think there's any client support for that, nor spec, but you can already change the acces-model/publish-options of your storage:bookmarks node :x

XEP-xxxx: MUC Avatars, how much XEP do we need to handle avatars on XMPP ?

do I need to also create one to handle avatars on Pubsub nodes ?

this is again another flow to handle/update/notify avatars

edhelas, how close is what you do for pubsub nodes to what that XEP does for MUC?

I don't do avatars on Pubsub nodes for now because I didn't found a way to do it yet

(also vcards)

maybe we can simply generalize that XEP, say that publication/retrieval is always done the same way (for JID, MUC JID and Pubsub Nodes) and the notification can be done through presences (for the JID), messages/presences for the MUC JID, and Pubsub healines for the Pubsub nodes

then we have an unique and generic way to handle vcard and avatars publication/retrieval accross the XMPP network

Good luck

Pubsub nodes don't have PEP, is one problem

yes

and it's kind of hacked by putting those "pubsub pep nodes" next to eachother : MIX

Hello!

Do we have a way to retrieve history from a transport?

Yes, XEP-0313 if the transport supports it

MattJ, so, once my client discover that transport supports MAM, I can request an archive for any of my chats via that transport?

Yagiza, that is how I would expect it to work

Normal chats will typically be archived by your server already

But group chats, yes, you will need to ask the transport

MattJ, normal chats could not be archived before I logged on the transport.

True

MattJ, so, what about requesting that parts of chat?

It depends completely on the transport

“10:35:47 edhelas> XEP-xxxx: MUC Avatars, how much XEP do we need to handle avatars on XMPP ?”, this one is almost informational (I hesitated), it describes how to do 0153 on 0045.

“10:36:07 edhelas> do I need to also create one to handle avatars on Pubsub nodes ?”, isn’t that 0084?

Ah, avatars for PubSub nodes*.

MattJ, I mean the correct way to retrieve history. How client should act?

I'm not aware of any transport providing this functionality, so I can't say

MattJ, but if I develop a transport, I need to know if this functionality is valid for a transport, or not.

MattJ, I guess it must be specified implicitly.

XEP-0313 defines a protocol for exchanging history between two XMPP entities

Usually this is a user and their own server, or a user and a MUC room

but a user and a transport is just fine too

However clients won't currently do this, so you may want to add a XEP for that

So the protocol is the easiest problem, that's 99% solved with XEP-0313

But implementations do not query transports, because transports today don't offer this ability (except for groupchats)

So implementations would need to add support for this, even if they already support XEP-0313 in other ways

so you need to get friendly with client developers :)

the proper fix would be if the transport sent messages to the account even if no client is online

I understood the problem to be access to messages before registering with the transport

MattJ, the problem is what to do if both transport and user's server do support XEP-0313.

Yagiza, the client can either request both, or assume one is the only source of truth.

Deduplication might be harder in the first case though, because stanza-ids will be different.

Link Mauve, yes. So all those issues must be clarified in the XEP.

The XEP only defines the protocol to retrieve history from another entity.

You can write another one (informational) about what to do with transports.

Link Mauve, yes. But at least, mention of transports in Archiving Entities( https://xmpp.org/extensions/xep-0313.html#archiving_entities ) should be added.

Yagiza, sure.