Hah, I agree with your resentment about the recent wave of "serverless" :)

By now redis has been replaced with native IPFS pubsub, which is provided by both go-ipfs and js-ipfs. The only remaining server-ish is some means of bootstrapping, i.e. entering the network.

I'm not sure how up-to-date the readme is, but the demo (orbit.libp2p.io) is out-of-date and still uses redis pubsub. I pinged @haadcode, who can go more into detail.

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 <topic> <data>... - Publish a message to a given pubsub topic.
     ipfs pubsub sub <topic>           - Subscribe to messages on a given topic.
   
     Use 'ipfs pubsub <subcmd> --help' for more information about each command.

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.

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.

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

Because IPFS only does distributed storage. It has no processing power or logic to handle data transformations.

Now, one avenue to handle that is js-ipfs. In order to update things like IPNS records, you need the private key of the node you're trying to change. Interestingly enough, and machine with the pub/priv key can submit an IPNS change.

So effectively, you could have a shared repo like Usenet, where everyone has the pub/priv key and pushes updates via js-ipfs. Although, I could imagine easily how that could get super-heavy.

_________________________

Another idea I had, was to build something akin to AWS lambda, except using Tor Hidden Services, and Erlang. It would be effectively a private computation cloud. The reason for the HS is so each machine, regardless of their location, could always talk with each other, using Erlang's built--in networking support. (I am using non-standard applications of Tor Hidden Services - read more what I'm doing here: https://hackaday.io/project/12985-multisite-homeofficehacker... )

That's very cool! Have you looked at OnionCat? I've managed a global LizardFS cluster on a PeerVPN network, overlayed on OnionCat IPv6. Latency is too high for erasure coding or XOR goals, but chunk-replication mode works reliably.

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.

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