Chat Cast

.wordlist.txt

@@ -8,13 +8,15 @@ AutoShardingConfig
 bool
 camelCase
 cd
+centric
 config
 ConnectionStatus
 ConnectionStatusEvent
 contentTopic
 contentTopics
 createNode
 creativecommons
+cryptographic
 danielkaiser
 DefaultAutoShardingConfig
 DefaultMessageValidation
@@ -26,8 +28,8 @@ DISCV
 DoS
 enrtree
 enum
-Eth
 eth
+Eth
 ETH
 EventEmitter
 EventSource
@@ -47,9 +49,11 @@ iana
 IANA
 IDL
 implementor
+Inclusivity
 Init
 ipv
 iterable
+Jazzz
 KiB
 Kozlov
 libp
@@ -58,8 +62,8 @@ LIGHTPUSH
 md
 MessageEnvelope
 MessageErrorEvent
-MessageEvents
 messageEvents
+MessageEvents
 MessagePropagatedEvent
 MessageReceivedEvent
 MessageSendErrorEvent
@@ -70,30 +74,38 @@ multiaddr
 NetworkConfig
 NetworkingConfig
 nim
-NodeConfig
 nodeConfig
+NodeConfig
 num
 Oleksandr
 onEvent
 OpenAPI
 PartiallyConnected
 PascalCase
+Pax
 Prathi
-Prem
 pre
+Prem
 ProtocolsConfig
 pubsub
+pubsub
+Raya
+Raya's
 RequestId
+responder
+rfc
 rfc
 RFC
-RLN
+RFC
 rln
+RLN
 RlnConfig
 Royer
-RPC
 rpc
-SHARDING
+RPC
+Saro
 sharding
+SHARDING
 subnets
 SubscriptionError
 TBD
@@ -106,8 +118,8 @@ TWN
 udp
 UDP
 uint
-Waku
 waku
+Waku
 WAKU
 WakuNode
 www

informational/chat_cast.md

@@ -0,0 +1,104 @@
+---
+title: CHAT-CAST
+name: Roles and Entities Used in Chat Protocol Documentation
+status: raw
+category: Informational
+tags: [chat/informational]
+editor: Jazzz <jazz@status.im>
+contributors:
+---
+
+## Abstract
+
+This document defines a reusable cast of characters to be used in chat protocol documentation and related supporting materials.
+The goal is to improve clarity and consistency when describing protocol roles, actors, and message flows.
+
+## Background
+
+When documenting applications and protocols, it is often beneficial to define a consistent set of characters representing common roles.
+A shared cast allows authors to convey meaning and intent quickly to readers.
+Readers are not required to understand these meanings, however consistent usage can make comprehension faster to achieve. 
+
+This approach is well established in cryptographic literature, where `Alice` and `Bob` are commonly used to describe participants in key exchange protocols.
+Within that context, Alice typically initiates the exchange and Bob responds.
+Readers familiar with this convention can quickly understand protocol flows without additional explanation.
+
+In messaging and communication protocols, a similar approach can be helpful, particularly when describing multiple actors and roles required for correct protocol operation.
+However, reusing `Alice` and `Bob` in these contexts can introduce ambiguity:
+
+- In cryptography, Alice is the initiator of a key exchange, but in a communication protocol the initiator role may vary by sub-protocol or phase.
+- Complex, multi-step systems may embed multiple cryptographic and application-level processes, each with their own initiator and responder.
+- The use of Alice and Bob implicitly frames the discussion as cryptographic, which may be misleading when describing application-level behavior such as message encoding, routing, or reliability.
+
+For these reasons, when documenting communication protocols that integrate multiple roles and procedures, it is preferable to use a context-specific cast of characters designed for that domain.
+
+## Guidelines
+
+### Use of Alice and Bob
+
+`Alice` and `Bob` SHOULD be used when describing novel cryptographic constructions or key exchange mechanisms that are not embedded within higher-layer communication protocols.
+These names are widely understood in cryptographic contexts, and introducing alternatives would reduce clarity.
+
+Communication protocols may incorporate cryptographic components, but they are not themselves cryptographic key exchanges.
+When documenting application-centric or protocol-level processes, the cast defined in this document SHOULD be used instead.
+This separation establishes clear contextual boundaries and prepares the reader to reason about different layers independently.
+
+### Standalone Documents
+
+Knowledge of this cast MUST NOT be a requirement to understand a given document.
+Documents MUST be fully standalone and understandable to first-time readers.
+
+### Consistency
+
+Use of the cast is optional.
+Characters SHOULD only be used when their presence improves understanding.
+Using characters in the wrong context can negatively impact comprehension by implying incorrect information.
+It is always acceptable to use other identifiers.
+
+## Character List
+
+The following characters are defined for use throughout the documentation of chat protocols. Documentation and examples focus on a portion of a real clients operation for simplicity. Using the character who corresponds to the role or perspective being highlighted, can help convey this information to readers.
+
+**Saro**  
+Sender ::
+Saro is the participant who sends the first message within a given time window or protocol context.
+Saro MAY be the party who initiates a conversation, or simply the first participant to act relative to a defined starting reference.
+
+**Raya**  
+Recipient ::
+Raya is the participant who receives the first message sent by Saro.
+After the initial exchange, Raya MAY send messages and behave as a regular participant in the conversation.
+When documenting message receipt or processing, Raya’s perspective SHOULD be used.
+
+**Pax**  
+Participant ::
+Pax represents an additional member of a conversation, typically in a group context.
+Pax is often used when the specific identity or perspective of the participant is not relevant to the discussion.
+
+## Decision Criteria
+
+The following criteria SHOULD be applied when considering the introduction of new character names or roles.
+
+### Clarity
+
+Names without strong pre-existing associations or implied behavior SHOULD be preferred where possible.
+
+### Brevity
+
+Short, easily distinguishable names SHOULD be preferred, provided they do not reduce clarity.
+
+### Inclusivity
+
+The cast of characters SHOULD be diverse, culturally neutral, and avoid reinforcing stereotypes.
+
+### Mnemonic Naming 
+
+Where possible the characters name should hint at their role in order to make them easier to remember.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## References
+
+[A global cast of characters for cryptography](https://github.com/jhaaaa/alix-and-bo)