
WebRTC Chat on IPFS - david4096
https://ipfs.io/ipfs/QmNURh26yenpqK5hK3ahRZhQJsaUttumepjtRWiVZXhnN1/p/webrtc-ipfs-chat.html
======
jstanley
> 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.

~~~
boomlinde
_> 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.

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

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

~~~
boomlinde
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]](http://localhost:\[someport\]/ipfs/\[somehash\]).
With browser plugins you can also translate ipfs.io gateway URLs to your local
gateway.

~~~
disiplus
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

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

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

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

[https://beakerbrowser.com/](https://beakerbrowser.com/)

~~~
EGreg
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...](https://www.scuttlebutt.nz/stories/design-challenge-avoid-
centralization-and-singletons.html)

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

Responding to GP, you probably mean [https://github.com/cabal-
club/](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

------
asymmetric
> We can't expect each client to have an ipfs client installed.

Couldn't they serve [js-ipfs]([https://github.com/ipfs/js-
ipfs](https://github.com/ipfs/js-ipfs))?

AFAIK that would make every user of the web app run an IPFS node.

~~~
sillysaurus3
This was very interesting, but sadly: [https://github.com/ipfs/js-
ipfs/tree/master/examples/exchang...](https://github.com/ipfs/js-
ipfs/tree/master/examples/exchange-files-in-browser)

> 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](https://github.com/ipfs/js-
ipfs/pull/856/files)

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

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

------
realPubkey
What is used as STUN-Server for WebRtc?

~~~
niftich
The post makes it sound like it's a copy of
[https://github.com/cjb/serverless-webrtc](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 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...](https://github.com/cjb/serverless-
webrtc/blob/master/js/serverless-webrtc.js) [2]
[https://bugzilla.mozilla.org/show_bug.cgi?id=807494](https://bugzilla.mozilla.org/show_bug.cgi?id=807494)
[3]
[https://bugzilla.mozilla.org/show_bug.cgi?id=920991](https://bugzilla.mozilla.org/show_bug.cgi?id=920991)
[4]
[https://bugzilla.mozilla.org/show_bug.cgi?id=1143827](https://bugzilla.mozilla.org/show_bug.cgi?id=1143827)

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

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

------
xGnarRx
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_

------
yellowsir
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)

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

------
david4096
Please do head over to [https://github.com/cjb/serverless-
webrtc](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.

------
indescions_2018
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 ;)

~~~
EGreg
Compare to SAFE Network, which may be far more secure but also never seems to
launch their alpha :)

[https://maidsafe.net/docs/Safe%20Network%20Primer.pdf](https://maidsafe.net/docs/Safe%20Network%20Primer.pdf)

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

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

~~~
cjbprime
A few, e.g.
[https://github.com/EricssonResearch/openwebrtc](https://github.com/EricssonResearch/openwebrtc)

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

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

------
rhn_mk1
Is there a version implementing video connections?

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

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

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

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

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

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

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

~~~
viach
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?

~~~
jerf
"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.

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

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

~~~
viach
>> 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?

