Fun! I wish WebTorrent had caught on more. I've always thought it had a worthy place in the modern P2P conversation.
In 2020, I messed around with a PoC for what hosting and distributing Linux distros could look like using WebTorrent[1]. The protocol project as a whole has a lovely and brilliant design but has stayed mostly stagnant in recent years. There are only a couple of WebRTC-enabled torrent trackers that have remained active and stable.
I think the issue has generally been that web torrent doesn't work enough like the real thing to do its job properly. There are huge bit torrent based streaming media networks out there, illicit, sure, but its a proven technology. If browsers had real torrent clients we would be having a very different conversation imo
I don't remember the web torrent issue numbers off the top of my head, but there are a number of long standing issues that seem blocked on webrtc limitations.
I think we still have the same blocker as we had back when WebTorrent first appeared; browsers cannot be real torrent clients and open connections without some initial routing for the discovery, and they cannot open bi-directional unordered connections between two browsers.
If we could say do peer discovery via Bluetooth, and open sockets directly from a browser page, we could in theory have local-first websites running in the browser, that does P2P connections straight between browsers.
Can't seem to find any mentions of this online from over a week ago, not much commentary either, mostly stuff that smells like advertising / astroturfing. Hmm...
What a pity that although webtorrent support is already merged in the libtorrent master branch years ago, it's not merged into the stable branch yet, therefore not working out of the box in clients like qBittorrent.
If it was, would it mean that qBittorrent would share with web clients by default? My understanding was that it's not the same protocol, so I'm guessing that a client like qBittorrent would have to choose to "bridge" between both protocols, right?
This is cool - I actually worked on something similar way back in the day: https://github.com/tom-james-watson/wtp-ext. It avoided the need to have any kind of intermediary website entirely.
The cool thing was it worked at the browser level using experimental libdweb support, though that has unfortunately since been abandoned. You could literally load URLs like wtp://tomjwatson.com/blog directly in your browser.
I think one of the values of (what appears to be) AI generated projects like this is that they can make me aware of the underlying technology that I might not have heard about - for example WebTorrent: https://webtorrent.io/faq
Pretty cool! Not sure what this offers over WebTorrent itself, but I was happy to learn about its existence.
I'm planning to eventually launch an open source platform with the same name (peerweb.com) that I hope will be vastly more usable, with a distributed anti-abuse protocol, automatic asset distribution prioritization for highly-requested files, streaming UGC APIs (e.g. start uploading a video and immediately get a working sharable link before upload completion), proper integration with site URLs (no ugly uuids etc. visible or required in your site URLs), and adjustable latency thresholds to failover to normal CDNs whenever peers take too long to respond.
I put the project on hiatus years ago but I'm starting it back up soon! My project is not vibe coded and has thus far been manually architected with a deep consideration for both user and site owner expectations in the web ecosystem.
Well this is supposed to load a website in the browser like a "normal" website (doesn't work for me, stuck on "Connecting to peers...").
Just using a torrent client means that you have to download the website locally with a torrent client, and then open it in your browser. Most people wouldn't do that.
If it actually worked i could certainly see the value prop of not making users download a separate program. Generally downloading a separate program is a pretty big ask.
I wonder if these colors are a kind of a watermark that are hardcoded as system instructions. Almost all slopware made using claude have the same color palette. So much for a random token generator to be this consistent
Ask any modern (post-GPT-2) LLM about a random color/name/city repeatedly a few dozen times, and you'll see it's not that random. You can influence this with a prompt, obviously, but if the prompt stays the same each time, the output is always very similar despite the existence of thousands of valid alternatives. Which is the case for any vibecoded thing that doesn't specify the color palette, in particular.
This effect is largely responsible for slop (as in annoying stereotypes). It's fixable in principle, but there's pretty little research and I don't see big AI shops care enough.
Before LLMs became big, I used emojis in my PRs and merge requests for fun and to break up the monotony a bit. Now I avoid them, lest I be accused of being a bot.
Yep, and I refuse to use sites that look like this. Lovable built frontend/landing pages have a similar feel. Instant lost of trust and desire to try it out.
> XSS Protection - All HTML sanitized with DOMPurify
> Malicious Code Removal - Dangerous tags and attributes filtered
> Sandboxed Execution - Sites run in isolated iframe environment
I don't think that super makes sense. You probably just want the iframe sandbox and not remove all js. Or ideally put the torrent hash as the subdomain to use same origin policy.
I think serving video is a particularly interesting use of Webtorrent. I think it would be good if you could add this as a front end to basically make sites DDOS proof. So you host like a regular site, but with a JS front end that hosts the site P2P the more traffic there is.
I think it is very difficult (and dangerous to the host) to serve user-uploaded videos at scale, particularly from a moderation standpoint. The problem is even worse if everyone is anonymous. There is a reason YouTube has such a monopoly on personal video hosting. Maybe developments in AI moderation will make it more palatable in the future.
The "host" is the user in this case. Every user that watches the video, shares the video. Given that discovery doesn't appear to be a part of this platform, any links would undoubtedly be shared "peer-to-peer" as well, so if you aren't looking at illegal things and don't have friends sending you illegal things to watch, it's perfectly safe.
What I'm suggesting is more in the context of self hosting - a JS wrapper which would make it easy to host a video with plain HTML while preventing bandwith issues.
I like Peertube a lot, and I didn't realize until just now that they had a form of P2P distributed distribution which uses WebRTC. But it would be great to be able to do that with a static site, without deploying a whole framework. Just a simple JS wrapper which could sit on top of a <video> element would be amazing
Readit News
In 2020, I messed around with a PoC for what hosting and distributing Linux distros could look like using WebTorrent[1]. The protocol project as a whole has a lovely and brilliant design but has stayed mostly stagnant in recent years. There are only a couple of WebRTC-enabled torrent trackers that have remained active and stable.
1. https://github.com/leoherzog/LinuxExchange
I don't remember the web torrent issue numbers off the top of my head, but there are a number of long standing issues that seem blocked on webrtc limitations.
If we could say do peer discovery via Bluetooth, and open sockets directly from a browser page, we could in theory have local-first websites running in the browser, that does P2P connections straight between browsers.
The elinks text-only browser has a "real" torrent client
The cool thing was it worked at the browser level using experimental libdweb support, though that has unfortunately since been abandoned. You could literally load URLs like wtp://tomjwatson.com/blog directly in your browser.
Pretty cool! Not sure what this offers over WebTorrent itself, but I was happy to learn about its existence.
I’m not sure what the value prop is over just using a torrent client?
Maybe when they’re less buggy they’ll become a thing.
I put the project on hiatus years ago but I'm starting it back up soon! My project is not vibe coded and has thus far been manually architected with a deep consideration for both user and site owner expectations in the web ecosystem.
Just using a torrent client means that you have to download the website locally with a torrent client, and then open it in your browser. Most people wouldn't do that.
Ask any modern (post-GPT-2) LLM about a random color/name/city repeatedly a few dozen times, and you'll see it's not that random. You can influence this with a prompt, obviously, but if the prompt stays the same each time, the output is always very similar despite the existence of thousands of valid alternatives. Which is the case for any vibecoded thing that doesn't specify the color palette, in particular.
This effect is largely responsible for slop (as in annoying stereotypes). It's fixable in principle, but there's pretty little research and I don't see big AI shops care enough.
Deleted Comment
Grok almost never uses emojis.
Would it be the case for folks who don't have any idea what Lovable is.
Familiar UI is similar to what Tailwind or Bootstrap offers, do they do something different to keep it fresh?
Average internet users/consumers are likely used to the default Shopify checkout.
> XSS Protection - All HTML sanitized with DOMPurify > Malicious Code Removal - Dangerous tags and attributes filtered > Sandboxed Execution - Sites run in isolated iframe environment
I don't think that super makes sense. You probably just want the iframe sandbox and not remove all js. Or ideally put the torrent hash as the subdomain to use same origin policy.
I think serving video is a particularly interesting use of Webtorrent. I think it would be good if you could add this as a front end to basically make sites DDOS proof. So you host like a regular site, but with a JS front end that hosts the site P2P the more traffic there is.