-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
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)
> 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?