Promoting select RFCs to stable & adapting updated COSS / template

[kaiserd]

This milestone issue tracks the promotion of select RFCs to the stable status,
as well as their adaption to the updated 1/COSS and RFC template.

Blockers

For now, this issue is blocked, waiting for the store flag implementation to be in release versions of at least two Waku implementation, as well as some in-the-wild testing thereafter.
However, many of prerequisite tasks described in this issue can already be started and merged to update draft versions of the respective RFCs. Only the actual promotions to stable are blocked.

• store flag support for for 14/WAKU2-MESSAGE in nwaku release version
• store flag support for 14/WAKU2-MESSAGE in the release version of one further Waku implementation
• wait until store flag support has been successful for some time in the wild

Background

The protocols specified in the following RFCs are ready for the stable status

• 10/WAKU2
• 13/WAKU2-STORE
• 14/WAKU2-MESSAGE
• 15/WAKU-BRIDGE

This milestone issue tracks the tasks necessary for promoting these RFCs to stable.
These tasks comprise

• thorough proofreading for ambiguity or lack of clarity, as well as the respective editing
• adding a category as specified in the updated 1/COSS
• adding tags as specified in the updated 1/COSS
• adding/ordering sections as proposed in our RFC template
  • Theory / Semantics (can be named differently if appropriate)
  • Wireformat / Syntax (can be named differently if appropriate)
  • Security Considerations

In addition to these tasks, 14/WAKU2-MESSAGE should be augmented by a store flag indicating whether a message should be stored or not. As all other RFCs listed above depend on message, this should be done first.

• Proposal: Add ephemeral flag to wakuMessage #532
• Promote 14/WAKU2-MESSAGE RFC to stable state #551

Further 21/WAKU2-FAULT-TOLERANT-STORE's wire specification should be merged into 13/WAKU2-STORE
so that RFC 13 reflects what is actually being used. This is important for promoting RFC 13 to stable.

• Stabilize and normalize 13/WAKU2-STORE RFC #552

Promoting 10/WAKU2 to stable requires factoring out parts that depend on non-stable RFCs.
These parts will be covered in a new RFC.

Action Items / Issues

• add ephemeral flag to 14/WAKU2-MESSAGE
• Stabilize and normalize 13/WAKU2-STORE RFC #552
• Promote 14/WAKU2-MESSAGE RFC to stable state #551
• RFC 15: promote to stable & update to new structure
• RFC 10: promote to stable & update to new structure
  • promotion to stable includes factoring out parts that depend on non-stable RFCs
• new RFC ??/WAKU2-unstable: covers parts of original RFC 10 that depended on non-stable RFCs

[oskarth]

@kaiserd @easye What is the status of this?

[kaiserd]

@kaiserd @easye What is the status of this?

This was planned as the follow up task for @easye after #524 and #512 have been merged.

So far, work on necessary updates of message ("ephermal flag") has been started both on the

• implementation Allow messages to be marked as "don't store" waku-org/nwaku#985 feat(store): Allow messages to be marked as "don't store" waku-org/nwaku#1119 and the
• spec side Proposal: Add ephemeral flag to wakuMessage #532

[LNSD]

I am planning to do the tasks related to the stabilization of the waku store protocol:

• add FT-STORE (RFC 21) wire format spec into RFC 13 (STORE)
• Update waku store wire format: simplify the wire format (e.g., remove unnecessary levels like ContentFilters) and change the error reporting from an enum to status code plus cause string.

cc @jm-clius @fryorcraken

[jm-clius]

Thanks, @LNSD!

Some notes from my side:

1. Backwards incompatible changes (e.g. getting rid of unnecessary nesting) are allowed since the spec is still in draft status, but we'll update the libp2p protocol ID.
2. To me it makes little sense to move store spec to stable before 14/WAKU2-MESSAGE is not stable. In fact, I think this should have been done before we moved the relay spec to stable, as any breaking changes in the WakuMessage breaks all protocols.
3. @kaiserd should spec adherence to the RFC template (very important IMO) be a pre-condition for moving to stable, or would a stable wire protocol be enough? Trying to compile list of tasks related simply to rewriting for clarity and reorganising before promoting the RFCs.

[LNSD]

Ok, I will create two separate issues to tackle before the next release (v0.14.0):

• Promote 14/WAKU2-MESSAGE RFC to stable state #551
  • Make the RFC conform to the RFC template
  • Create the waku protobuf repository: vacp2p/waku
  • Add Waku Message protobuf definitions to the repository
• Stabilize and normalize 13/WAKU2-STORE RFC #552
  • Make the RFC conform to the RFC template
  • Add the new protocol's wire format (v3) to the waku store RFC. Deprecate v2-beta4
  • Merged 21/WAKU2-FAULT-TOLERANT-STORE's wire specification into 13/WAKU2-STORE
  • Add current Waku Store protobuf definitions to the waku protobuf repository (v2-alpha4)
  • Add the new Waku Store protobuf version(v3)

[kaiserd]

should spec adherence to the RFC template (very important IMO) be a pre-condition for moving to stable, or would a stable wire protocol be enough?

Imo, following the template should be a pre-condition for Standards Track RFCs.
In case the specified entity is not a protocol, sections like "Wire Format Specification" should have a different name, but the general structure should still follow the template.

[jimstir]

Closing, issue moved here