Protocol minimization

[jthor]

@msena

For my info, when you say Firehose API here, are you referring to the document-specific change feed, or a more general event-based change feed? I’d think of events at the Ceramic layer, documents as middleware, and indexes/dbs as products.

I think we are aligned on this. Right now Firehose API is focument specific feeds + more. What I’m suggesting is that anything that is not just a feed of signed events, e.g. computation over events, belongs in a layer above, e.g. middleware and/or indexes.

@dbcfd

As a concrete example, assume we are attempting to write Verifiable Credentials to Ceramic. For someone that wants to know when new VC’s are written to Ceramic, we have two approaches: Ceramic provides a way to “find” all the VC’s, possibly by a parent (model) stream id; Ceramic emits a stream of events like new streams being created, which will bring up my second concern later.

I don’t really see how doiong schema validation for a particular type of VC prevents DoS? An attacker could simply generate a lot of fake VCs that conform to the schema.

I think there is another valid area of research around suppring VCs as a type of event on Ceramic (see Simplify event creation)

@dbcfd

Based on this, I feel that simplest valuable implementation of rust-ceramic is one that includes at least

1. Ability to write data to node
2. Data syncing between nodes
3. Verification and validation of written events
4. Feed of events that occur on the node - init, data, time

I wonder if there’s a misunderstanding of what I suggested in the OP because I definitely agree with (1), (2), and (4). There should definitely be a way to get a feed of events from the Rust node! My main point is that:

a. json-schema validation & json-patch processing are application specific
b. conflict resolution is also application specific (we are not able to build CRDTs based on the current model)

By moving (a) and (b) to the application layer we can allow the protocol to move faster on delivering the core values of Ceramic, e.g.:

• Scalable p2p event replication
• Blockchain timestamping
• (eventually) on-chain access control
• (eventually) incentivized event availability