Live data from Hacker News

WebRTC Chat on IPFS

ipfs.io

41–50 of 90 posts

Re: WebRTC Chat on IPFS

#41
post #37
post #18

Interesting, why there is still no chat-on-blockchain thing. Sounds like an obvious idea for an ICO.

If you actually put the content of the messages on the blockchain itself it'll become ridiculously expensive really fast. Furthermore if you actually wait until a message gets mined to be accepted it's not going to be exactly "instant" messaging. What would be the point anyway? A dedicated peer-to-peer messaging network that doesn't need to keep track of the entire history of everything seems much more appropriate. I…

My original comment was a little bit sarcastic, but seriously - why not? I understand that a single blockchain will not handle global scale messaging. But a set of federated installations, could that work?

Re: WebRTC Chat on IPFS

#42
post #7

Earlier quoted context omitted.

It's serverless in that there is no specific server running it. The website is distributed across Ipfs and the chat is peer-to-peer.

I don't know man, when we say "defenseless", we mean it has no defense. "Useless", it has no use. We don't mean "it has so many uses that you can't really pick one". That would be "useful", I guess, which is pretty much the opposite.

"Priceless" has so much price that you can't pick up one.

Re: WebRTC Chat on IPFS

#43

Earlier quoted context omitted.

It's used now as official term on AWS and probably other clouds as well. Its the new hot thing since you don't need to provision any servers or infrastructure. All you do is write code and deploy it to a cloud platform. And it's much much cheaper as well. So yeah it's a dumb term but it's here to stay. :)

Cheaper? I have no idea what running a particular app would cost. The ridiculously fine grained way in which the big IaaS providers charge for their services is a major reason why I'm avoiding them whenever I can. It's just too risky, too complex and too brittle. Any tiny change can have huge cost implications.

From what I've read if you had a single instance of a lambda function running 24/7 it's still cheaper than the micro EC2 instance. You have warm-up time on initial requests if the functions been idle for awhile, but otherwise the response time is fairly quick Whether this works well depends largely on the architecture of the application and if it's done right. You can absolutely have a serverless application that would be much better served with elastic beanstalk or ECS perhaps but to say serverless is useless or too expensive all around is not true.

Re: WebRTC Chat on IPFS

#44

> We can't expect each client to have an ipfs client installed. Couldn't they serve [js-ipfs]( https://github.com/ipfs/js-ipfs )? AFAIK that would make every user of the web app run an IPFS node.

This was very interesting, but sadly: https://github.com/ipfs/js-ipfs/tree/master/examples/exchang...

> Note: As js-ipfs@0.29.0 currently doesn't support DHT peer discovery, the peer from which you are fetching data should be within the reach (local or in public IP) of the browser node.

The PR to implement DHT has been languishing since May 2017: https://github.com/ipfs/js-ipfs/pull/856/files

Re: WebRTC Chat on IPFS

#45

Earlier quoted context omitted.

> This is a strange way of saying "you're looking at this site through one centralised server hosted at ipfs.io". No, your rephrasing is completely orthogonal to what they're saying. Both are true. Seems like dishonest nitpicking to me to say that they obscure the difference between a gateway and a node.

Besides, aren't all nodes basically a gateway? Ie, a gateway is effectively just a readonly node on an accessible IP. Any node could be this if not bound the local net.

sure, but practically probably not, because you would need a domain and a easy way to update it + a cert + thats assuming you are not behind some sort of a NAT and have your own IP.

Re: WebRTC Chat on IPFS

#46

Earlier quoted context omitted.

> This is a strange way of saying "you're looking at this site through one centralised server hosted at ipfs.io". No, your rephrasing is completely orthogonal to what they're saying. Both are true. Seems like dishonest nitpicking to me to say that they obscure the difference between a gateway and a node.

Besides, aren't all nodes basically a gateway? Ie, a gateway is effectively just a readonly node on an accessible IP. Any node could be this if not bound the local net.

I think all gateways are nodes, but a node can at least disable the gateway.

Re: WebRTC Chat on IPFS

#47

Earlier quoted context omitted.

Besides, aren't all nodes basically a gateway? Ie, a gateway is effectively just a readonly node on an accessible IP. Any node could be this if not bound the local net.

sure, but practically probably not, because you would need a domain and a easy way to update it + a cert + thats assuming you are not behind some sort of a NAT and have your own IP.

You don't need a certificate and a domain to run a gateway. For a public gateway, sure, that's desirable (though not strictly required), but for a private gateway (that most nodes are probably running anyway) you really don't need any of that. At home I can just go to http://localhost:[someport]/ipfs/[somehash]. With browser plugins you can also translate ipfs.io gateway URLs to your local gateway.

Re: WebRTC Chat on IPFS

#48
post #10

What is used as STUN-Server for WebRtc?

The post makes it sound like it's a copy of https://github.com/cjb/serverless-webrtc uploaded to IPFS; examining the code [1] shows that '23.21.150.121' is hardcoded for STUN. This was seemingly set up by Wesley Dawson [2] at Mozilla in 2013, at which point it was an EC2 machine in AWS us-east-1. It subsequently made it into various gists and projects as a public STUN server. Later in 2013 Mozilla changed over to usi…

A single hard-coded STUN server is a big face-palm for a "serverless" chat app. `ipfs.io` could at least host their own STUN server. As long as they disable TURN, it shouldn't require much bandwidth. It's not like very many people are actually going to actually use this...

Re: WebRTC Chat on IPFS

#49

Earlier quoted context omitted.

sure, but practically probably not, because you would need a domain and a easy way to update it + a cert + thats assuming you are not behind some sort of a NAT and have your own IP.

You don't need a certificate and a domain to run a gateway. For a public gateway, sure, that's desirable (though not strictly required), but for a private gateway (that most nodes are probably running anyway) you really don't need any of that. At home I can just go to http://localhost:[someport]/ipfs/[somehash] . With browser plugins you can also translate ipfs.io gateway URLs to your local gateway.

im talking about somebody that does not run a node accessing it via "old internet", im assuming the OP has this in mind with his comment

Re: WebRTC Chat on IPFS

#50
As a browser author, are there any alternate implementations of WebRTC besides the one all of the browsers use?

From my research I was kind of shocked that the answer might be no.

Post reply on HN