Hacker News Reader

> Which means, if there's a new type of technology that lets people do just that--set up their own server anywhere and make it accessible via HTTP--then I don't see why we really need IPFS

I have a ton to say here, but I'll keep it to a few point. Tor onion services solve the setup-your-own-server issues, it's just not super easy yet. IPFS is needed regardless, because there is a need to distribute things when your machine isn't up and to solve discovery. What IPFS doesn't have natively is anonymity (tho there are onion transports conforming to libp2p transport iface) and distributed compute, but neither is that important.

> Tor onion services solve the setup-your-own-server issues, it's just not super easy yet.

Lately I've been trying to make this easier. I developed ormesh (https://github.com/cmars/ormesh) in an attempt to simplify setting up hidden services for private use.

I think both Tor and IPFS are both awesome and useful decentralization projects, they just have different use cases & characteristics. AIUI IPFS lacks fine-grained access controls. Last time I looked, it seemed like I either had to run all my own infrastructure of IPFS nodes with pre-shared private keys, or open everything to the public and encrypt on top of that... I prefer the Tor hidden service model, where I can decide on a per-service basis how I want to share it, revoke client access if necessary, and have my traffic securely routed on existing infrastructure.

Edit: fixed link

Saw this on /r/golang (I was the one asking why the full Tor browser). I have considered similar [0]. A simple service (or portable exe) that has Tor statically linked and lets you reach/manage a machine from anywhere (think webmin-like web console on onion service) would have real value. Of course it can be authenticated and have the option to open direct connection (webrtc?) if you need fast media playing or direct download.

0 - https://github.com/cretz/software-ideas/issues/54

This is my first time discovering IPFS, so pardon if this my question is obvious/addressed elsewhere.

At what point does the "network" become too small. I.e. if your computer can only reach 10,000 devices... are those 10,000 devices supposed to be able to have access to all data for the entire world? (albeit out of date)

The scenario I'm thinking of here is similar to if Alaska suddenly got cut off from the rest of the world for a week, month, year.

Weird to see Tor as a connectivity solution. I guess if you really don't care about performance.

At the least it's a good NAT buster for signalling. May be able to piggy back a direct connection off of it (using it for just STUN-like reasons) but of course the increased performance of a direct connection comes at the cost of anonymity.

There are lots of better NAT busters that are way faster and more versatile.

Of course I'm partial because I made one: https://www.zerotier.com/

There are others ways too like libp2p, webrtc, etc.

Tor is an anonymity layer. By definition this requires worst case routing and artificially added latency, since if latency is low you can triangulate. Anonymity and efficient direct connectivity are antagonistic goals in a system.

More of an addendum than a correction, the Akasha project is an ETH & IPFS project that looks interesting https://akasha.world/

What can you do with Akasha from the FAQ "You can publish, share and vote for entries, similar to Medium and other modern publishing platforms, with the difference that your content is actually published over a decentralized network rather than on our servers."

Blog-ish websites are unreliable even when they have real hosting. If you put it on someone's laptop it gets so much worse. To me, the reliability boost is the killer feature of IPFS.

> You don't really need a globally addressable immutable file storage, because unless you're dealing with static images, a lot of files DO change all the time, and people want to store and share files privately.

While it boosts reliability, IPFS is not globally immutable. If you share a file with a limited scope, it won't stick around forever.

Though from a quick search you can't easily keep a file private, that's not great.

you can just store an encrypted file or archive

You can, but the whole thing is built on ease of use, and you don't get ease of use if you have to manually encrypt your selfies.

In a forward-secure manner?

If your app is hosted on github, it is not really distributed. And Ethereum is extremely limited as a database.

Exactly, IPFS allows data storage and retrieval for Dapps to also be done through a decentralized network. That's the whole point of a D-app, not falling back on someone's central servers. The performance and scalability limitations of Ethereum make it virtually unusable as a database, application data definitely needs to be taken off-chain.

Also, the IPFS system contains IPNS, which allows users to host mutable content. Rather than navigating to the hash of a file, you're retrieving what's been signed by the publisher's key. So it's more flexible than just static content.

Just to be clear, this is exactly what I thought when I first started working on DApps. But the more I get into it the more I realize there's a blurry line in there a lot of people don't even think about.

