Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A while back I built out a proof-of-concept distributed web based on webtorrents - https://github.com/tom-james-watson/wtp-ext. Once this change makes its way into popular clients, it makes the idea a whole lot more viable.

Unfortunately it looks like Mozilla's interest in the distributed web died when they made redundant the main stakeholders in the project last year - https://github.com/mozilla/libdweb/issues/109.



It's really fucking sad that Mozilla is struggling so much financially. They didn't participate on the iOS platform for a long time, then they burned a huge pile of cash on FirefoxOS, and now they have to somehow match the engineering resources of Google and Microsoft.

I personally work on a decentralized web project ... but even I can't fault them for shutting down side projects. Every project either needs to provide alternative revenue streams or feed into getting Firefox on par with Chrome's speed, security, and feature set. Hopefully Chrome will follow through with neutering their ad-blocking and people will switch back to Firefox.


When I was last looking at the libdweb stuff they didn't have WebRTC support working in the service workers to let you use it from a protocol handler (and they somehow didn't even consider that important as they insisted no one would even want to use WebRTC, which made no sense to me); did they eventually fix that so you could do WebTorrent?


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.


Pretty 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.


OK, 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

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

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

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?


The Internet Archive is very active in the distributed web space. Have you gotten in touch with them?




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: