-
-
Notifications
You must be signed in to change notification settings - Fork 771
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XEP-0363: HTTP File Upload #161
Comments
A possibility would be, using WebRTC, to pass sending/receiving information through the chat. |
File transfers would be a useful feature. There is an XEP (0096) for this: http://xmpp.org/extensions/xep-0096.html And there is also a Strophe.js plugin: https://github.com/strophe/strophejs-plugins/tree/master/si-filetransfer. I agree that WebRTC could be used to transfer the file data out-of-band while XMPP is used to initialize the transfer. |
Hello, What about Jingle File Transfer: http://xmpp.org/extensions/xep-0234.html? Conversations, gajim and swift implement that. Thank you. |
@kruks23 Thanks for the info. I haven't yet decided upon a standard, but good to know that XEP-0234 is implemented by those projects. |
There are some WebRTC js available. For example, jsSIP, SIP.js, if converse.js can aware any one of these two, converse.js + (jsSIP or SIP.js) could be a great "Web based" UC client. those js do support file transfer, plus video, voice support, they connect to the sip based IP-PBX. It will be a powerful integration client. |
The file transfer probably can use http post... if it make sense... The user can upload the file, and the http server reply back the file URL to the sender when the file upload successfully , and the file sender then send out the URL to received side by using xmpp message. When the Received side get the message, the received side can show the URL and allow the user to click the URL to download the file from the http server. It is quite simple in this way. |
I think now is better to use Http File Upload (#466). |
Note that this requires a third-party file storage service:
Whereas https://xmpp.org/extensions/xep-0096.html requires no additional server (if I understand correctly) |
Http FIle Upload requires the same server that you use to send your messages via xmpp. Servers like ejabberd or prosody already support xep-0363 Http file upload. |
I created #593 for XEP-0234 (Jingle File Transfer) support. Could this issue please be renamed to "XEP-0363 - HTTP File Upload" (and add a link to XEP-0363 to clarify the destinction? @nodiscc I think many clients are migrating away from XEP-0096 (SI File Transfer) and new clients are not implementing it, but are rather going straight for XEP-0234. The reason is afaik that XEP-0095 (Stream Initiation), on which SI File Transfer is based, does not deal with firewalls and NAT. This is handled by XEP-0166 (Jingle), on which Jingle File Transfer is based. Details can be found in the Requirements section of the Jingle File Transfer specification. |
HTTP storage is provided by Jabber server (ejabberd and prosody provides this). So to implement this feature, two tasks to be done: 1. Negotiate upload slot via XMPP, 2. perform HTTP PUT on the negotiated URL. That's it. Once upload is completed, URL needs to be sent via chat, but that is an ordinary message. To receive the uploaded file, nothing has to be done, the URL will appear in chat and that is completely fine. HTTP upload is the most reliable file sharing method Jabber has. There is no need to implement anything else, since nothing else is actually supported widely enough and even when it is supported clients must understand each other (XEP versions) and must be able to connect to each other (NAT, firewall). It never really worked for me. On the other side, HTTP upload works well in MUC and with transports (ICQ, Facebook), since the only thing to send via chat is plain URL. |
In my experience, XMPP servers (instances, not the software) which support modern XEPs are extremely rare. So rare in fact, that I am again running an own instance, because none of the available (free or part of a paid email contract) ones support any useful (mobile) extensions. Many people will probably not be in the lucky situation that they can easily boot up an own XMPP server. Thus I would argue that a file transfer implementation which is independent of the server is still very much needed. |
@devurandom As I understand purpose of Converse.js, it is meant for integration into another application, therefore you run your own infrastructure more or less anyway. |
I'd love to see http_upload here, too. +1 |
@jcbrand : Would you set me on track for this ? :) |
@happy-dev You'll need to write a plugin for converse.js The most up to date docs for plugin development are here: Once the next release is made, those docs will also be on https://conversejs.org |
Thank you very much ! |
Team OK for it.
Would you have any recommendation to tackle this ? Many thanks for your inputs |
@happy-dev Sounds great :) Generally how I go about adding new features/plugins, is that I first write the plugin outline, and make sure it's loaded together with all the other plugins. That requires a few steps, such as updating the src/config.js file, adding the file to the src directory and whitelisting it in converse-core. Most of that is covered in the plugin documentation mentioned above. The only thing not mentioned that I can think of now is the fact that you also need to set the plugin path in src/config.js. Then, once you have the plugin registered and loading when you load converse.js, you can start adding the functionality via test-driven development. I don't always do test-driven development, or let's say at least, I don't always start with tests. But with the XMPP protocol it works well because you can directly test the XML stanzas from a relevant XEP and then check that converse.js does the right thing. So, once the plugin outline is available, I'd study the relevant XEP-0363 and start mocking the XML traffic in tests. I'd create a new test file in the spec directory, to specifically test this new plugin. This is fairly easy to do. Take a look at spec/protocol.js for tests which test the XMPP protocol. Similar things are done in spec/chatbox.js and spec/chatroom.js. Basically you can simulate incoming XML stanzas, write your plugin to send the right outgoing stanzas and then test that this all conforms to the XEP. This way you can write a plugin without needing an XMPP server at all. At least initially, obviously later you'll want to test with a real server. |
Thank you so much. I believe you just set the TODO list for this weekend ! |
* Use Promises instead of callbacks * Update to latest (Last Call) version of XEP-0363 * Move non-view specific methods to models instead * Add more tests updates #161
It contained only `overrides` and some HTTP upload code was in other modules. Current thinking concerning overrides: Usage of `overrides`, while useful in certain cases, should in general be discouraged, since it's in essence "monkey patching" which makes it more difficult to know whats executing at runtime and more difficult to refactor. Splitting modules up between XEPs is not always that useful. Some XEPs, like HTTP Upload (and MAM comes to mind) have their functionality spread out over single and group chats (and pubsub) and might for practical purposes be considered "core" enough to not try and keep them in separate modules (which inevitably requires overrides or a fundamentally rethinking the architecture). Where splitting code between modules makes a lot of sense is in keeping Backbone Models and Views separate (so that alternative view libraries like Vue could be used) and probably in keeping Single chats, MUC, PubSub and MIX separate. updates #161
Specifically the methods related to requesting an upload slot and uploading a file. Also show a progress indicator while a file is being uploaded. Updates #161
This has been implemented and will be included in the 4.0.0 release. |
Would like anyone to show how to configure converse.js to enable "File sharing / HTTP File Upload XEP 363" function ? |
@Heraptor you need to make sure your xmpp server supports that XEP. |
@jcbrand i have setup ejaabberd & converse.js and everything is working fine as far as chat is concerned. Now please guide me the way for attachment support in the same. Thanks |
@Pankhur What error do you see? |
@licaon-kter So, i configured ejabberd.yml config for attachment support as mentioned here but nothing seems to working and when i attach any file via converse it just sits idle there. |
So, error in browser console? Error in ejabberd.log? Actual config of server? |
Hi, I configured converse.js 6.0 to work with prosody. I activated XEP-0363 module "http_upload_external" module of prosody and set up a perl file upload server behind nginx (https://github.com/weiss/ngx_http_upload). The paperclip icon did appear and clicking on it allows it to choose a file to upload.
What is going wrong ? |
Prosody is saying that the service is not available. So you probably misconfigured it. |
Issue fixed. |
Hi Thierry Kauffmann, can you share how you got it running? I am trying to do the same but it's not working. |
Hi @itsdennian, It's been a long time (many months) since I did this and I can't remember exactly what I did. What is not working as expected ? |
Hello.
It probably hasn't been implemented from what I've seen, but is there/could there be a way of handling file upload/transfer from within the chat?
For example, I'd like to select (or drag and drop) a file from my drive in a conversation (either room or private). At that point, probably Converse.js would not handle the file itself, but rather offer a hook when such an event occurs. I have no experience with such events actually.
In the end, once the upload is considered over, an URL would be sent as a message, so chat users can access the file right away.
Thanks in advance.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: