json based server lists via HTTPS

[QJKX]

Just bouncing the idea around.
This doesn't have to replace the existing implementation - it's use could be inferred by the client's directory server URL.

Pros:

• Removes limit on server list size
• Server list delivery is assured by TCP
• Better errors than UDP
• Makes simple directory hosting for small groups of servers very easy (static file on a webserver)
• Could use FQDNs to shift IP address updates to DNS - leaving the static file alone. (individual jamulus servers can be configured with "dynamic DNS")
• Makes more sophisticated directory hosting accessible to higher level languages with existing libraries. This may be useful for building more features into a directory server service - like collecting and validating email addresses of server admins.
• Allows person-specific directory server URLs (unguessable URLs like Google Docs)
• Allows use of existing HTTP CDN infrastructure and DDoS mitigation services
• Allows use of HTTP caching headers
• Makes server list format extensible (clients should ignore unrecognised json keys allowing backwards compatibility with any keys added in later versions) (extensions might include server coordinates)
• Makes it easy to make attributes of servers in the list, list types. (eg multiple genres - there is a question as to if this information belongs in an individual server response instead though - the reason to put it here is for filtering - allowing clients to avoid probing irrelevant servers.)
• Lends itself to a file-based server list option (not sure why you'd want this?)
• Qt already includes support for HTTP and json

Cons:

• more traffic / slower loading time on client with FQDNs needing to be resolved (reasonable TTLs on domains should help via caching in the OS or network DNS server)
• The validation by the directory server that entries are correct is much more involved than a static file - that work is already done for the existing design, and a necessary feature for a public directory server.
• possibly an increased attack surface area on clients now they are speaking HTTP.
• Detecting that the client has UDP blocked may happen later in the processes of trying to connect, and be more confusing to the user.
• clients need web access
• HTTP is more likely to be messed with by corporate/institutional network appliances in confusing ways
• If it's trying to be clever, what the directory server gleans about the client's HTTP connection may not hold for UDP.
• Directory servers open themselves to the hordes of HTTP bots webmasters have to contend with.
• In turn servers are more likely to be probed

[pljones]

Please check out https://explorer.jamulus.io/ and https://jamulus.live/. There's no problem supplying the lists over HTTPS -- but it will not be inside the Jamulus software as it's not needed to mix audio or control the server.

[hoffie]

Thanks for the writeup. I definitely find this interesting. There have also been ideas to switch the non-realtime stuff to TCP, but there hasn't been anything specific so far. JSON-RPC -- despite being an internal admin interface only for now -- is another thing which got recently worked on. The bad thing is that any attempt to standardize or control those efforts might stall them. :(