Live data from Hacker News

IPFS Pubsub: Distributed named pubsub channels based in the IPFS Cloud

ipfs.io

31–39 of 39 posts

Re: IPFS Pubsub: Distributed named pubsub channels based in the IPFS Cloud

#31
post #30

Earlier quoted context omitted.

In that sense, I would agree, ipfs can provide access to content that would otherwise be blocked.

Could ISPs throttle IPFS content the same way they did with torrents a while ago? (and probably will again once net neutrality falls).

Sure -- but libp2p's network transports underneath are pluggable. There's already Websockets (/ws, think domain fronting! [1]) and Tor (/onion) transports, so there's various options for evading censorship (I personally consider bandwidth throttling a form of censorship).

[1] Domain fronting lets you use a well-established web frontend for your web service. E.g. we could host /ws nodes in Google Cloud, and to the ISP the TLS handshake looks like it's for google.com, while inside the connection there's e.g. a `Host: libp2p.googlecloud.com` header. More info: https://www.bamsoftware.com/papers/fronting/

But then again, net neutrality is a political issue! You don't solve it for good with technology.

Re: IPFS Pubsub: Distributed named pubsub channels based in the IPFS Cloud

#32
Back in the day (late 1990s iirc) I used Usenet as a global, distributed, publish/subscribe bus for system messages between island service POPs. Messages PGP encrypted and carried by a variety of groups (mostly alt.*). Also eventually consistent. Very eventually in some cases.

"Floodsub" indeed.

Re: IPFS Pubsub: Distributed named pubsub channels based in the IPFS Cloud

#33

Hey Everyone! IPFS dev here, If anyone is interested in the future of ipfs pubsub you can participate in the discussions in our research repo: https://github.com/libp2p/research-pubsub . One of the next big things we're planning to do is to implement a new routing algorithm, one proposal for this is here: https://github.com/libp2p/research-pubsub/pull/17 (feedback and review very welcome) We are also planning on impl…

Sweet. Is there an RFC for authentication yet?

Re: IPFS Pubsub: Distributed named pubsub channels based in the IPFS Cloud

#35
post #19

Earlier quoted context omitted.

Is there where a third party node can spoof (or lie about) the content belonging to a pin to clients that ask it?

Since IPFS is based on content addressing, if a node tries to spoof a piece of content, any peers trying to fetch from the malicious node will immediately see that the content provided does not match the desired hash. I'm not sure how peers handle that situation, I'd assume it'd be treated like wire corruption (retry) or give up and try to fetch from a different peer.

But that doesn't stop ddos attacks.

Re: IPFS Pubsub: Distributed named pubsub channels based in the IPFS Cloud

#37

Hey Everyone! IPFS dev here, If anyone is interested in the future of ipfs pubsub you can participate in the discussions in our research repo: https://github.com/libp2p/research-pubsub . One of the next big things we're planning to do is to implement a new routing algorithm, one proposal for this is here: https://github.com/libp2p/research-pubsub/pull/17 (feedback and review very welcome) We are also planning on impl…

Sweet. Is there an RFC for authentication yet?

Not yet, its somewhere in our giant pile of things to do. If anyone is interested in helping out on this I can definitely help out and point people in the right direction.

Re: IPFS Pubsub: Distributed named pubsub channels based in the IPFS Cloud

#38

Earlier quoted context omitted.

Sweet. Is there an RFC for authentication yet?

Not yet, its somewhere in our giant pile of things to do. If anyone is interested in helping out on this I can definitely help out and point people in the right direction.

I wouldn't want to drive this but I'd be interested in contributing and providing feedback. yaniv [] functionalfoundry com

Re: IPFS Pubsub: Distributed named pubsub channels based in the IPFS Cloud

#39
post #19

Earlier quoted context omitted.

Since IPFS is based on content addressing, if a node tries to spoof a piece of content, any peers trying to fetch from the malicious node will immediately see that the content provided does not match the desired hash. I'm not sure how peers handle that situation, I'd assume it'd be treated like wire corruption (retry) or give up and try to fetch from a different peer.

But that doesn't stop ddos attacks.

True, but a ddos also doesn't exactly mean the content is "exploitable".

I presume future clients would block nodes that share false content (if clients don't already).

Post reply on HN