WebRTC Chat on IPFS
ipfs.io
ipfs.io
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.
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.
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.
ipfs companion is worthy of mention:
https://addons.mozilla.org/en-US/firefox/addon/ipfs-companio...
It converts ipfs.io to use your local resolver (amongst other cool things).
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.
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.
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.
Read this: https://www.scuttlebutt.nz/stories/design-challenge-avoid-ce...
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
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.
> 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
But it just received an update 4 days ago! :)
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
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.
And we already had DHT before serverless became a thing... sigh
From my research I was kind of shocked that the answer might be no.
Surprisingly large amount of dependencies in a conforming implementation. (e.g. SCTP for datachannels!)
I was wondering if it was. I am disappointed to hear that it is not :-(
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.
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.
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.)
So yeah it's a dumb term but it's here to stay. :)
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.
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.
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.
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.
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?
Chat on IPFS is a good idea, though.
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.
just this week I saw https://adamant.im
There was a thing called "my echo" (which appears to have failed/been cancelled).
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.
I hate this mindset