Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Orbit – Distributed, serverless, peer-to-peer chat application on IPFS

github.com

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Orbit – Distributed, serverless, peer-to-peer chat application on IPFS

#41

Post by lgierth »

fizzbatter wrote: post #38
diggan wrote: post #34

Earlier quoted context omitted.

There is some prototype work done in master already (if you build go-ipfs from source). $ ipfs pubsub --help USAGE ipfs pubsub - An experimental publish-subscribe system on ipfs. SYNOPSIS ipfs pubsub DESCRIPTION ipfs pubsub allows you to publish messages to a given topic, and also to subscribe to new messages on a given topic. This is an experimental feature. It is not intended in its current state to be used in a pr…

Wow, thank you! Very interesting! Quite odd that none of my follows mentioned this going live, must be an issue of too many github issues. Time to dig into this a bit! edit : For anyone else perplexed and surprised by me, seems `floodsub` is their moniker for the new tech, and it was (in part) merged in here: https://github.com/ipfs/go-ipfs/pull/3202 This is really, really cool! Also, if this implementation is robust…

Yes we haven't been very vocal about it yet because it's not yet part of a go-ipfs release -- it'll be in the next release, go-ipfs v0.4.5.

Note on the name: floodsub is one specific implementation of pubsub. There are many ways to do pubsub, and we chose to go with a naive and simple flooding implementation for now. In the future there will be more, and you'll be able to use different implementations simultaneously.

Re: Orbit – Distributed, serverless, peer-to-peer chat application on IPFS

#42

Post by fiatjaf »

alpb wrote: post #29
fiatjaf wrote: post #28

This is a perfect non-use-case for IPFS: ephemeral messages in a chat application.

What makes it ephemeral? Does not IPFS store all objects forever?

My point is that chat messages are meant to be ephemeral, so it was a waste to store them in IPFS and hash them and make them identifiable by a unique useless hash in the entire world forever.

But since I posted the comment I realized that this is actually a cool feature for a chat app to have.

Re: Orbit – Distributed, serverless, peer-to-peer chat application on IPFS

#43

Post by daviddias »

aleken wrote: post #11
dwills wrote: post #7

Another false headline. "serverless"? Nope. A redis server must be running.

I imagine an IPFS chat software could store it's necessary information in... IPFS. So why involve redis?

redis was mainly used to get pubsub for the first iteration (demonstrated in June), now (demonstrated in September) orbit uses IPFS pubsub (available in the go-ipfs implementation) for a complete distributed web application.

Re: Orbit – Distributed, serverless, peer-to-peer chat application on IPFS

#44

Post by daviddias »

heliumcraft wrote: post #12
dwills wrote: post #7

Another false headline. "serverless"? Nope. A redis server must be running.

Isn't Redis used just for running the test suite?

It was just used for pubsub on the 1st iteration, see: https://news.ycombinator.com/item?id=12721898

Re: Orbit – Distributed, serverless, peer-to-peer chat application on IPFS

#45

Post by daviddias »

crudbug wrote: post #15

Does IPFS provide HTTP adaptor ?

Yes, both as a read-only gateway (browser navigation friendly) and as a read+write HTTP API, you can find several API client libraries at:

https://github.com/ipfs/?utf8=%E2%9C%93&query=ipfs-api

Re: Orbit – Distributed, serverless, peer-to-peer chat application on IPFS

#46

Post by mirimir »

kefka wrote: post #10
Mizza wrote: post #3

Earlier quoted context omitted.

IPFS is not an anonymity network.

Indeed not. In fact, IPFS via the DHT, tells the network of your whole network topology, including internal address you may have, and VPN endpoints too. There's still talks in how to handle Tor connections. Because right now, if you were to use a Tor connection with IPFS, it will tell the whole network your public, private, and .onion addresses all.

I'm thinking about creating a gateway for IPFS from clearnet to OnionCat IPv6. So other onion servers can participate without revealing public IPs.

Re: Orbit – Distributed, serverless, peer-to-peer chat application on IPFS

#47

Post by lkjhgfdsa57 »

notwhiteknight wrote: post #2

Interesting. Can someone explain how IPFS works? Is it like Tor? I don't have any interest in running some sort of distributed content farm that might place CP on my computer. Even if the chance of that happening is 0.00001%.

Freenet encrypts content, parcels it into chunks and distributes those chunks amongst peers. Does this meet your definition of "distributed content farm that might place CP on my computer"?

