61–70 of 72 posts
* non js enabled clients can see the page, think robots, SEO, etc.
* js enabled clients can help to perpetuate the content
* if the last js enable client had a network glitch, the content is still available.
Curious how long this page has been up for at this point. Since 2015?
I can vouch that it has been up at least that long.
Earlier quoted context omitted.
A building does not exist until the materials sitting at the site are assembled. Same principle applies to dynamic webpages.
But what if the materials are assembled "automatically" every time someone tries to enter the building :D
A dynamic page is not assembled until the HTTP request (i.e external) sets things in motion.
> Imagine essentially an archival service where all kinds of content (web pages, mp3s, videos, etc) are indexed according to their SHA-256. Isn't that pretty much what IPFS is?
It's not specific to IPFS. Arguably, it's also what bittorrent does.
Oh, wow. I didn't expect to see this on HN today. This was a toy app I wrote to learn a bit more about Elixir, Phoenix, and Phoenix's concept "channels" (websockets). I submitted it a long time ago to HN. I wrote a bit more about it on my blog: http://gabe.durazo.us/tech/ephemeral-p2p-project/ (wow, I need to update my blog). Unfortunately, it's not really that p2p, contrary to the name. There's a server running on h…
Some people really want this to live forever. Or they're just that bad about closing old tabs. Both options are fun to think about.
Thanks for keeping this going!
Oh, wow. I didn't expect to see this on HN today. This was a toy app I wrote to learn a bit more about Elixir, Phoenix, and Phoenix's concept "channels" (websockets). I submitted it a long time ago to HN. I wrote a bit more about it on my blog: http://gabe.durazo.us/tech/ephemeral-p2p-project/ (wow, I need to update my blog). Unfortunately, it's not really that p2p, contrary to the name. There's a server running on h…
I love love love these kinds of experiments. Reminds me of the Early Web. I really wish WebRTC was easier to use. I wish there were some good faith free servers to do the… crap I forget the acronyms… the STUN and TURN stuff and whatnot to negotiate the connections. Ie. Not a proxy, just an operator. Having one I could use freely and comfortably would trivialize a lot of neat projects, particularly fun little multipla…
I recently learned you can do the candidate server exchange without those servers. There was an implementation which used [this]( https://github.com/cjb/serverless-webrtc ) as a backend and a QR code to do the transfer. I can't seem to find it now. However they were having issues with the QR code reaching its size limit, leading to the question of whether you could break the message into a series of qr codes. Pretty…
The main idea in removing the signaling server is to somehow transfer the session description between clients e.g. one client scans a qr code that encodes the session description of another or sending session description through some existing chat application and allowing a user to enter it manually instead of having your own server do the transfer over some mechanism.
Also it may be possible to avoid the multiple qr code thing this blog is talking about (qr code per ice candidate) if you just wait for the ice gathering state to be complete then send the session description, though they are correct that the session description in its entirety will most likely exceed the qr code capacity (coincidentally they use LZ compression in an attempt to lower the length, similar to what I tried long ago though I ended up deciding it wasn't worth it).
It also means that pages can never be updated without sharing a new link. So typos like "permament" are there forever (ever.. ever)