A Ceramic node acts as a layer on top of IPFS, hence the documentation says it needs to be connected to some IPFS server. But it doesn’t mention whether the Ceramic node needs privileges on the IPFS node? Is the Ceramic node instructing the IPFS node to pin things? Update IPNS records? In other words, can one simply point their Ceramic node at gateway.ipfs.io/ipfs/ and be good? Or is having the ability to pin/unpin files sufficient (e.g. Infura offers IPFS nodes that grant the owner the ability to pin/unpin files (Manage files | INFURA), but doesn’t have IPNS management)?
It appears the concept of a StreamID (Ceramic concept) doesn’t mention IPNS (IPFS concept), but is it using IPNS under-the-hood?
For context, I’m evaluating using Ceramic as a data store layer for working with Ethereum Attestation Service (EAS) Attestation data (adr/0010-user-created-lists.md · ADR/0010-eas-list-accepted · MoonCatRescue / Development Environment · GitLab). That project does have an example referencing ComposeDB (Ethereum Attestation Service), but I’m also considering if it’s possible/practical to use plain Ceramic without needing to layer ComposeDB onto it too. For this use-case, the authorization to add content to a stream would be pretty open; anyone who presented a valid off-chain-signed EAS Attestation document (using an EAS schema that is relevant to the target project) would be allowed to add it to the stream, so anyone could find “known” off-chain-signed Attestations.
No, Ceramic does not use IPNS. Instead it currently relies on gossipsub. You can learn more about how our protocol works in our documentation.
Worth noting is that we are currently planning to stop relying on gossipsub, in favor of a native networking protocol (still based on libp2p). You can read more about this in cip-124. An implementation of this is underway in rust-ceramic, which will also remove the need to run a separate IPFS node.
Thanks! That CIP doesn’t actually mention IPFS directly, so I’m not sure I’m understanding how that dependency would be removed. If CIP124 is finalized and adopted as currently written, that changes how Ceramic nodes communicate changes to Streams, however the data of the streams is still stored in IPFS, right? So an application wanting to add data to a Stream would still need some access to an IPFS server to add the data itself to?
When running a Ceramic node currently, and configuring it to point to an IPFS server, does it only use the IPFS server as a means to get access to the gossipsub communication? Or does it actually instruct the IPFS server to pin/unpin files that get added to Streams it knows about? I can only find in the documentation indications that the Ceramic node “pins” content it sees added to Streams it cares about, but unclear if that translates into requesting “pins” on the linked IPFS server or not?
Thanks! That CIP doesn’t actually mention IPFS directly, so I’m not sure I’m understanding how that dependency would be removed. If CIP124 is finalized and adopted as currently written, that changes how Ceramic nodes communicate changes to Streams, however the data of the streams is still stored in IPFS, right? So an application wanting to add data to a Stream would still need some access to an IPFS server to add the data itself to?
CIP-124 is being implemented as part of the larger rust-ceramic effort. Rust-ceramic aims to replace Kubo with a new rust code base. It will remain compatible with IPFS bitswap for now, but not use the DHT in the same way. This means a few things:
To run Ceramic you would need to run rust-ceramic + js-ceramic (but not Kubo)
Kubo nodes that are directly connected to your rust-ceramic node can find the event data
Rust-ceramic nodes always “pins” the underlaying data in its internal blockstore
I can only find in the documentation indications that the Ceramic node “pins” content it sees added to Streams it cares about, but unclear if that translates into requesting “pins” on the linked IPFS server or not?
Yes, currently js-ceramic pins all data to IPFS (kubo)
All right, so then back to my original question: currently if wanting to run a Ceramic node (js-ceramic), the IPFS node it’s configured to talk to, the Ceramic node needs permission to pin IPFS data blocks, but does not need permission to update IPNS values owned by that IPFS node. Therefore, for an app looking to use Ceramic right now, using an Infura-run IPFS node should work (since it gives access to the owner to pin/unpin. Leaving just a js-ceramic and PostgreSQL node the application needs to run for themselves).
Eventually (after rust-ceramic implements CIP-124), an application maintainer would only need to run rust-ceramic and js-ceramic (but not PostgreSQL?)? Why both rust-ceramic and js-ceramic? Is one acting as server and one as client?
Therefore, for an app looking to use Ceramic right now, using an Infura-run IPFS node should work
Infura doesn’t provide the gossipsub functionality (pubsub feature of IPFS) so unfortunately this won’t work.
Eventually (after rust-ceramic implements CIP-124), an application maintainer would only need to run rust-ceramic and js-ceramic (but not PostgreSQL?)? Why both rust-ceramic and js-ceramic? Is one acting as server and one as client?
Good question. I believe Posgres might be needed (to support ComposeDB features of js-ceramic). And yes, we might bundle rust-ceramic into the js-ceramic install to make it easier to set up. However, the medium term goal is to separate Ceramic and ComposeDB into their own executibles explicitly. This means that rust-ceramic would take care of events and data propagation, and parts of js-ceramic might be renamed, or merged into the js-composedb code base to provide Indexing functionality for ComposeDB.