adding done:
- multi steward support sections such as: consensus types, big and small
type flows
- new two de-mls term epoch and backup steward
- violation list section
- who can initiate the consensuses
- deterministically creation of the steward list (against biased list)
- order of the consensus messages
- adding member-id as 160 bit id
- adding flexible committing for multiple steward
- unifying the commit among multiple committing for specific epoch
- clarifying minimum number of steward list s_min and the scenario that
group member number getting below this
next (in a separate PR)
- introducing peer scoring (currently we only kicked off malicious
members)
- anti deadlock mechanism in case of non-active steward (even if the
committing is flexible now)
- identifying the format of dishonesty evidence
---------
Co-authored-by: Ekaterina Broslavskaya <seemenkina@gmail.com>
Co-authored-by: Jazz Turner-Baggs <473256+jazzz@users.noreply.github.com>
Update the 21/WAKU2-FAULT-TOLERANT-STORE status to deleted. Added to the
deprecated folder, but actual status must be deleted as only stable RFC
can be deprecated.
Added SDS-R, an (optional) extension of SDS to allow for coordinated
repair of missing messages over a limited time window.
It functions by allowing subgroups of participants to rebroadcast
dependencies that were reported missing by other participants. As with
the rest of SDS, it aims to scale to larger groups first and could
likely be simplified for 1:1 or small group chats. To prevent an
explosion in repair requests or broadcast storms, it uses backoff timers
to prevent multiple participants from performing the same action (either
request a repair or rebroadcast in response to a repair request) in a
probabilistic manner.
Note that what is still missing is a specified recommended way to use
SDS-R in conjunction with retrieving missing dependencies from Store
nodes.
---------
Co-authored-by: fryorcraken <110212804+fryorcraken@users.noreply.github.com>
Lamport timestamps should remain close to current time (in milliseconds)
for new joiners to be able to have their messages ordered reasonably
close to other messages in the channel.
This means that:
- the `timestamp` field should be large enough to accommodate
millisecond resolution timestamps, i.e. `uint64` (see
https://github.com/vacp2p/rfc-index/pull/195 for reasoning)
- the lamport timestamp should be updated before sending _each_ message
to `max(timeNowInMs, current_lamport_timestamp + 1)`.
The current spec only indicated that Lamport timestamps should be
_initialised_ to current time, which means that the logical timestamp
would soon drift from current time.
Changed Lamport timestamp initialization from nanoseconds to
milliseconds. The current time in nanoseconds exceeds JavaScript's
Number.MAX_SAFE_INTEGER, making nanosecond precision unsuitable for
JavaScript implementations. Milliseconds provide sufficient precision
while remaining well within safe integer bounds for decades to come.
This simple, scalable and decentralized consensus is for using in
decentralization MLS RFC.
todo:
- [x] solve lints
- [x] refine the RFC: adding liveness and time expiration section, also
default counting silent peers (peers that dont participate the voting)
- [x] add references
- [x] add license
- [x] first round reviewing
- [x] second round reviewing
- [x] last round review
---------
Co-authored-by: Ekaterina Broslavskaya <seemenkina@gmail.com>
Removing Waku terminology (Waku v2). Updating links, grammar and some
formatting changes. A path to stable should be considered as
implementation has not been revisited for two years.
---------
Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>
Updates include changing links, removing deprecated specs, and adding
updated specs.
---------
Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>
An update of the 12/WAKU2-FILTER RFC. Some rearrange some sections,
updated links and terms.
---------
Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>
Changes here address the bulk of what is necessary for
https://github.com/waku-org/pm/issues/266 and
https://github.com/status-im/status-go/issues/5821 to define the new
shared-shard strategy for Communities.
This PR should be enough unblock implementation and, once merged, we can
go ahead with the pubsub topic changes in status-go.
I'm not yet closing the accompanying deliverable, as the spec still
requires a full list of all Communities-related messages with functional
scope explicitly assigned.
