2 ms·
You can implement your own protocol + handler with the functionality exposed by the library as far as I understood. It doesn't really matter anyway since you h
by madushan1000 6y ago
You can implement your own protocol + handler with the functionality exposed by the library as far as I understood.
It doesn't really matter anyway since you have access anything firefox can do with webextensions experiments, which was required since libdeweb isn't a part of firefox(and won't be anytime soon because AFAIK most people who were working it has been laid off) and to run experiments you need firefox nightly.
- mcjiggerlog 6y agoPretty much this. The code runs as an extension - it registers the protocol handler in the extension's background script. That means the code for webrtc has no need to run in a service worker.
- saurik 6y agoOK, so as I don't actually do much in-browser development, and because this was also two years ago, "of course" I managed to get the terminology wrong: the issue was that WebRTC wasn't supported in a "WebExtension" (not a "service worker", which happened to be the subject of a massive thread I was reading a few weeks ago on WebRTC not working there either). Here's the bug I had referred to the libdweb person at the time in November of 2018 (due to comment #2): > RTCPeerConnection.createOffer doesn nothing in WebExtension background script https://bugzilla.mozilla.org/show_bug.cgi?id=1398083 https://bugzilla.mozilla.org/show_bug.cgi?id=1398083 This bug had already been resolved in September of 2018 as a duplicate of this bug: > WebExtension cannot access WebRTC mic from popup.js nor background.js https://bugzilla.mozilla.org/show_bug.cgi?id=1278100 https://bugzilla.mozilla.org/show_bug.cgi?id=1278100 And I now see that bug ended up getting resolved in September of 2019 as a duplicate of this bug: > Improve getUserMedia permission model for web extensions a bit. https://bugzilla.mozilla.org/show_bug.cgi?id=1579489 https://bugzilla.mozilla.org/show_bug.cgi?id=1579489 Which was supposedly fixed? I'm honestly a bit concerned still, though, as this bug slowly got dragged from being about createOffer to being about permissions dialogs for audio/video, and it kind of sounds like there's some weird thing where a "foreground page" has to vouch for the extension, which shouldn't be required. Everyone who works on WebRTC stuff in browsers conflates it all with getUserMedia, but all of us distributed web people just want peer-to-peer data channels :/. I take it this is actually fixed then, and you can now use WebRTC in this context?