IPFS Blog

Saying there's "no business value" in tools coming out of this space/building on IPFS is nonsense. Sure, the vast majority of people won't care about using a tool because it's decentralized in and of itself, but they _will_ choose tools that give them features they care about - like working better offline, having faster downloads/uploads, being more reliable and trustworthy, preserving their agency and control, etc. These implications from building a distributed system (ex able to collaborate when disconnected from central servers) are strong business reasons for folks to use one service over another, but that isn't clear from saying "it's decentralized". Look at Netflix using IPFS for faster container image distribution (business value: more productive developers - https://blog.ipfs.io/2020-02-14-improved-bitswap-for-container-distribution/), Audius & Matters.news using IPFS to give content creators more ownership over their own data, Berty & OpenBazaar using IPFS for private messaging/marketplaces -- clearly there is business value in removing middle-men/central points of failure & control in these applications.

You absolutely can incentivize others to pin content. Check out Infura (infura.io), Pinata (pinata.cloud), Temporal (temporal.cloud), and Eternum (eternum.io) - these are all services you can pay to host your IPFS data with reasonable uptime. They have an incentive to keep your content around because you pay them to. Filecoin is a distributed solution to that (and…

(Disclosure: I work for the Filecoin Foundation/Filecoin Foundation for the Decentralized Web).

I do actually agree that the privacy and anonymity aspects of IPFS are not well- conveyed. I think people get hooked on the "censorship-resistant" nature of decentralized systems, without understanding that even if you have multiple sources, for instance in a content-addressable network like IPFS, aggressive censorship systems have other strategies to dissuade dissemination or punish readers. You always have to be thinking a few steps ahead. Services like Tor and, I hope, the IPFS network both try to convey what threat models they are useful for, and which they are not, but it's really hard to stop overenthusiastic re-statements that give them super-powers they do not, in fact, possess.

That said, there's a bunch of careful thinking right now going on about how IPFS's privacy story could be improved: https://blog.ipfs.tech/ipfs-ping-2022-recap/ has a couple of sessions on this, and is a great summary of some other recent developments in the space.

One of those improvements is in the point about nodes being high CPU, RAM, etc. (I actually find this to be more of a challenge when running the full IPFS Go node locally on my desktop, rather than on a VPS; it requires some tweaking.)

The strategy right now is to encourage more implementations of IPFS to cover more use-cases; the original go-ipfs had to do everything, including maintaining some legacy decisions. Nowadays, there's a…

Matrix mitigates the threat of a hub & spoke model by not being hub & spoke (particularly in P2P!) :)

> I am not sure that spanning trees or gossip protocols solve the problem I'm describing, but, if they do, I'd appreciate if you could elucidate further.

Perhaps the confusion here is the expression "hub and spoke" which sounds to me like a static centralised star topology routing model.

My point is that if you have 1M nodes trying to share data (e.g. follow a celebrity's personal pubsub topic), you clearly need a smarter routing algorithm than full mesh (where the celeb's node would have to do 1M parallel pokes to send its messages). You're completely right that one solution is a hub-and-spoke model (where the celeb's node would poke a big centralised hub somewhere, which would then relay the poke out to 1M followers on spokes) - but as you point out, the hub becomes a centralised chokepoint of failure/control/privacy-violation etc.

So, the main other options I'm aware of are either to arrange your 1M nodes into a spanning tree (or overlapping spanning trees) of some kind, as Yggdrasil does (their current one looks like https://yggdrasil-map.cwinfo.org/#, although only ~300 nodes are live atm)... or you let the nodes self-organise into some kind of hierarchy based on gossiping and fan out the messages that way (as per https://blog.ipfs.io/2020-05-20-gossipsub-v1.1, and some of the experimental routing stuff we've been doing with Matrix).

It's not hard for IRC-style chats, but it gets harder if you want to handle:

* Asynchronous messaging: what if the two devices are not online at the same time, or on disjointed networks? Store the message on a server somewhere? Secure Scuttlebutt[1] relies on devices pulling encrypted data that does not belong to them.

* NAT or firewall hole-punching, though it can be remediated by leveraging other nodes. Some implementations use a DHT[2], but you're often relying on other servers of some sort.

* What you call contact discovery is also typically handled through a DHT of some kind. Yggdrasil-like (or hyperboria, cjdns, .onion) overlay networks are usually able to route to a public key, regardless of how it moves around on the network.

* Push notifications. Either you accept the use of an external server (like the Tox client TRIfA, which has an add-on[3] that also supports UnifiedPush), or you have to rely on a separate persistent connection that will drain your battery faster, especially if there's some computation involved.

The last point is why I uninstalled Briar: I had almost no contacts, and didn't want an extra battery-draining service.

[1] https://scuttlebutt.nz/docs/introduction/detailed-start/#more-about-social-connections-and-how-posts-travel

[2] https://blog.ipfs.tech/2022-01-20-libp2p-hole-punching/

[3] https://github.com/zoff99/tox_push_msg_app

It's "not already there" as what torrents do is not the same as what Netflix does even though both are related to media delivery. Try seeking on a torrent which only caches the local blocks and getting the same seek delay, try getting instant start and seek when 1 million people are watching a launch, try getting people to pay you the same amount to use their upload, try getting the same battery life on a torrent as a single HTTPS stream using burst intervals. As I said P2P doesn't offer as many experience consistency guarantees and has many other problems. Licensing is just one of many issues.

Of course for free many people are willing to live with starting and seeking being slow or battery life being worse or having to allocate the storage up front or using their upload and so on but again the question is can it fit in the cost offset of some of the centralized infrastructure not what you could do for free. I don't have anything against torrents, quite the opposite I am quite a heavy user of BOTH streaming services and torrenting due to DRM restrictions on quality for some of my devices, but it isn't a single issue problem like you are pressing to make it be.

For some internal distributed action Netflix has made IPFS into something they can use but not for end delivery https://blog.ipfs.io/2020-02-14-improved-bitswap-for-container-distribution/

I believe the problem is the lack of protocols implemented in browsers. It's needlessly fragile to have a single route to the data.

"Web pages only last about 100 days on average"[1]

http was nice, we gave it a good spin, it was certainly close enough for the cigar but in all honesty... where you have 100 days to find the content you want to consume it is not even a reasonable approach. I bet a lot of it is still available some place but whoever archived it legally may not distribute it without permission.

I really don't care if TOR, IPFS, freenet or zeronet work out of the box. If it means access to more content its great. I don't even know how to use gopher atm.

Good stuff is happening[2] but where they apparently chose to make it an extension is pretty lame.

also..

If the user types "salvation army" into the browser we know what they want. Selling the rights to deny access is not what we need.

[1] - http://blog.archive.org/2015/02/11/locking-the-web-open-a-call-for-a-distributed-web/

[2] - https://blog.ipfs.io/2019-10-08-ipfs-browsers-update/