I know it's cool to build completely decentralized apps, but let's ask WHY you're trying to build a completely decentralized app.

Chances are you're trying to make sure that what users do on the app is never censorable.

If you're trying to build a decentralized app where EVEYRY asset must be unstoppable, then you need IPFS. For example million dollar homepage kind of app.

But I think those are niche cases and for most decentralized apps, the more important part is the actual transaction ledger. I don't really care if my profile image next to my transaction history stays on IPFS forever, in fact I don't want it to be permanent. I would rather have it be deletable if I wanted to. All I care about is that I own certain asset or have control over certain actions through my private key.

I think a lot of DApp developers are missing the point in this regard, trying so hard to make everything "100% decentralized" for the sake of being decentralized, while sacrificing user experience, not to mention the fact that users may actually NOT want their assets to be permanent (they only care about transaction being permanent).

Yes I know what IPNS is, but I think by now you get my point. It's not about being able to have an address to refer to multiple versions, but the question about "do users want immutability for that?"

Most people don't want their own server. Consider the person whose only computer is a phone. (That's, for example, most people in Japan; most people in the West under 15; etc.) Do they want to serve documents from their phone? No, because their phone doesn't have an always-on high-upload-bandwidth internet connection!

Only certain computers make good servers. It's more likely that everyone will get an automatic slice of a good server somewhere (i.e. the ISP-hosted "cloudlets" concept—your phone can launch edge-hosted VMs as if they were threads) than that people will suddenly, after all this time, start wanting to host things directly on their crap low-availability hardware.

> Most people don't want their own server.

Yes and No.

It is true people don't want their own server because it's too much hassle to set up and maintain, with not much upside.

But we've never actually experienced this so nobody really knows whether people will want this or not. Nobody knew we needed a touch screen phone that works as a computer either. You can only tell AFTER such a thing becomes available.

> No, because their phone doesn't have an always-on high-upload-bandwidth internet connection!

This is exactly the infrastructure problem I was talking about. It has nothing to do with the hardware ability itself. In case you're still thinking your iPhone is a crappy computer, No, the iPhone in your pocket is already performant enough to function as a full fledged server. It's the network that doesn't support it.

> It's more likely that everyone will get an automatic slice of a good server somewhere

Unless this comes as completely free AND it comes built into the device, people won't likely jump onto using something like this because there are free alternatives.

If you think about it, every iPhone user owns their "own cloud" (iCloud). This was unthinkable several years ago. Same thing may happen when people can have servers running on their own devices.

My point was, if the infrastructure can evolve to match the type of things devices can already do, all mobile devices will suddenly turn into p2p devices overnight. And a lot of powerful things can happen.

> In case you're still thinking your iPhone is a crappy computer, No, the iPhone in your pocket is already performant enough to function as a full fledged server. It's the network that doesn't support it.

A crappy computer, no; a crappy server, yes. The available network is part of a server. A URL that points to a machine that can't be accessed whenever the owner goes into a tunnel, is a URL nobody will link to.

(Another part of the evaluation of "a server" is the available concurrent I/O throughput. There is a reason the term "slashdotted" exists, and thinking an iPhone—or even a home PC—makes a good server for serving anything with any exponential-interest-curve potential is it. This is also the reason why nobody has built the sequel to Iridium using cube-sats.)

> Unless this comes as completely free AND it comes built into the device

Yes, that's exactly the future that cloudlet advocates like IBM are talking about:

1. the ISPs run compute clusters at the edge, including both setting up traditional co-los, and making their in-home gateway modems into compute hosts as well;

2. the device/"cloud" providers (Apple, Google, etc.) make agreements with said ISPs to pay for time on those edge-clouds;

3. the device/"cloud" providers resell (possibly at a loss, to encourage lock-in) the use of the aggregate edge-cloud to the app developers on their platforms; or, they let developers use the edge-cloud in their apps for free, and pass the costs onto only heavy users, the same way they do with document storage today;

4. the users of these devices suddenly have cloudlet-enabled apps, and most don't have to pay a cent more.

Amusingly, you can already see that the device/"cloud" providers are trying to short-circuit this whole process, skipping the ISP step, by simply selling people consumer-electronics devices that could sit in their homes, connected to ZeroTier-like overlay networks, hosting mobile cloudlets. You know, like the Google Home and Amazon Echo.

