5 ms·

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

• kefka 10y ago
  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-homeofficehackerspace-automation https://hackaday.io/project/12985-multisite-homeofficehacker... )
  • mirimir 10y ago
    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.
• daviddias 10y ago
  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.