]> Cisco

fluffy@iii.ca

Cisco

snandaku@cisco.com

Applications and Real-Time Media Over QUIC MoQ MOQT MOCHA Reactions Emoji This document specifies reactions for MOCHA (MoQ Open Communication & Hosting Architecture). It supports message-targeted reactions (emoji on a specific chat message) and standalone reactions (engagement signals such as applause or raised hands). About This Document Status information for this document may be found at . Discussion of this document takes place on the Media Over QUIC Working Group mailing list (), which is archived at . Subscribe at .

Introduction This document specifies how MOCHA enables real-time reaction exchange using MOQT's publish/subscribe model. Two modes are supported:

Message-Targeted Reactions:

Emoji responses referencing a specific chat message MsgID.

Standalone Reactions:

Standalone engagement signals (applause, raised hands) directed at the channel as a whole.

Both modes use the same track structure.

Conventions and Definitions See BCP 14 . This document uses terminology defined in and MOQT primitives defined in . Message identifiers (MsgID) are defined in .

Reaction Track Naming

Reactions Namespace , , "reactions", , , ) ]]> HClientID and HDevID are derived per , Section "Identifier Derivation".

Track Names Each device publishes reactions on its own track: ]]>

Object Semantics Within each group, reactions are assigned sequentially increasing Object IDs starting at 0. Each reaction occupies one MOQT object.

Reaction Format

Encoding Reactions are encoded as JSON and compressed per the MOCHA_COMPRESSION track property defined in .

Reaction Structure ", "devId": "" }, "target": { "msgId": "a1b2c3...f0a1b2" }, "ext": {} } ]]>

Fields

type (REQUIRED):

Integer reaction type. See .

value (REQUIRED):

String identifying the specific reaction (e.g., "thumbs-up", "fire", "raise").

ts (REQUIRED):

Creation time in milliseconds since Unix epoch.

sender (REQUIRED):

Object with userId and devId fields.

target (OPTIONAL):

Object with msgId field (hex-encoded MsgID per ). Present for message-targeted reactions; absent for standalone reactions. {#target-field}

ext (OPTIONAL):

Extension fields. Implementations MUST ignore unknown keys.

Reaction Types

Value	Name	Description
1	emoji	Emoji reaction (heart, fire, thumbs-up)
2	vote	Poll or vote response
3	raise	Raise/lower hand
4	applause	Applause or cheer
5	custom	Application-defined reaction

Extensible via IANA registry.

Reaction Value Encoding Each reaction type defines integer encodings for its values: Emoji (type 1):

Integer	Value
1	thumbs-up
2	thumbs-down
3	heart
4	fire
5	laugh
6	sad
7	wow
8	clap
9	thinking
10	eyes

TODO: The range of emoji values to be supported is not clear at this point and further discussion is needed. Values 11-127 are reserved for future standard emoji. Values 128+ are available for application-defined emoji. Raise (type 3):

Integer	Value
1	raise
2	lower

Vote (type 2) and Applause (type 4) value encodings are application-defined.

Reaction Removal To retract a reaction, a device publishes an object with the same type, value, and target, plus "remove": true. The receiver removes the matching reaction from display.

Sending Reactions To send a reaction, a device publishes a MOQT object to its track within the reactions namespace.

Rate Limiting

• Message-targeted: At most 1 reaction of a given type per message per device (newer replaces older).
• Standalone: At most 1 reaction per second per device.

Relays MAY enforce rate limits and drop excess objects.

Receiving Reactions A participant discovers reaction tracks via SUBSCRIBE_NAMESPACE on the reactions namespace prefix, then subscribes to the announced tracks.

Processing Message-Targeted Reactions

1. Look up the referenced MsgID in the local message store.
2. Display the reaction on that message.
3. Same sender + same type + same target: newer replaces older.
4. If remove=true, remove the matching reaction.

Processing Standalone Reactions

1. Display as a transient signal (e.g., floating emoji, applause indicator).
2. For raise-hand: maintain a queue until "lower" is received.

Security Considerations TODO

IANA Considerations TODO

Normative References Cisco Google Google Meta This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments TODO