Since Ceramic heavily relies on IPFS, is it possible to use IPFS cluster(https://ipfscluster.io/) or elastic IPFS(GitHub - elastic-ipfs/elastic-ipfs: A cloud native IPFS node) ?
Hi Liang,
Thanks for posting on the forum.
Unfortunately, neither of these options support PubSub, which Ceramic currently needs for its operation 
We’re already working on an alternative implementation that will optimize how we use PubSub as well as break our reliance on IPFS PubSub.
1 Like
Hi Mohsin,
Thanks for the prompt reply! 
How does does IPFS Pubsub differ from libp2p PubSub ? Is this related to this issue Issues · ipfs/kubo · GitHub Is possible to do pubsub via libp2p directly so that we could be more flexible in terms of IPFS node choice?
Hi Liang, we use libp2p PubSub through IPFS, which means we don’t have a ton of control over it
That issue you linked to is for deprecating that support in Kubo entirely, which we are aware of. The release we’re using as the base of our image right now (v0.19.1) does still have support for PubSub. We are currently running a fork of Kubo, packaged with a newer release of go-libp2p-pubsub that has an important protection against duplicate messages on the network.
We are actively in the process of building an alternative Stream synchronization implementation directly over libp2p instead of through IPFS, which will give us a lot more fine-grained control, and also make the synchronization a lot more efficient than it is today.
Until we get there though, we’re unfortunately restricted by what we can achieve by using PubSub through Kubo 
In other words, Ceramic is currently tied to Kubo with PubSub until we can move off of PubSub (and likely even Kubo) over the next few months.
1 Like
Argh I see. So CIP-124 is already finalised and in the implementation stage? That is good news! Is this the rust implementation Joel mentioned? We have been planning to attempt a Golang version. Just want to find out more about future protocol spec before we proceed @jthor
Yes! This is the Rust implementation that is currently in progress. The spec isn’t fully finalized yet, but we’re getting closer.
1 Like
So I would assume once the stream work is done, we could move away from kubo dependence and use elastic ipfs deployment or evening using infura ipfs ?
We likely won’t need IPFS at all, though we will be aiming for compatibility with the IPFS network so that data can be fetched from IPFS nodes even if Ceramic nodes don’t use IPFS directly.
Could you elaborate? Understanding that we could use libp2p to do away with the kubo pubsub dependency. But how could Ceramic remove IPFS dependency if all Init/Time/Data events are IPLD?
Or you mean Recon by AaronGoldman · Pull Request #124 · ceramicnetwork/CIP · GitHub ?
Great question, I should have clarified. We’ll stop using IPFS for its data store or for pubsub or (eventually) bitswap, but continue to use IPLD data structures.
In other words, Recon will store and synchronize IPLD based events without using an IPFS backing store.
1 Like
I see. This is a big move by basically removing IPFS dependencies and only using libp2p and ipld. In this case, however, events would no longer be content addressable via IPFS? @jthor What is the primary benefits of sticking with IPLD?
That’s correct. The benefits of sticking with IPLD is that the data can be exported as a CAR file and imported into IPFS / filecoin.