Live data from Hacker News

IPFS 0.5

blog.ipfs.io

21–30 of 145 posts

Re: IPFS 0.5

#21
post #18

I wish they hadn't picked go. Go isn't a bad language really, but it's a huge pain to integrate a go library into an app written in another language.

C or Rust would be perfect. No GC runtime, no name mangling, fast, great ffi story. Rust needs to start edging out Go for new tools. Kubernetes, Envoy, IPFS, etc. would have benefitted from it. It might not have been time four years ago, but it's time now.

There's actually a new Rust-IPFS implementation looking for more contributors. Seems to be moving pretty fast - https://github.com/ipfs-rust/rust-ipfs

Re: IPFS 0.5

#22
post #18

I wish they hadn't picked go. Go isn't a bad language really, but it's a huge pain to integrate a go library into an app written in another language.

C or Rust would be perfect. No GC runtime, no name mangling, fast, great ffi story. Rust needs to start edging out Go for new tools. Kubernetes, Envoy, IPFS, etc. would have benefitted from it. It might not have been time four years ago, but it's time now.

Envoy is written in C++, not Go.

Re: IPFS 0.5

#23
post #10

Earlier quoted context omitted.

Doesn’t IPFS still rely on Kademlia? Since node IDs are random, node lookup may require multiple interplanetary hops, no? For instance, from N1 on Earth to the nearest XORwise node in its routing table which might be N2 on Mars, whose routing table finds the target node N3 on Earth.

We do use Kademlia - but note this release actually runs 2 DHTs - one for LAN connections and one for WAN connections. You could easily imagine a small Mars outpost as the LAN DHT where you can do fast retrieval for all content already available locally without hitting interplanetary lookup times. https://docs-beta.ipfs.io/recent-releases/go-ipfs-0-5/featur...

What are your plans WRT Coral? I noticed there's a work-in-progress Go implementation. Is it going to supercede Kademlia eventually?

Re: IPFS 0.5

#24
post #14

anyone know good python ipfs resources + decentralized sync-able embedded databases ?

orbitdb is a distributed database built on IPFS - looks like they have a python http client: https://github.com/orbitdb/py-orbit-db-http-client

the py-ipfs-http-client library is also actively maintained (but I think needs some small changes to work with IPFS 0.5): https://github .com/ipfs-shipyard/py-ipfs-http-client/

Re: IPFS 0.5

#25

I wish they hadn't picked go. Go isn't a bad language really, but it's a huge pain to integrate a go library into an app written in another language.

Go can handle 100k goroutines (green threads) without a sweat.

This is useful for p2p systems in which you are connected to thousands of peers multiplexing several p2p protocols with each concurrently. You want to be able to switch threads as fast as possible.

The concurrency model is a bit easier to reason about too.

It would be good to see how Rust and others do. Other languages excel at other things (i.e. embedded devices ).

Re: IPFS 0.5

#26
This uses DHTs. How resilient is it against Sybil attacks? Also how does it work under global netsplit conditions, like if someone borks or attacks BGP in such a way that 1/3 of the world is not reachable?

My impression is that DHTs fall down pretty hard under the latter scenario and are also pretty vulnerable to the Sybil scenario if the attacker has enough resources to mount a really serious attack. They're okay for low-value simple stuff that doesn't have much of an intrinsic bounty attached to it (like BitTorrent magnets), but trying to put a "decentralized web" on top of a DHT seems like a scenario where the instant it becomes popular it will get completely shredded for profit (spam, stealing Bitcoin, etc.).

My rule of thumb is that anything designed for serious or large scale use (in other words that might get popular) needs to be built to withstand either a "nation state level attacker" threat model or a "Zerg rush of hundreds of thousands of profit motivated black hats" threat model. The Internet today is a war zone because today you can make money and gain power (e.g. by influencing elections) by messing with it.

Re: IPFS 0.5

#27

I wish they hadn't picked go. Go isn't a bad language really, but it's a huge pain to integrate a go library into an app written in another language.

Go can handle 100k goroutines (green threads) without a sweat. This is useful for p2p systems in which you are connected to thousands of peers multiplexing several p2p protocols with each concurrently. You want to be able to switch threads as fast as possible. The concurrency model is a bit easier to reason about too. It would be good to see how Rust and others do. Other languages excel at other things (i.e. embedded…

Rust can easily do the same.

Re: IPFS 0.5

#28
post #5

Earlier quoted context omitted.

The ping from Earth to Mars varies between 360 and 2600 seconds, so 30 might still be fast enough for an "interplanetary" thing.

Doesn’t IPFS still rely on Kademlia? Since node IDs are random, node lookup may require multiple interplanetary hops, no? For instance, from N1 on Earth to the nearest XORwise node in its routing table which might be N2 on Mars, whose routing table finds the target node N3 on Earth.

Tbh, chances are you will find a faster path through earth peers. The query will explore multiple paths in parallel and timeout slow ones...

Re: IPFS 0.5

#29

I wish they hadn't picked go. Go isn't a bad language really, but it's a huge pain to integrate a go library into an app written in another language.

They also picked javascript ¯\_(ツ)_/¯

Browsers picked... until recently it was the only way to run in browsers.......

Re: IPFS 0.5

#30
post #26

This uses DHTs. How resilient is it against Sybil attacks? Also how does it work under global netsplit conditions, like if someone borks or attacks BGP in such a way that 1/3 of the world is not reachable? My impression is that DHTs fall down pretty hard under the latter scenario and are also pretty vulnerable to the Sybil scenario if the attacker has enough resources to mount a really serious attack. They're okay fo…

For BGP partitions / Significant network outage conditions: You may not find content partitioned on the other side of a netsplit from you, but the degraded condition is that you can still query and find content present in the same part of the network as you. This is better than centralized solutions face at present - e.g. google not being available in China, and isn't too far off from what you might hope.

For Sybils: You've left the attack you're worried about pretty vague. IPFS itself doesn't need to tackle many of the sybil-related issues by being content addressable (so only worrying about availability - not integrity) and not being a discovery platform - so not worrying about spam / influence. For the remaining degradation attacks - someone overwhelming the DHT with misbehaving nodes - there's been a bunch of work in this release looking at how to score peers and figure out which ones aren't worth keeping in the DHT.

Post reply on HN