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

31–40 of 72 posts

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

#31

Post by fizzbatter »

carolc wrote: post #16
dwills wrote: post #7

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

Orbit used to use a Redis server for pubsub messaging but it's not anymore as IPFS has implemented a peer-to-peer pubsub. Totally serverless.

Are you familiar with IPFS pubsub? Would you be able to link some information about the implementation/usage?

I'm quite surprised to hear what you said. I've been following multiple Github Issues on IPFS pubsub, and none of them (that i followed) announced success/etc. I thought it was still in the planning phase.

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

#32

Post by wcummings »

jude- wrote: post #30
alpb wrote: post #29

Earlier quoted context omitted.

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

Nope. You have to re-announce them periodically (and this is ignoring all the routing attacks you can do on IPFS).

Routing attacks?

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

#34

Post by diggan »

fizzbatter wrote: post #31
carolc wrote: post #16

Earlier quoted context omitted.

Orbit used to use a Redis server for pubsub messaging but it's not anymore as IPFS has implemented a peer-to-peer pubsub. Totally serverless.

Are you familiar with IPFS pubsub? Would you be able to link some information about the implementation/usage? I'm quite surprised to hear what you said. I've been following multiple Github Issues on IPFS pubsub, and none of them (that i followed) announced success/etc. I thought it was still in the planning phase.

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 production environment.
     
     To use, the daemon must be run with '--enable-pubsub-experiment'.
   
   SUBCOMMANDS
     ipfs pubsub ls                    - List subscribed topics by name.
     ipfs pubsub peers                 - List all peers we are currently pubsubbing with.
     ipfs pubsub pub  ... - Publish a message to a given pubsub topic.
     ipfs pubsub sub            - Subscribe to messages on a given topic.
   
     Use 'ipfs pubsub  --help' for more information about each command.

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

#35

Post by diggan »

marknadal wrote: post #5

The browser demo does seem to be working, however it seems very slow? Beautiful interface though! One of the best I've seen yet. What is going on underneath? Are you guys using WebSocket or WebRTC? The reason I ask is because I wrote an interactive coding tutorial for building a distributed chat app ( http://gun.js.org/converse.html ), and it uses WebSockets to communicate with a federated relay peer server. I'm hopi…

The version deployed at orbit.libp2p.io is using orbit-db which is using redis to do pubsub right now. However, pubsub is being worked on and exists in for example go-ipfs#master right now under a feature flag. Run `ipfs pubsub --help` after build from source to try it out. It's also being worked on getting into js-ipfs.

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

#36

Post by kefka »

mekaj wrote: post #23
b101010 wrote: post #22

Earlier quoted context omitted.

Would (a) not be a. Cache files are added to when _something causes a request for_ IPFS content The distinction being that "something" is not always a direct action from the user. If content on IPFS (ie a web page?) can reference and load content from other addresses (assumption) then could someone end up in the situation where they are "hosting" (from the cache) something they would not expect to be? (until the garb…

This is true and good to keep in mind, but it's also an inescapable risk of any network involving autonomous agents. We're also susceptible to downloading content that's different than advertised (e.g. Rickrolling).

And in all honesty, the whole "but child porn OMG" is a non-sequitor.

Child porn already exists on the web directly. And Tor Hidden Sites. And Freenet. And other places.

The real problem with CP is that fact there's no mens-rea requirement. A script can download it to your browser cache under blank images. It's in your cache, and you have no clue.

In the current situation, you are illegal. With mens-rea, you aren't - there was no willingness to get it, therefore you aren't at fault. Think of this as shoplifter compared to something that fell in your cart you missed. Same idea.

(In all honesty, I hold to Stallman's idea of CP shouldn't be illegal, period. It's a proof of a crime. Snuff videos of people being murdered isn't illegal, although the murdering part very much is. Child abuse is illegal, as well it should be, but proof of child abuse shouldn't.)

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

#37

Post by viraptor »

kefka wrote: post #36
mekaj wrote: post #23

Earlier quoted context omitted.

This is true and good to keep in mind, but it's also an inescapable risk of any network involving autonomous agents. We're also susceptible to downloading content that's different than advertised (e.g. Rickrolling).

And in all honesty, the whole "but child porn OMG" is a non-sequitor. Child porn already exists on the web directly. And Tor Hidden Sites. And Freenet. And other places. The real problem with CP is that fact there's no mens-rea requirement. A script can download it to your browser cache under blank images. It's in your cache, and you have no clue. In the current situation, you are illegal. With mens-rea, you aren't -…

You still have to convince others there was no willingness. And it's much easier to convince them of that if you're not also sending the copies to other people.

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

#38

Post by fizzbatter »

diggan wrote: post #34
fizzbatter wrote: post #31

Earlier quoted context omitted.

Are you familiar with IPFS pubsub? Would you be able to link some information about the implementation/usage? I'm quite surprised to hear what you said. I've been following multiple Github Issues on IPFS pubsub, and none of them (that i followed) announced success/etc. I thought it was still in the planning phase.

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 and performant, this is huge for IPFS.

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

#39

Post by jude- »

wcummings wrote: post #32
jude- wrote: post #30

Earlier quoted context omitted.

Nope. You have to re-announce them periodically (and this is ignoring all the routing attacks you can do on IPFS).

Routing attacks?

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 pathological sequence of join requests and data inserts/deletes), then (s)he can go on to censor buckets and/or serve malicious data from them.

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

#40

Post by lgierth »

jude- wrote: post #39
wcummings wrote: post #32

Earlier quoted context omitted.

Routing attacks?

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).

Post reply on HN