Wojciech Kapcia (Tigase) opened 2 years ago
-
@wojtek I was thinking about that and I've mixed feelings. On one side, having this could be helpful, however, I think that quite often for the XMPP server running at
domain.comat the same DNS name there is a website running (ie. XMPP client, company website). With that in mind, provider would be forced either to redirect requests from this json file or server static version of a JSON file.Some fields values could be fetched from the XMPP server settings, however not all of them (for some we would need to add options to set them). I'm reluctant to keep that in TDSL file, as we have many cluster nodes so it would be better to keep that in sync in database.
Also things like
Alternative JIDsis not just list of VHosts with open registration? ie. on tigase.im we allow people to host their domain and allow them to open registration, but we do not "own" the domain, so we cannot guarantee its availability (so we shouldn't advertise it).I'm also not sure, how often this file will change? I suppose not very often, and with provider file generator supporting upload and changes, I wonder how and in what case would benefit from this feature?
| Type |
New Feature
|
| Priority |
Minor
|
| Assignee | |
| Version |
none
|
| Sprints |
n/a
|
| Customer |
n/a
|
There is https://providers.xmpp.net/ which helps with discovering XMPP services and their properties. There is a move towards mora automatic approach ( XMPP Providers Fully Automated ) so it would be good to include such feature and generate and server the file.
There is Provider File Generator but I think it would be more convenient to generate such file from data provided in TDSL file or obtained from other configuration fields (password reset url, software version, in-band registartion and so on).
Current data for our services is available here: https://invent.kde.org/melvo/xmpp-providers/-/blob/master/providers.json#L6499