Ceramic without Anchoring

[mohsin]

@spencer

If we could satisfy 90% of use cases without it, then I think it might be worth it to abandon those 10% that do need it for the benefit of the simplicity and ability to deliver faster and higher quality to satisfy the remaining 90%.

That’s fair, and would be an instance of intentionally loosening requirements based on a smaller set of use cases we want to focus on.

We’ll just need to be very explicit in our documentation, especially because the guarantees of anchoring have been part of the protocol for so long that app developers expect it to be present.

[mohsin]

@spencer

I agree with this in theory but in this case anchoring adds a lot of complexity and potential points of failure to our protocol.

I feel like we’ve substantially reduced complexity and points of failure with the latest self-anchoring design but yes, it’s still going to be complex, and we’re also going to need multi-prev to plug in some holes.

We’ll have to decide whether that’s more effort than we’re willing to invest for the use cases they would serve.

Separating Anchoring out from Streaming would also have the advantage of letting us punt on the implementation without precluding the possibility of implementing it at a later time.

[jthor]

@mohsin

My first question is logistical. Even if we decide to remove anchoring, it’s looking like we not only need an alternative approach for OCAP revocation, we then need to design it, implement it, test it, and harden it.

I would challenge this. If we have reason to believe that anchoring is holding us back now, I think there is a world in which we commit to adding event revocation in the future, but hold off on implementation. Just like we’re holding off on implementing Event validation (which is a much bigger problem imo).

@mohsin

Thirdly, I feel like we’d be opening up a huge can of worms trying to work around time-bound tokens. Most of Web2 works that way, and we’d be in brand new security territory if we went in a different direction.

This is a reason I actually like spencers proposal. While we would remove time enforcement from the core protocol, we would still enforce it everywhere else. Making it hard for devs to do the wrong thing.
We would make the Ceramic-one “add event” API only accept writes with valid OCAPs, and we would make client side libraries rotate OCAPs often. Setting the norm that keys are short lived.

@mohsin

One of my mentors would say, “Start with a design based on the strictest use case, then intentionally relax requirements as you go based on the specific use cases you want to target.” This prevents designing for use cases needing looser guarantees, when in fact your system could be used (and fail) for a use case expecting stricter guarantees.

This is a great point and I think we are reaching the point where the strict guarantees we provide with anchoring are actually limiting the types of use cases we can serve.

@mohsin

We’ll just need to be very explicit in our documentation, especially because the guarantees of anchoring have been part of the protocol for so long that app developers expect it to be present.

This is my biggeset worry about this direction. We do have customers that rely on timestamping, not for key rotation, but for historical record. Changing this would break that, so there needs to be a way to solve that problem, even if that’s just pointing at some alternative solution.

[mohsin]

@spencer

cons

• Pushes responsibility for detecting and managing a compromised session key entirely to the end user
  ** Note there are already categories of attack that would require the end user to take responsibility for explicit capability revocation, even if we continue to support time-based capability expiration.
• A compromised session key can remain usable indefinitely.
  ** On the one hand, if a session key is compromised today, the attacker can already generate an unbounded amount of malicious data before the key expires. On the other hand, with this proposal the attacker could sit on the key for an arbitrarily long period of time before using it to generate malicious data, expanding the types of attacks that are possible and making it harder for users to monitor their session keys for misuse.

These points scare me

We would be:

• Pushing some of the responsibility for security back to the most vulnerable and least technical party in the data flow. I don’t think we should be adding scenarios in which explicit revocation is necessary even if there are scenarios like that today.
• Apps, SDKs, and browsers are part of the security boundary for writes to Ceramic today but the blast radius of a vulnerability in any of these external components is usually limited by the fact that OCAPs are short-lived and expire quickly.
  With explicit OCAP revocation, vulnerabilities in these components become more critical and introduce new ways in which security gaps can be exploited over time.

[mohsin]

@jthor

@mohsin

My first question is logistical. Even if we decide to remove anchoring, it’s looking like we not only need an alternative approach for OCAP revocation, we then need to design it, implement it, test it, and harden it.

I would challenge this. If we have reason to believe that anchoring is holding us back now, I think there is a world in which we commit to adding event revocation in the future, but hold off on implementation. Just like we’re holding off on implementing Event validation (which is a much bigger problem imo).

Do we feel like implementing self-anchoring will slow us down that much? Additionally, will not anchoring + explicit OCAP revocation need no engineering work, or will there still be some work required to allow the system to continue working, especially with tons of legacy data? I suspect that it’ll be the latter.

Self-anchoring will be at most a few cycles of work and uses an approach that not only cleanly separates anchoring out as its own subsystem but also simplifies a lot of the complexity of the current anchoring system. Would it make sense to implement self-anchoring anyway, even if we decide to deprecate or make it optional it later?

@jthor

@mohsin

We’ll just need to be very explicit in our documentation, especially because the guarantees of anchoring have been part of the protocol for so long that app developers expect it to be present.

This is my biggeset worry about this direction. We do have customers that rely on timestamping, not for key rotation, but for historical record. Changing this would break that, so there needs to be a way to solve that problem, even if that’s just pointing at some alternative solution.

This will definitely be a massive change in our behavior and guarantees. Without anchoring, we’re more like the latest iteration of Iroh. By focusing more on p2p collaboration cases would we be weakening our value proposition?

Additionally, would the use cases of our biggest partners (current or potential) work without significant disruption if we were to remove anchoring and rely on explicit OCAP revocation?

[jthor]

@mohsin

Do we feel like implementing self-anchoring will slow us down that much? Additionally, will not anchoring + explicit OCAP revocation need no engineering work, or will there still be some work required to allow the system to continue working, especially with tons of legacy data? I suspect that it’ll be the latter.

Self-anchoring will be at most a few cycles of work and uses an approach that not only cleanly separates anchoring out as its own subsystem but also simplifies a lot of the complexity of the current anchoring system. Would it make sense to implement self-anchoring anyway, even if we decide to deprecate or make it optional it later?

We don’t really know if self-anchoring will definitely solve the pain points that we’ve heard from developers building on ceramic. We do know that if we didn’t do anchoring those pain points wouldn’t exist. There might be other problems that emerge from not doing anchoring though.

[mohsin]

@jthor

We don’t really know if self-anchoring will definitely solve the pain points that we’ve heard from developers building on ceramic. We do know that if we didn’t do anchoring those pain points wouldn’t exist.

Yes, should we enumerate some of those pain points and talk through them as well? I’m assuming expired CACAOs are the chief complaint, or are there more?

I feel like we might have a better handle on issues related to anchoring and would have an easier time figuring them out. I also don’t feel like it has to be either-or, especially if we can cleanly separate Anchoring out of Streaming.

@jthor

There might be other problems that emerge from not doing anchoring though.

Yes, that’s my main concern here. We don’t yet know enough about the edge-cases without anchoring