mirror of
https://github.com/logos-messaging/specs.git
synced 2026-02-16 12:13:09 +00:00
Chat Cast (#99)
* Add chat cast * add clarity about usage * Updated roles * Update Wordlist.txt
This commit is contained in:
Jazz Turner-Baggs
GitHub
parent
ed7b40c064
commit
62c783ce21
@ -8,6 +8,7 @@ AutoShardingConfig
|
||||
bool
|
||||
camelCase
|
||||
cd
|
||||
centric
|
||||
config
|
||||
ConnectionStatus
|
||||
ConnectionStatusEvent
|
||||
@ -15,6 +16,7 @@ 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
|
||||
|
||||
104
informational/chat_cast.md
Normal file
104
informational/chat_cast.md
Normal file
@ -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)
|
||||
Loading…
x
Reference in New Issue
Block a user