> 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.
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.
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?
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.
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.
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
> 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 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 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.
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.
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...
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.
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)
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 ;)
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.