Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Peerweb: Decentralized website hosting via WebTorrent

peerweb.lol

Post reply on HN
Print view View original

81–90 of 137 posts

Re: Peerweb: Decentralized website hosting via WebTorrent

#81

Post by t-3 »

NewsaHackO wrote: post #18
sroerick wrote: post #11

This is pretty interesting! 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.

Re: Peerweb: Decentralized website hosting via WebTorrent

#82

Post by alfiedotwtf »

TuringTest wrote: post #52
dpweb wrote: post #38

Useless if it takes > 5 sec. to load a page

You never lived the 90's

lol.

Not only did it take > 5 seconds to load a page, images were progressively loaded as fast as two at a time over the next minute or so - if there were no errors during transfer!

Re: Peerweb: Decentralized website hosting via WebTorrent

#84

Post by [deleted] »

tombert wrote: post #60
SLWW wrote: post #53

Earlier quoted context omitted.

We all know that CSAM is one of the first things that gets uploaded to these sorts of platforms. If advocating against CSAM = Fascism then I'll be the first to say that i'm a nazi facist. o7

In high school, an acquaintance of mine made the website "e-imagesite.com" [1]. It was a very easy-to-use image uploading site (and honestly less irritating than ImageShack and predated imgur). It was just being hosted on HostGator, I believe, and written in PHP and used jQuery. I believe he had to eventually shut it down because people kept uploading horrifying stuff to it, and it was never even that popular. Child…

[deleted]

Re: Peerweb: Decentralized website hosting via WebTorrent

#86

Post by westurner »

embedding-shape wrote: post #64
Seattle3503 wrote: post #59

Earlier quoted context omitted.

If a tracker could be connected to via WebRTC and had additional STUN functionality, would that suffice? Are there additional WebRTC limitations? > they cannot open bi-directional unordered connections between two browsers. Last I checked, DataChannels were bidirectional

Yes, but it's STUN that sucks. If the software ships with a public (on the internet) relay/STUN server for connecting the two clients, it won't work if either aren't connected to the internet, even though the clients could still be on the same network and reach each other.

/? STUN: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

There is a Native Sockets spec draft that only Chrome implements;

"Direct Sockets API": https://developer.chrome.com/docs/iwa/direct-sockets :

> The Direct Sockets API addresses this limitation by enabling Isolated Web Apps (IWAs) to establish direct TCP and UDP connections without a relay server. With IWAs, thanks to additional security measures—such as strict Content Security Policy (CSP) and cross-origin isolation— this API can be safely exposed.

Though there's UPNP XML, it lacks auth for port forwarding permissions. There's also IPV6.

Similar: "Breaking the QR Limit: The Discovery of a Serverless WebRTC Protocol – Magarcia" https://news.ycombinator.com/item?id=46829296 re: Quick Share, Wi-Fi Direct, Wi-Fi Aware, BLE Beacons, BSSIDs and the Geolocation API

Re: Peerweb: Decentralized website hosting via WebTorrent

#87

Post by rudhdb773b »

karanSF wrote: post #70
4nonverbal-alit wrote: post #65

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

Emojis on every line are an AI tell. The times I do use AI (shhhh...) I always remove them and tweak the language a bit.

Isn't it mostly ChatGPT that does that?

Grok almost never uses emojis.

Re: Peerweb: Decentralized website hosting via WebTorrent

#89

Post by miki123211 »

embedding-shape wrote: post #41
r14c wrote: post #32

Earlier quoted context omitted.

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 lo…

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 runn…

Could you run some kind of hybrid DHT where part of it was Webrtc and part was plain HTTP(S) / WebSocket?

There are some nodes (desktop clients with UPNP, dedicated servers) that can accept browser connections. Those nodes could then help you exchange offers/answers to give you connections with the Webrtc-only ones, and those could facilitate offer/answer exchanges with their peers in turn.

It'd be dog-slow compared to the single-udp-packet-in, single-udp-packet-out philosophy of traditional mainline DHT, but I don't see why the idea couldn't work in principle.

I think a much bigger problem is content discovery and update distribution. You can't really do decentralized search because it'd very quickly get sybil-attacked to death. You'd always need some kind of centralized, trusted content index, but not necessarily one hosted on a centralized server. If you could have a reliable way to go from a pubkey to the latest hash signed by that pubkey in a decentralized way, + E.G. a Sqlite extension to get pages on-demand via WebTorrent, that would get you a long way towards solving the problem.

Re: Peerweb: Decentralized website hosting via WebTorrent

#90

Post by namibj »

miki123211 wrote: post #89
embedding-shape wrote: post #41

Earlier quoted context omitted.

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 runn…

Could you run some kind of hybrid DHT where part of it was Webrtc and part was plain HTTP(S) / WebSocket? There are some nodes (desktop clients with UPNP, dedicated servers) that can accept browser connections. Those nodes could then help you exchange offers/answers to give you connections with the Webrtc-only ones, and those could facilitate offer/answer exchanges with their peers in turn. It'd be dog-slow compared…

That was you ask exists; it updates through a version counter. It just works on mainline DHT btw.
Post reply on HN