> A crappy computer, no; a crappy server, yes. The available network is part of a server. A URL that points to a machine that can't be accessed whenever the owner goes into a tunnel, is a URL nobody will link to.

This is one of the very points that IPFS tries to address: decoupling content from location, so that additional copies of the same content in different locations of the network can actually strengthen the content's availability, instead of being non-addressable and thus wasted.

Works if you're serving a static webpage; doesn't work if you're serving, say, a private chatroom. This is what decentralized execution environments like Ethereum seek to solve, but running an Ethereum node on your phone is not the same thing as actually serving a private chatroom from your phone. In fact, Ethereum is much closer to the cloudlet side of the spectrum of solutions, insofar as your client (the phone) is just sending commands to a computer "somewhere else" (in this case, ~everywhere) that then acts as the server.

Works with IPFS if you use Pubsub, cryptographic capabilities, and CRDTs :) Check out PeerPad: https://peerpad.net

edit: what I also meant to say is, a chat room doesn't need computation (although there certainly use cases that do)

I see a lot of people here making the mistake of thinking that IPFS is a file storage system that splits up content among a decentralized, shared network when it's not. If I have a file and "store" it on IPFS - that file sits on my own machine indefinitely. You would think that a project called “Interplanetary File System” would be able to store some data... but nope. Instead, files in IPFS are only ever distributed to other hosts if they express interest in that content, and they are mirrored only if their clients have been setup to seed that content.

IPFS in that sense is more like Bittorrent in that it doesn't magically guarantee data will be available. That is the reason why you see so many “decentralized” systems using IPFS that suck. Because the moment data is “stored” in Interplanetary “File System”, the user thinks they can close the application and the data will still be there.... Guess why there are so many stores on OpenBazaar that are inaccessible at the moment ;)

The reason why so many Ethereum developers are using IPFS is because these developers typically have no clue what they're doing. They're the kind of developers whose introduction to blockchains came in the form of an artificially-imposed toy sandpit and now they think that blockchain engineering consists of being able to build towers out of blocks built by other people. They cannot build anything new for themselves, and if they understood how any of the existing components worked they probably wouldn't use them... But they don't.

After doing some tests, IPFS seems to run their own caching servers that automatically cache content retrieved from the network via their servers. So I am guessing that “dapp developers” are “optimizing” their code to use these servers, or are making requests to these servers in tests and then assuming that IPFS is a magic data store that gives them infinite decentralized, scalable storage space for no cost.... I mean, economically that is already impossible. But even if it could technically do that, ask yourself what Filecoin is suppose to be for?

On the topic of Filecoin, it's a complete disaster and the paper linked in the OP doesn't cover any of the main technical problems. What this paper fails to address is how unreliable time-lock encryption is as a timing function for anything given that its impossible to know how much serial computational power an attacker has available. That already defeats most of the claims made around Filecoin's absurdly inefficient and impossible to verify “proof-of-spacetime” algorithm.

The other thing that none of these papers addresses is how an auction market is fundamentally at odds to the needs of a cryptoeconomic system. The problem is that with no way to regulate the supply of storage space, it naturally leads to more people wanting to sell what they have then there is demand for it (which will crash the price of the storage space.)

If hosts cannot remain profitable by playing fairly then the only option left is to cheat. This is actually the opposite to how blockchains work as they strictly control the supply to maintain a healthy security-cost ratio (technically there is only ever 1 Bitcoin whose scarcity is maintained via a growing proof-of-work. The “bit” comes from the virtually fragmented sub-coins, but there is only ever 1 Bitcoin.)

Tl; dr: Interplanetary File System can only do distribution and cannot actually store files; And Filecoin isn't really a coin at all since the supply is indeterminate and it functions more like an exchange for contracts than a currency. The Protocol Lab guys sure know how to bullshit people though, I'll give them that much.

> if there's a new type of technology that lets people do just that--set up their own server anywhere and make it accessible via HTTP--then I don't see why we really need IPFS

> In my opinion, the reason IPFS is so hot nowadays is because it's riding the DApps wave where people want to build Ethereum apps with IPFS as a file storage.

