[Standards] feedback on file sharing with XMPP [XEP-0135] [XEP-0214] [XEP-0234] [XEP-0329]

Goffi goffi at goffi.org
Tue Feb 20 06:46:16 UTC 2018

Hello here,

I'm currently implementing file sharing over XMPP, and I thought a feedback 
could be interesting.

First my use cases: I want  progressively to
1) upload files to a component, and find them later, with permission handling
2) share directory (virtual or real) with a contact (or several with 
permission handling)
3) share photo albums
4) allow to manipulate files (delete, rename, change permissions, etc.)

Once XEP-0234 (Jingle FT) is implemented, it's really easy to do as file 
request is specified (https://xmpp.org/extensions/xep-0234.html#requesting).

I have checked available XEPs to share a structure, the 3 of interest are:


it's using disco and SI File Transfer (XEP-0096) to retrieve files
		- we can retrieve whole tree at once with a tree.xml
		- based on deprecated technologies, so discarded


it's using pubsub to share files metadata, with a mirror list, and using SI 
File Transfer as main way to retrieve file
		- Pubsub based, so we have subscription, access models and search 
(via MAM) for free.
		- handle revisions
		- handle mirrors, even non XMPP (e.g. ftp, http, torrent)
		- tedious to implement in current Pubsub ecosystem state
		- Pubsub Collections Nodes (XEP-0248) are in my opinion unusable, as 
the access model of the collection node override leaf nodes access models 
(but it would be a good XEP if this was fixed)
		- using deprecated technologies (but this can be fixed easily)
		- seems a bit over-engineered, not sure to see widespread 

I've tried to contact the author to see if he still wanted to work on this 
without success


it's using a simple IQ request, where node is the requested directory, 
which return XEP-0234 file informations, sufficient to request the file with 
jingle. There is a way to create a P2P channel to retrieve big repository 
(or to encrypt metadata)

		- simple and easy to implement
		- based on good technology stack (jingle)
		- can use a separate channel for signal, allowing large amount of 
data and metadata encryption
		- no subscription mechanism (we need to poll to see if there are new 
		- no search/filtering
		- no file revisions

That's the one I've chosed for its simplicity. There are small annoying 
stuff that need to be fixed though (I don't like that sometime we can send 
just the name, sometime a whole bunch of metadata, and that directories 
can't be empty), but it's doing the job quite well for basic use cases.

With XEP-0234 and XEP-0329 I can do my 1) and 2) uses cases. 4) can be done 
with ad-hoc commands (XEP-0050), even if this would need a XEP to specify 
well known nodes.

For 3) (photo albums), I need other features:

I) I need to be able to filter by mime-type, to retrieve only photos, or 
II) I need to retrieve thumbnails if available
III) I want to allow users to comment any file

For I) as far as I know, there is no solution at the moment

For II) XEP-0264 can be used (Jingle Content Thumbnails)

For III) I want to use XEP-0277 (microblogging over XMPP) as we have 
already advanced implementations. But I don't want to have to request one 
node per file when most of files will probably not have any comment. My 
current plan is to let the file sharing component handling the nodes, so it 
can return the number of comments with file metadata, and I can request 
comments only if needed. Any better suggestion welcomed.

My current implementation will be available in next release of Salut à Toi 
(or soon in dev version for the most adventurous ones). If other people are 
willing to work on this field, please contact me.


More information about the Standards mailing list