[geekuillaume]

I encountered this problem on my project Soundsync. It's controlled by a webpage that needs to connect to every Soundsync peer on the current local network. I couldn't use HTTP as I need to instantiate an AudioWorklet (which has the same security requirements as a WebWorker). The big browser warning of a self-signed HTTPS certificate is a deal-breaker for a lot of non tech-savy users (which are my target).

In the end, I used WebRTC from an external HTTPS webpage I'm hosting and a "mailbox" service where two peers can post and retrieve messages from a UUID. To communicate this UUID on the local network to the peer, I first used an <img> tag with the UUID in the URL query string but this method was recently broken because of increased security measures by browsers. I now use two methods:

- Bonjour: Every peer listen for every bonjour request on the network, on the webpage I make a request to https://soundsync-UUID.local/. The peer then extract the UUID from the request and connect

- TLS Server Name Indication: I use sslip.io to connect to https://UUID_IP.sslip.io/. This is redirected to the local network IP of the peer which use the full domain name in the TLS handshake to extract the conversation UUID. This method doesn't always work because of some router filtering out DNS records resolving to 192.168.X.X.

All this process is very hacky and doesn't always work but I haven't found anything else better. We still don't have a good way to make self-hosting easy for anyone while making it secure and not dependant on an external service.

[Wowfunhappy]

As much as I dislike it for most things, your project sounds like the ideal candidate for an Electron app!

Edit: Just to clarify, I meant because an Electron app could be coded to allow a self-signed certificate, or allow AudioWorklets over http, or whatever other solution makes sense for your use-case.