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