Add chat cast

.wordlist.txt

@@ -15,6 +15,7 @@ contentTopic
 contentTopics
 createNode
 creativecommons
+cryptographic
 danielkaiser
 DefaultAutoShardingConfig
 DefaultMessageValidation
@@ -26,8 +27,8 @@ DISCV
 DoS
 enrtree
 enum
-Eth
 eth
+Eth
 ETH
 EventEmitter
 EventSource
@@ -58,8 +59,8 @@ LIGHTPUSH
 md
 MessageEnvelope
 MessageErrorEvent
-MessageEvents
 messageEvents
+MessageEvents
 MessagePropagatedEvent
 MessageReceivedEvent
 MessageSendErrorEvent
@@ -70,30 +71,36 @@ multiaddr
 NetworkConfig
 NetworkingConfig
 nim
-NodeConfig
 nodeConfig
+NodeConfig
 num
 Oleksandr
 onEvent
 OpenAPI
 PartiallyConnected
 PascalCase
+Pax
 Prathi
-Prem
 pre
+Prem
 ProtocolsConfig
 pubsub
+pubsub
+Raya
 RequestId
 rfc
+rfc
+RFC
 RFC
-RLN
 rln
+RLN
 RlnConfig
 Royer
-RPC
 rpc
-SHARDING
+RPC
+Saro
 sharding
+SHARDING
 subnets
 SubscriptionError
 TBD
@@ -106,8 +113,8 @@ TWN
 udp
 UDP
 uint
-Waku
 waku
+Waku
 WAKU
 WakuNode
 www

informational/chat_cast.md

@@ -0,0 +1,90 @@
+---
+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 without repeatedly redefining actors and their properties.
+
+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 by readers in cryptographic contexts, and introducing alternative names in such cases is likely to reduce clarity rather than improve it.
+
+Communication protocols may incorporate cryptographic components, but they are not themselves cryptographic key exchanges.
+Descriptions of encodings, payload formats, transport behavior, or reliability mechanisms would be out of place in a cryptographic specification.
+
+When documenting processes that are primarily application-centric or protocol-level, 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.
+
+## Character List
+
+The following characters are defined for use throughout the documentation of chat protocols.
+
+**Saro**  
+The initial 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**  
+The initial 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**  
+A generic 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.
+
+## 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)