Hacker News new | past | comments | ask | show | jobs | submit login
WebRTC Chat on IPFS (ipfs.io)
297 points by david4096 on June 8, 2018 | hide | past | web | favorite | 85 comments

> 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 centre, at least until we reach a point where every user is running an IPFS node without realising it.

> 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.

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

Well I was replying in the context of someone saying there is a meaningful difference to a gateway vs a node. If you access content via a gateway, your content is hosted by IPFS. The content gains all the benefits of IPFS, but you, the viewer, do not. However, if the IPFS Gateway works, ie it isn't throttling/blocked/etc, then you still get the content. I'm struggling to find a meaningful difference, is what I mean.

Now if everyone accessed the content via a gateway, then sure - that undermines the point of IPFS. But a gateway isn't inherently bad, nor is it worse in most respects than a local node - at least, to my understanding.

Thanks, yes as a community we need to address the problem of ipfs.io as a centralized DNS gateway. What happens if they don't pay their domain name registration fees?

ipfs companion is worthy of mention:


It converts ipfs.io to use your local resolver (amongst other cool things).

what? your comment is exactly wrong..

The content is being served by many peers on the network. You find the peers through a gateway - ipfs.io is one such gateway but any peer can also act as a gateway.

When you visit the page via ipfs.io you are viewing it via the ipfs.io gateway. The ipfs.io gateway has complete power to censor content, serve malicious content, etc.

You lose most of the benefits of IPFS if you browse via a gateway controlled by somebody else.

You don't find peers through a gateway. A gateway is literally just an IPFS<->HTTP gateway. The gateway does all the IPFS stuff and just serves content to you over normal HTTP.

> To that end, this demonstration requires you to transfer your offering using some other means, like an email or instant message.

While I appreciate the effort that went involved, the effort is identical to serving the app over S3. Without solving this problem with something like IPFS pubsub, there's nothing IPFS-specific about this. It's the hosting for a webapp and a use of browser-based code.

In short, this isn't WebRTC over IPFS.

I 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.


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...

Beaker doesn't act as a server, it uses Dat, which is very similar to SSB and IPFS. https://datprotocol.com

Responding to GP, you probably mean https://github.com/cabal-club/, which is a WIP and relies on some new protocol features not in Beaker yet, but usable in the CLI as I understand it

Really excited about scuttlebutt, will make a future post on it, thanks!

Maybe ipv6 or upnp helps?

I wanted to not reply to this... but I didnt.

> 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

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

But it just received an update 4 days ago! :)

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 '' 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 using a hostname in Firefox instead [3], and much later Firefox 41 removed [4] Mozilla's STUN servers from being defaults.

I'm not sure how one would go about confirming that this service is still pro bono and not malicious, and whether it's likely to stick around in the future.

[1] https://github.com/cjb/serverless-webrtc/blob/master/js/serv... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=807494 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=920991 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1143827

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.

Ethereum is trying to be a lot of things and has some pretty severe architectural problems. I bet the Mozilla stun server lasts longer.

Exactly, how is STUN not centralized in this solution??

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...

Too bad it isn't developed anymore. i already try to use it, but i was facing hard time with this lib.

You're basically attempting to manually exchange the ice handshake so there wouldn't be one here, although the demo gives me an empty offer so as is it doesn't seem to work to create a new chat on there.

Unless this only works on firefox, perhaps it doesn't work with chrome.

How did "Serverless" become the term for things hosted on servers all over the place?

And we already had DHT before serverless became a thing... sigh

i get an empty offer to copy and the following js error: Error adding stream to pc1: NotFoundError: The object can not be found here. (FF + local ipfs gateway)

I had to wait for a long time for the offer to show up. Post issues here! https://github.com/cjb/serverless-webrtc/issues

Please do head over to https://github.com/cjb/serverless-webrtc to make issues and PRs! The most painstaking part for me is how long it takes to get the offer in the first place without a useful dialog.

This 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 :)


the problem is signaling, i wanted to use ethereum for signaling but there is to much back and forth to establish a connection for it to be viable.

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.

A few, e.g. https://github.com/EricssonResearch/openwebrtc

Surprisingly large amount of dependencies in a conforming implementation. (e.g. SCTP for datachannels!)

Also it seems to have been decided that you have to use SCTP-in-UDP (RFC 6951) in order to get though firewalls, which is only implemented in FreeBSD so far, so an implementation will include a userspace SCTP library even if the operating system has it in the kernel as well.

Not that it will help you because it's not open source, but Edge probably doesn't use the same implementation as other browsers.

> it's not open source

