DIP-1 becomes purely about off-chain

diem / dip

Libra Improvement Proposals

https://lip.libra.org

Apache License 2.0

40 stars 55 forks source link

DIP-1 becomes purely about off-chain #148

Closed davidiw closed 3 years ago

davidiw commented 3 years ago

Move Travel rule into an independent DIP-13
Add an optional result field to responses
Improve statements around cid on responses
Use must and instead of should around UUID requirements
Removed example code -- should be in a guide not in a spec
Introduce a PingCommand, optional
Make author's list inclusive

Action items:

DIP-13 must be created, approved, and landed before landing this
I've added a list of authors, if you don't feel your name belongs there, let me know, but I'm a big fan of being inclusive
@xli, I've noticed that the wording around cid in response makes it quite clear that it is expected to be there unless the request is unparseable, but I remember a conversation where maybe that thought wasn't consistent either in DRW or SDK or both

pdhamdhere commented 3 years ago

DIP-1 is already in Final stage. Please note partners have implemented or in the process of implementing DIP-1 as it stands today. Changing the Spec which is already final can not only create confusion but may introduce compatibility issues in production. Would the right process be to start new DIP and then deprecate DIP-1?

davidiw commented 3 years ago

DIP-1 is already in Final stage. Please note partners have implemented or in the process of implementing DIP-1 as it stands today. Changing the Spec which is already final can not only create confusion but may introduce compatibility issues in production. Would the right process be to start new DIP and then deprecate DIP-1?

What makes you feel like this is an incompatible update to the dip? It's largely improving the readability and improving the organization. If it breaks anything or creates any incompatibilities, then the update has failed it's purpose.

With respect to a new dip, the intent here being a forward compatible update, we've agreed to using versioning. If we were to introduce a completely different off chain format, say ethereum whisper, it would be a different dip.

aching commented 3 years ago

While I do appreciate that incompatible updates to a protocol are not as disruptive, I think this DIP has gone substantive changes over time and we should be following the process of DIP deprecation rather than updating it. Also as this is an optional standard, it makes sense to keep it in a draft stage until we have sufficient confidence to more to Accepted/Final (this would avoid multiple DIP deprecation/updates).

From https://dip.diem.com/overview Deprecated – The DIP Manager or Maintainers may mark a DIP Deprecated if it is superseded by a later proposal or otherwise becomes irrelevant. Final – The Final state of a DIP means the necessary implementations of the DIP are complete and deployed to the codebase. This DIP represents the current state-of-the-art. A Final DIP should only be updated to correct errata. (edited).

bmwill commented 3 years ago

I think this highlights a few issues with the DIP process as a whole. Specifically that DIPs cannot be looked at as a cohesive Specification. In particular it might be more ideal to have a single offchain Specification (that includes everything) and instead use the DIP process as a way to propose and ratify changes to said specification.

davidiw commented 3 years ago

At this point, the plan is to take this content and leverage it in a spec instead of updating the DIP. Once the spec is fully written, we should eliminate referring to DIPs from our nomenclature and instead refer to the spec.