Matrix Application Services are meant to be able to do that. In fact, one of the main goals of Matrix is to be able to bridge different protocols together. So you don't need a separate protocol, you just need a Matrix-XMPP bridge. There are a few experimental bridges already, but none are really production-ready yet.
I don't think instances dedicated to a specific thing is as popular in the XMPP world, though I'm not sure why.
Disroot (https://disroot.org/) has an instance "based on principles of freedom, privacy, federation and decentralization" according to their website, that might be a good fit for you. I've used yax.im in the past, the maintainer is heavily involved with XMPP stuff and it seems pretty good. I've heard good things about https://dismail.de/ as well. And finally, my personal account is at conversations.im, although that one costs money.
Converse.js does not upload OMEMO keys to any servers, and in fact it has no server-side storage at all - it's a client-side Javascript application that operates within your browser. It aims to connect directly to your XMPP server using BOSH (HTTPS) or websockets. If those fail (due to your server not supporting these connection methods) it can fall back to a proxy. The proxy is not ideal, but still it does not get access to your OMEMO keys.
Since Converse.js is simply HTML+Javascript it is very easy to deploy to anywhere that can serve static files, and it's ideal when server operators provide an up-to-date version on their own site.
There is also <code>XEP-0368</code> which seem to have been adopted by quite a few client/servers which allows one to specify dedicated TLS endpoints through _xmpps-{client,server}
, instead of STARTTLS
ones which can get MITM'ed.
The timing is interesting. I wonder is gdpr becomes easier when you control all the servers. We still do t know what gdpr will do to server federation or communication between eu and us
Look at the right to be forgotten stuff.
https://nextcloud.com/blog/nextcloud-introduces-social-features-joins-the-fediverse/
Well my bad. I was getting NextCloud Chat mixed-up with NextCloud Social.
I'll edit my original reply.
As you recommended Gajim, it's also available on Mac, with the same features as on Windows and Linux - though installation is not straightforward at all at this time.
Monal (https://monal.im) is also available with Omemo, and its counterpart on iOS based on the same code as well.
As I explained as well, Adium/Pidgin have outdated omemo support so less recommended, but aside from that, they work...
It supports OMEMO, but depending on how you use it, there are some things to consider:
1) If you select "this is not a trusted device" when you login, OMEMO is disabled to avoid a false sense of security. If you say it's a trusted device, the padlock should enable OMEMO.
2) If you install conversejs on your own server or computer, there's a good chance you need to supply your own OMEMO js file, because it cannot be bundled with conversejs due to different licenses. Chimeverse has a compatible license and bundles OMEMO.
https://conversejs.org/docs/html/features.html#end-to-end-message-encryption-xep-0384-omemo
There is XEP 0289 but it would need some more work for handling of case where one node is going offline etc and it would also need server implementations...
There has been some protocol work going into this (see link below), but the general consensus was that in a federated system that's open for third party clients (the essence of XMPP) doing ephemeral messages doesn't really make sense since you cannot force the receiver to reliably delete the message as requested.
What you probably need is writing an XMPP Component and connect to a server that implement the rest of XMPP (included the federation part), the protocol is defined in XEP-0114:
https://xmpp.org/extensions/xep-0114.html
And you can find an example here (sorry, it's in Python because I found no free .Net library implementing the component protocol):
https://slixmpp.readthedocs.io/getting_started/component.html
That depends on the way you choose to transfer the data. XEP-0234 negotiates the file size to your contact, in the xep there are different conditions mentioned which would lead your contact to about the transfer. Thus the transfer amount 8s possible to be limited by your contacts storage and connection. With XEP-0363 the upload size is limited by the configured maximum filesize of the server.
Most providers state the maximum upload size on thier website. Alternatively there are multiple sites collecting such data points for great amounts of public servers. Those sources could be inaccurate though.
Implementint a client-side XEP usually consist of the following steps:
That may sound not very helpful, but every XEP is different, so there is no definitive answer for this.
I'd start by implementing a XEP which is merely about information transfer. XEP-0107: Mood is a classic, which is quite simple to implrment.
Basically you have to read up, how libstrophe does implement extension elements and hoe you listen for them.
I can recommend the book "The definitive Guide to XMPP", which helped me a lot to start with XMPP :)
Ejabberds documentation documents mix 0.1.0 the xep revision history on the other hand lists the latest revision 0.14.1 from the 5 January 2019.
I would recommend asking in the xsf muc about the current mix state.
Source: https://xmpp.org/extensions/xep-0369.html https://docs.ejabberd.im/tutorials/mix-010
Here - https://ulloo.net/ the latest version of jabber server. It supports most XEP. But in order to accurately answer your question, write a list of your XEP used in standard: XEP-0000 where 0000 XEP code. For a complete list of all existing XEP can be found here: https://xmpp.org/extensions
If you just want to chat via XMPP, I would recommend to forget about Cisco Jabber.
There are various clients available, a selection can be found here:
https://xmpp.org/software/clients.html
I don’t use Windows, so I don’t know if there’s a better one for this OS, but I can recommend Gajim.
Thanks for help. I guess the link i provided was listing XMPP servers (both of them support XEP-0280 and XEP-313). And since Conversations app is supposed to support those 2 as well, i guess i might as well submit an issue ticket on their github.
That is an interesting question and I don’t know the answer to it. I think bridges are always a second class citizen in any protocol (Even though they play a huge role in Matrixes marketing strategy.) and are probably not designed and developed by the most competent people ever. Developing a "proper" bridge that emulates users on both sides requires deep insights and understanding of both protocols. The matrix website lists different types of bridges and admits that what they describe as the most elegant way of doing a bridge (server to server bridging) has not been implemented yet.
Even one of the best bridges out there (biboumi which bridges IRC to XMPP) doesn’t do s2s bridging but creates a c2s connection to the IRC server for every single user instead of just emulating an IRC server on the s2s link.
If you follow the 'the best bridges are done on the s2s level' argument you’ll quickly run into the question on why - if s2s bridges are not only possible but are also the best solution to that problem - wasn’t matrix designed in a way that only replaces the client to server protocol while keeping the s2s protocol.
So either bridges are a fundamentally flawed concept that will never work properly or the whole idea of reinventing the wheel with matrix was a stupid idea.
I have both apps in use as I recommend both of them on my website. But I have to say that both apps have pros and cons. Mostly ux stuff, as PixArt now has push too, but for some people that is really important.
Conversations also supports older version with the Conversations Legacy App which is free in the Appstore. https://play.google.com/store/apps/details?id=eu.siacs.conversations.legacy