I'm curious because I've seen objections to Freenet for that reason yet the content stored is in no way CP. No bad content can be reconstructed from the data in your store. Not just because it's encrypted but because you'd be holding random small chunks of the file.

The vast majority of Freenet content is probably about Freenet itself (Web of trust data, Sone traffic, FMS traffic), not bad content.

Re: Orbit – Distributed, serverless, peer-to-peer chat application on IPFS

#48

Post by giancarlostoro »

kefka wrote: post #25
giancarlostoro wrote: post #24

Earlier quoted context omitted.

Why would it do that though? I don't really care for Tor, but private network? That's a bit strange to me. Can you or someone explain? Seems like it has no regard for privacy by the sound of it.

Sure can. What IPFS does, is looks at network topology to determine 'closeness' of nearby IPFS nodes. It then prefers 'closer' nodes, to speed up transactions and requests. For example, if we take Gangnam Style video, it spread to something like 100M views rapidly. With Youtube, that's 100M individual downloads. With IPFS, it would be 1 or 2 downloads per local network. And then those machines would provide the local…

That's neat, though I think in some cases, say Intellectual Property on your LAN, or other things, you may want those services ignored I would think? Sounds like setting up IPFS has to become a rather isolated process for some? Which I find kind of limiting if you're forced to go through hoops for something that could be opt-in / configurable at the very least?

Re: Orbit – Distributed, serverless, peer-to-peer chat application on IPFS

#49

Post by kefka »

mirimir wrote: post #46
kefka wrote: post #10

Earlier quoted context omitted.

Indeed not. In fact, IPFS via the DHT, tells the network of your whole network topology, including internal address you may have, and VPN endpoints too. There's still talks in how to handle Tor connections. Because right now, if you were to use a Tor connection with IPFS, it will tell the whole network your public, private, and .onion addresses all.

I'm thinking about creating a gateway for IPFS from clearnet to OnionCat IPv6. So other onion servers can participate without revealing public IPs.

You WILL have to hack on IPFS software, as to not release all your adapter information. Even if you tunnel all the IPFS datastream through .onion , the datastream inside will tell everyone your IP adresses, internal (unroutable) and external.

Re: Orbit – Distributed, serverless, peer-to-peer chat application on IPFS

#50

Post by jude- »

lgierth wrote: post #40
jude- wrote: post #39

Earlier quoted context omitted.

IPFS uses a DHT to look up and announce the availability of content. DHTs are notoriously vulnerable to routing attacks, whereby an attacker can insert nodes into the network and take control of individual hash buckets. This is achieved by inserting the nodes such that they become responsible for pointing clients to the target hash bucket. If an attacker takes control over all such nodes (and can do so with a patholo…

You're very right about the weaknesses of DHTs. We're planning ahead for future mitigations by making every layer of IPFS pluggable. We also devide routing into Peer Routing and Content Routing, as well as soon Wire Routing once there is a packet-switched overlay network in place. There are also improvements upon Kademlia such as S/Kademlia which we've partially applied to IPFS (and we'll continue to apply more).

Routing attacks aren't specific to DHTs--they affect all kinds of structured overlay networks. If your routing layer allows anyone to route requests, then the attacker can insert its nodes into the routing layer (e.g. as a sybil) and censor data. Also, if your routing layer makes forwarding decisions based on arbitrary data previously uploaded, then the attacker can pathologically insert, delete, and request data to either deny service to the network or divert requests to attacker-chosen nodes.

Splitting routing into peer routing and content routing isn't going to fix this if you're still using a DHT to do both. Also, S/Kademlia's decentralized countermeasures only slow down the attacker, and they don't save you if the attacker has a botnet.

> We're planning ahead for future mitigations by making every layer of IPFS pluggable.

The problem with this line of thinking is that it ignores the fact that IPFS-with-DHT-routing is a fundamentally different system than e.g. IPFS-with-DNS-routing, which are both fundamentally different from IPFS-with-Namecoin-routing. This is because they each make fundamentally different guarantees about availability, durability, and security. In general, the end-to-end properties of a distributed system do not logically decompose.

Plugins make this problem worse, not better. Now it's not enough to know that I'm storing my data with IPFS; now I also need to know which plugins both I and my peers are using using since the set of plugins is what determines the properties of the data store.

Post reply on HN