You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is part of the Waku ambient discovery roadmap (new roadmap issue to be opened in the research repo; will edit/update this description once the roadmap issue is open)
and tracks the editing of a new RFC specifying a Waku capability push protocol.
(also see #520)
Background
In its first version, it will simply be libp2p identify/push
with restrictions on specific fields.
Reasons for having a separate Waku spec instead of simply using libp2p identify/push may be found in #520.
Reasons for having a separte RFC for capability-push and not make it part of #520, even though these protocols are very similar with respect to the transmitted messages:
these protocols are semantically different
these protocols might develop in different directions
imo, each RFC should only specify a single protocol ID.
(Sill, I could merge these two into one, if desired.)
The text was updated successfully, but these errors were encountered:
Reference issue: vacp2p/rfc#521
Author: kaiserd
This issue is part of the Waku ambient discovery roadmap (new roadmap issue to be opened in the research repo; will edit/update this description once the roadmap issue is open)
and tracks the editing of a new RFC specifying a Waku capability push protocol.
(also see #520)
Background
In its first version, it will simply be libp2p identify/push
with restrictions on specific fields.
Reasons for having a separate Waku spec instead of simply using libp2p identify/push may be found in #520.
Reasons for having a separte RFC for capability-push and not make it part of #520, even though these protocols are very similar with respect to the transmitted messages:
(Sill, I could merge these two into one, if desired.)
The text was updated successfully, but these errors were encountered: