Earlier quoted context omitted.
There's a bunch of these things, regrettably.
For example, could you please provide at least 3 (a bunch) examples which are in production?
WebRTC Chat on IPFS
31–40 of 90 posts
Re: WebRTC Chat on IPFS
#32This has potential. In peer brokering at scale, its the individual state of each peer that has to be mediated. The classic "LimeWire" problem. Just wondering as a peer, how much of my metadata gets leaked? Simply determining when or where I am chatting may be enough to de-anonymize me ;)
Compare to SAFE Network, which may be far more secure but also never seems to launch their alpha :)
Re: WebRTC Chat on IPFS
#33> That means the "servers" hosting it are distributed across a wide network. This is a strange way of saying "you're looking at this site through one centralised server hosted at ipfs.io". Don't get me wrong, IPFS is great. I have released an application that works over IPFS. But I don't think obscuring the difference between a gateway and a node is beneficial. I think the difference needs to be highlighted front and…
> 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.
Re: WebRTC Chat on IPFS
#34I wanted to write that there is another similar project based on Beaker Browser (P2P) browser, that uses dat protocol and direct streaming to another browser... but I can't find it. https://beakerbrowser.com/
I never understood how Beaker browser can act as a server listening on a port. It sounds like you always need relays on the internet because your router and ISP is gonna block all ports unless requested not to.
Read this: https://www.scuttlebutt.nz/stories/design-challenge-avoid-ce...
Re: WebRTC Chat on IPFS
#35Earlier quoted context omitted.
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…
Thanks for that informative answer. So we have a serverless web-chat with a stun-server that might go offline at any time. I don't know a solution to do the chat really serverless. One option would be to use ethereums whisper, so we can use all eth-nodes to handle the webrtc-connection. This would not be 'really' serverless but at least surely work for a long time.
Exactly, how is STUN not centralized in this solution??
Re: WebRTC Chat on IPFS
#36Re: WebRTC Chat on IPFS
#37Interesting, 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. IRC comes close to that with its federated architecture, although I suppose a completely seemless bittorent-like peer-to-peer chat using public key cryptography for message authentication could be pretty great.
Re: WebRTC Chat on IPFS
#38Interesting, 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…
I think that was sarcasm, given that “serverless” is a pretty trendy term, just like “blockchain”.
Chat on IPFS is a good idea, though.
Re: WebRTC Chat on IPFS
#39Can we stop calling everything "serverless"? It's a stupid name. I assume it means peer-to-peer here right?
No it doesn't mean peer-to-peer here. It means that there is no one server but a lot and in fact the 'server' is abstracted away from the developer so he sees no server (serverless).
I think Wikipedia has a nice explanation of the term:
Serverless computing is a cloud-computing execution model in which the cloud provider dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.[1] It is a form of utility computing.
Serverless computing still requires servers, hence it's a misnomer.[1] The name "serverless computing" is used because the server management and capacity planning decisions are completely hidden from the developer or operator. Serverless code can be used in conjunction with code deployed in traditional styles, such as microservices. Alternatively, applications can be written to be purely serverless and use no provisioned servers at all.
Re: WebRTC Chat on IPFS
#40Earlier 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.
'Distributed' just isn't exciting any more