Our great sponsors
-
-
You need access to the internet, that's about it. IPFS can use any transport protocol (see section 3.2 in the whitepaper [1]), it uses a distributed hash table for routing purposes, content addressing to represent objects - these are immutable, once published they're available as long as there is a peer which has the object in cache or 'pinned' (permanently cached).
Read the whitepaper and install [2] a node of your own to get a feel of the thing, you'll soon find out it is an amalgamation of earlier peer to peer systems. The go-ipfs daemon tends to be quite busy, it averages somewhere around 30% CPU, 500MB memory, 0.1Mb/s in, 0.04Mb/s out when hosting ~3GB of (self-generated, niche-interest, database-related) files. This busyness is acknowledged by the developers and should be addressed somewhere down the line.
[1] https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-...
[2] https://dist.ipfs.io/ (get go-ipfs)
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
> IPFS can use any transport protocol (see section 3.2 in the whitepaper [1]),
In theory. In practice, the network (I checked my local node with ~2500 nodes connected to it) is mostly using quic over tcp/udp, more or less 50%/50% split between tcp/udp.
> This busyness is acknowledged by the developers and should be addressed somewhere down the line.
IPFS has been killing routers[https://github.com/ipfs/go-ipfs/issues/3320] and sending/receiving lots of network traffic[https://github.com/ipfs/go-ipfs/issues/2917] since 2016 and there hasn't been any notable improvements on that front yet. When is "down the line" in reality?