I was wondering if it was. I am disappointed to hear that it is not :-(

Is there a version implementing video connections?

Can we stop calling everything "serverless"? It's a stupid name. I assume it means peer-to-peer here right?

This is the first time I read serverless in an appropriate context and still there are people complaining...

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.


So... a PaaS?

yep, just reversed now: SaaP... Serverless as a Platform

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.

It means that the price cannot be meaningfully quantified en masse, the price is set at the moment of purchase.

Art is a good example of this as it generally has no immediate utility, and even it cultural significance is created less by the piece itself, but rather by it's philosophical foundation which is not part of the purchase (nor even ownable).

The Mona Lisa may be 'priceless', but all the money in the world is just a lot of money.

'Distributed' just isn't exciting any more

People effectively map “server” to mean “centralization botteneck” or “Single Point Of Failure” these days. In both of those senses, this system is “serverless.”

Why do we need to keep inventing new terms, though? We have perfectly apt terms already, "decentralized" and "distributed", with much more exact meanings.

Well, "distributed, decentralized, peer-to-peer network" worked well enough, back when, to differentiate e.g. Kademlia from Napster.

But interestingly, people also called BitTorrent a "distributed, decentralized, peer-to-peer network", even though BitTorrent requires trackers. None of those adjectives allow the differentiation of the Kademlia design (a network of dumb nodes with smart, active clients that walk them) from the BitTorrent design (a network containing both dumb client nodes and smart server nodes, where the clients register with the servers.)

"Serverless" is the word for what Kademlia is and (pre-DHT) BitTorrent isn't. Or what differentiates a wireless mesh routing system from a 1980s BBS store-and-forward architecture. Or what differentiates IPFS from, say, the network consisting of all Lotus Notes clients + all Lotus Domino servers.

(The funny thing is that AWS Lambda is not "serverless" by this definition. AWS Lambda is just a PaaS with a CGI-alike ABI. Now, if Lambda was an ABI standard; and everyone ran a mesh of their own Lambda nodes; and your newly deployed Lambda function could end up running on any random node, without a first-class "server"/second-class "client" node separation; then that'd be "serverless." It'd also basically be Ethereum or Urbit or another of those wacky architectures, rather than Lambda any more.)

serverful, then?

Yes, or just nothing, as that's the default anyway.

It's still a stupid name.

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 <25ms and it scales up with your traffic directly. It's cheap for a web application served primarily from CDN with serverless for backend logic and easy entry to using other AWS services with secure access per function. Starting a web app through serverless would be insanely cheap barrier to entry with serverless considering you only pay for processing time.

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.

Yes, I second this.

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. 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.

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?

"My original comment was a little bit sarcastic, but seriously - why not?"

Because in engineering, the question is not "why not", but "why". Blockchains are not the default answer. What positive virtue is blockchain going to bring to your IM system that is not better attained by a non-blockchain-based solution?

If you can answer that, great. I'm not saying this has no answer. I'm just saying it's the real question.

If you are going to say the word "federated", then from what I can see, trying to do "blockchain" at that point isn't all that helpful and likely to be worse and harder than just trying to develop a federated system, a sufficient challenge on its own that doesn't strike me as greatly helped by "blockchains". XMPP already does federated IM, since long before the current fad.

I match any vague handwaves about identity or security with vague handwaves at existing SSL certificate authorities, and an observation that if you're going to complain about the security of such things I get to apply an equal amount of effort towards breaking your blockchain solution, e.g., if you're going to complain about nationstates getting root certificates they shouldn't, I get to point out your tiny little blockchain for IMs is equally vulnerable, if not more so.

Thank you, great comment, excellent points. I'm not discussing here nation-state certificate ledgers vs my small miserable blockchain, but instead an instance of a federated (say, XMPP) network server vs blockchain based solution. From my point of view, on this level, it provides more security and, what is more important , incentives to run such a thing.

A blockchain-based solution to what, though? Bearing in mind the XMPP network exists now, and works. (It may not be "winning", but it works.) What is even the problem?

Though I will concede your point slightly; if XMPP needs some more Hype Juice to win, I can't deny "but on a blockchain!" could help there. Kinda not being sarcastic here.

>> A blockchain-based solution to what, though?

To the declining popularity of Jabber, to put it short.

As an additional benefit, blockchain is indeed more secure to run than an ejabberd instance.

I understand your irony with "Hype Juice" etc. But in the end, good software is that which people use, right?

I think that was sarcasm, given that “serverless” is a pretty trendy term, just like “blockchain”.

Chat on IPFS is a good idea, though.

There's a bunch of these things, regrettably.

For example, could you please provide at least 3 (a bunch) examples which are in production?

I don't think there are any 3 that are exactly what you ask about ("chat-on-blockchain thing").

However, from my understanding of Telegram's ICO and "leaked" roadmap, they appear to be doing a decentralized chat the may leverage their own blockchain for some features (identity, tokens etc.).

I think Status.im is another example, but it's currently early access I believe.

My own product, stealthy.im could be another example. The web product is in production. It builds upon blockstack, storing identity and storage pointers in the blockchain.

So that's 3. I could probably list a few more, but again they wouldn't strictly satisfy your precise criteria in one or major ways. I think @jerf's response is really good--for us the "why" of blockchain is in identity and providing a verifiable decentralized storage network through blockstack. The underlying bitcoin blockchain wouldn't be suitable for message storage or sdp handshaking due to latency as another person pointed out.

I don't really keep track of those things, but I can give you two attempts without much searching:

just this week I saw https://adamant.im

There was a thing called "my echo" (which appears to have failed/been cancelled).

Thank you for providing an example. It's not a "bunch" but still. Could you explain why did you use word "regrettably", is it a bad thing these projects exists?

I think @detaro says 'regrettably' because of the distaste many have about ICOs and the hype related to them. However, I too would like to hear from @detaro on this.

Pretty much, yeah: pushing actual messaging over a blockchain is just horribly inefficient and I don't see it being a workable idea, so it seems dishonest to me to widely promote it and collect money for it.

Other related things are fine: e.g. mapping public keys to human-readable identifiers like a nickname is a good match to what a blockchain is good at, I get why people like the idea of cryptocoin-payments in a messenger platform, ... Still leaves the general concern of "does this really need it's own coin with an ICO and hype", but at least the ideas make some sense there.

We have built a chat application with blockchain for auth that uses decentralized storage to enable WebRTC: https://www.stealthy.im.

There are several projects for that of course. ZenCash is one of them. I run 5 ZenCash masternodes, so it works, but it's a resource hog and it's really not fast.

> Sounds like an obvious idea for an ICO

I hate this mindset


Poe’s law caused you to be downvoted on HN, sir

Yup, but I think it's a good deal - to lose some points but have an interesting discussion.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact