Skip to main content


Should #Conversations_im add stun.conversations.im as a fallback for #XMPP servers missing XEP-0215: External Service Discovery?

I’ve hesitated to add anything resembling "calling home" (no update checker, no metrics).

However, the main goal here wouldn’t be improving A/V call success (though it helps) but making P2P file transfers more reliable. Many servers still lack HTTP Upload, and the refactored Jingle File Transfer would benefit greatly from a fallback STUN server.

  • Yes (72%, 63 votes)
  • No (27%, 24 votes)
87 voters. Poll end: 1 month ago

Peter Vágner reshared this.

in reply to Daniel Gultsch

Would not it be better to give users a warning "your server do not support the following features X, functionality Y will not work", rather than silently put the stress on conversations.im infrastructure?
in reply to Daniel Gultsch

wouldn't it be better to give users/ admins a hint?

I understand that you want to give best possible user experience to Conversations, but:

As a admin I am interested to improve my server (or maybe I don't want to use STUN at all?), and as a user I would like to switch to a server that fits my needs. 🤔

Using your infrastructure feels bad, because it allows to keep badly hosted servers without noticing it.
Perhaps give a hint to admins, how he can improve it or how to use your services.

Also from a GDPR view:
Does the user agree to contact a server he did not configure himself?

in reply to Daniel Gultsch

Yes, but before using it, the user should confirm they want to use this service like it is already done with search.jabber.network. In any case, it should also be possible to configure the URLs of the STUN servers in the settings.
in reply to Daniel Gultsch

I had a hard time setting up turnserver with prosody. And i failed. I think it has to do with NAT (the server is a vserver at hetzner). Instead of a fallback i would have loved to have some debugging tools for turn.
in reply to Daniel Gultsch

Absolutely nothing is worse than a bad (first) user experience. Fallback, make a one-off notification/confirmation, and an advanced option to turn it on/off.
in reply to Daniel Gultsch

yes.

But communicate clearly about it.

I still encounter people that say "I don't want to use xmpp, it doesn't work" - when the last time they tried was years ago. Bad Ux seems to create long lasting bad impressions.

in reply to Daniel Gultsch

maybe an option to disable (opt-out) the fallback could help for those who not like this feature.
in reply to Daniel Gultsch

yes, those who don't care will have ability to make calls, those who care will spend some effort to spin off and publish own service.
in reply to Daniel Gultsch

If it can be deactivated in the configuration, then I don't see an issue with that. I would appreciate a warning though somewhere, maybe just a Message Toast on both sides that the fallback is used. That would help notice wrong configurations.

It would be great if conversations could verify that stun/turn works completely in addition to that. (Might also be a separate tool).