So what I find confusing here is “Cannot access gateway over mDNS (.local)” but you also say “we’re accessing the webui via https://<domain>.local”, which implies you’re accessing the webui through your local gateway.
No, embassyOS allows the service packager to define multiple interfaces, which each receive a unique domain.local. For this package I have defined two separate interfaces: one for the API/webui, and another for the gateway. I can make them both the same interface if need be.
As a brief intro, embassyOS is a system for easily running any dockerized service on a raspberry pi in the user’s home. The OS takes care of reverse proxying all the connections to and from the containers and the external world. The hard part is packaging the service [ie IPFS] for embassyOS [ie what I’m doing right now]. The service packager defines a manifest file that tells the OS what ports to expose on what interfaces.
Also the 0.0.0.0 I believe should be what interface it’s broadcasting on, it should effect how it’s accessing content, assuming you’re talking about a setting on your actual IPFS node (which is what’s hosting the gateway). I’m unsure which setting on what tech you’re talking about here though.
The 0.0.0.0 is both the listening IP (defined in the kubo config file as: "Gateway": "/ip4/0.0.0.0/tcp/8080",) and the link that is accessed by the frontend whenever I click on a file to view it, or attempt to download it (this is what causes the browser to complain like so: Blocked loading mixed active content “http://0.0.0.0:8080/ipfs/<cid>”. Ostensibly this error is caused because of the http scheme at the beginning of the page, being viewed from an https://<domain>.local URL. If there were some way to change this URL in the kubo config, that would most likely fix this problem, but I don’t see a way to do this.
In an exchange I just had with Jorropo.eth in the #community-help channel on the IPFS discord, I was able to change the default public gateway in the frontend settings, which causes files to be viewable in the webui because the gateway URL is correct now. However, I still cannot download files from the webui. When I try, it gives me the same “mixed content” error as before. This is bizarre, because if I copy and paste the exact URL from the errored GET request into my browser’s address bar, the file appears just fine.
Would you mind maybe focusing on the WebUI aspect, and what works, and what doesn’t? I understand you’re trying to do it “over mDNS”, so what I’m wondering, specifically in relation to the WebUI, what is happening in regards to what you expect to happen, and what is actually happening instead?
I believe I just answered this in the above paragraph. Let me know if you need any more details.
If port 5001 is accessible over the network (which would give anyone access to that full control over your node BTW), that’d allow you to use the WebUI from a different device (which I’m assuming because of docker reasons, that could also be the same device).
The point of .local is only to expose your address over LAN. So only people on your LAN can access your webui. We would also be exposing the webui as a Tor hidden service, which, yes, would be accessible to anyone with your Tor .onion address. But our users know not to share this with anyone they don’t trust.
However even if it is accessible, CORS still needs to be configured to allow wherever you’re coming from to be trusted.
Adding a CORS exception for the gateway .local domain does not seem to make a difference. Though perhaps I’m adding it in the wrong place. I added it to API.Access-Control-Allow-Origin, because I don’t see a place to add a CORS exception for the gateway. But again, I don’t think that’s the problem; I think the problem is that the UI is trying to access http://0.0.0.0:8080, which makes no sense.
Otherwise for https I feel like you’re always going to have browsers complain about invalid cert issues over your local network. You could use plain HTTP to access the gateway, assuming your trust your local network.
This has nothing to do with the cert. embassyOS generates a root CA for each device, and once installed in your browser, all leaf certs generated from the root CA are valid, including the ones for the gateway and the webui/API, in this case. And no, I cannot use cleartext HTTP since embassyOS does not support cleartext HTTP over .local, and I don’t think that would make much sense anyway. But I’m open to temporary workarounds.
This is all to say: I’m sorry I’m not quite understanding what you’ve tried, what you want to accomplish, or what result you’re looking for. I do hope to assist you though, so I’m here to struggle along-side you :').
I super-appreciate your response! I hope my answer helps you understand a bit clearer what the problem is 
. Things are much clearer now, but of course still a bit confusing as to why it’s not working.