Whilst I enjoy reading and learning about dapps, blockchains, etc. they seem very niche at this point: it can be argued whether or not bitcoin is "mainstream" (many have heard of it, but how many have or use it, compared to e.g. bank accounts), but ethereum is even more niche in comparison; using dapps is presumably rather niche even in the ethereum world, compared to those simply speculating on ether or making pump-and-dump ICOs; those building dapps would be even more niche; those building dapps with IPFS for distributed file storage would be a niche part of that.

I don't think this is what's driving IPFS.

However, I do come across many potential uses of IPFS every day.

Whenever I see a broken link, especially for some old informational site or tarball or whatever, and Googling for an alternative link just brings up more and more of the same broken link, it makes me wish IPFS were around (most recent example: http://easyldap.exofire.net/files/installer/easyldap-install... )

Likewise, whenever I find myself writing a URL into a file, e.g. a source tarball for a Linux package, I want to use an IPFS hash instead (IPFS is hopefully coming to Nix at some point https://github.com/NixOS/nix/issues/859 ).

In the latter case, I could add these files to IPFS myself, but I'd probably be the only one using it, and I'm usually less reliable than those canonical HTTP URLs, so those hashes would likely disappear sooner than the HTTP ones.

I have high hopes for IPFS. At one point I thought magnet URLs might solve this. I was pleased when kio-magnet allowed KDE to browse Web sites via magnet links, but even the blog post announcing that seems to be no more :( https://www.reddit.com/r/linux/comments/ew0y4/kiomagnet_what...

I met Juan back in 2014, where us (Feross, Substack, Max Ogden, Mafintosh, and others) all showed off our P2P projects. How times have changed since then!

I can attest to the usefulness of Filecoin. But I do think you are right in that IPFS is for immutable file/asset storage, and not as efficient for mutable data. David, one of the core teams at IPFS, reached out to me the other week about how CRDTs on top of IPFS can fix that. That is what we have solved, mutable graph data that can update in realtime or offline, across a ad-hoc mesh network.

IPFS is still critical here though, because using our Radix Storage Engine (just released) adapter, we can batch high volume mutable data to disk (aka IPFS) for storage and retrieval, which once fetched gun kicks back into gear and does sync.

Ethereum is just not at this scale yet, last I heard it was doing about 7 transactions per second (and Bitcoin doing 4). We're doing 2K end-to-end (across a 4 peer network hop) table inserts/second! I demo this on stage here: https://youtu.be/nTbUCTgLmkY

In that talk, I also explain how to do load testing across a distributed system in order to verify its correctness, aka do simulations on failures like with Kyle Kingsbury's (Aphyr) Jepsen Tests.

So while Filecoin isn't ready yet, its market cap represents a massive emerging opportunity. If Uber unicorn-ed crowdsourced transportation, imagine what a truly P2P incentivized crowdsourced storage system could do. Remember, all machines need electricity (Bitcoin), computation (Ethereum), storage (filecoin), and bandwidth (what we're tackling, with data sync, and incentives).

If you look at it in that context, it makes sense. Hopefully the crypto-P2P community will deliver :) to keep up with the demand. Cheers!

Looking at my dropbox, <1% of files have been updated in the past year. So your premise that a lot of files change over time may not be correct.

Also, you started by warning against uninformed comments about BTC but your comment on FC seems uninformed itself - especially the last 2 paragraphs which go into hardcore speculation category.

Feel free to tell me what I got wrong then. There's a difference between informed speculation and uninformed. Uninformed speculators draw conclusions from what they heard elsewhere. I tend to think I drew the conclusion as independently as I can.

I've thought a lot about this problem so I don't think I'm uninformed about this matter. This is not to say I'm right, and as I mentioned, I would love to be corrected, which was the reason why I posted the comment to begin with.

But just saying "you're uninformed yourself" doesn't help anyone.

Also I said:

> a lot of files DO change all the time, and people want to store and share files privately.

Unless you really think IPFS should be compared to Dropbox, your comment about your dropbox usage is irrelevant to this thread. I'll assume that you are aware IPFS is completely public by default and dropbox is for private usage by default (although you could use it for public sharing, it's not the intended usage for dropbox). The closest you can compare IPFS to is on S3 level, not dropbox level.

Why do they need their own server? What's wrong with Dropbox, Google Drive, et al? Or, what's wrong with the network drives from Seagate and WD that will let you access those files remotely (aside from the fact that they do cost money)?