From f2b8893e1def3600ce7d66290519a7a209a163f9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Fri, 29 Nov 2024 16:36:58 +0100 Subject: [PATCH] New ProtoXEP: MUC Activity Indicator --- inbox/muc-activity.xml | 151 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 151 insertions(+) create mode 100644 inbox/muc-activity.xml diff --git a/inbox/muc-activity.xml b/inbox/muc-activity.xml new file mode 100644 index 00000000..ec40d930 --- /dev/null +++ b/inbox/muc-activity.xml @@ -0,0 +1,151 @@ + + +%ents; +]> + + +
+ MUC Activity Indicator + This specification provides querying entities an approximate indication of the level of activity in a given XEP-0045 Multi-User Chat room. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XEP-0030 + XEP-0045 + XEP-0128 + + + + NOT_YET_ASSIGNED + + &jonaswielicki; + + 0.0.1 + 2024-11-29 + jsc +

Initial submission.

 + +
+ +

Currently, the only activity metric available to entities considering + interacting with a &xep0045; chat is the number of occupants which is + published in the &xep0030; response.

+

However, the number of occupants alone is not a great metric for + usefulness of a chat. On the one end of the spectrum there may be highly + active, but small, groups of experts on a specific topic who are happy to + help. On the other end of the spectrum there may be huge chats consisting + mostly of lurkers.

+

This specification introduces a new field in the disco#info data which + gives an indication of the rate at which messages are sent in a given + group chat.

+ + +
    +
  • MUST NOT impose excessive computing requirements on servers.
    • +
  • MUST be useful as rough indicator.
    • +
+ + + +

To request the current level of message activity, an entity sends a standard &xep0030; information request to a MUC's address:

+ + + +]]> +

Services implementing this specification MUST return the {urn:uuid:86b614b6-e64d-436c-bd6d-6f0b5d7f2e53}message-activity field, if:

+
    +
  • The room is persistent, and
    • +
  • The room is public, and
    • +
  • The data is currently available.
    • +
+

The field MUST contain an approximation of the number of messages sent per hour in this room as floating point value. For example approximation approaches, see the Implementation Notes below.

+ + + + + + http://jabber.org/protocol/muc#roominfo + + + + 23.42 + + + + +]]> +

In particular, services MUST omit the field entirely if the above preconditions are not met. Services MUST NOT put placeholder values in the field.

+ + + +
    +
  • The value provided in the form field MUST be in units of messages per hour.
    • +
  • The time frame over which this number is derived is service-defined. However, services SHOULD NOT take into account messages which are older than 72 hours.
    • +
  • Services MUST NOT count messages without a <body/> element, unless it is known that this message would be rendered as standalone message on a compliant client nontheless.
    • +
  • Services MUST NOT count messages where the type is not groupchat; in particular, they MUST NOT count private messages among occupants.
    • +
  • Services SHOULD NOT count &xep0308; messages.
    • +
  • Consumers MUST NOT assume that the number is exact.
    • +
  • Consumers MUST NOT assume that the number is updated in real-time.
    • +
  • Services SHOULD update the number at least once per hour.
    • +
+ + +

The obvious "correct" implemetation to provide the message rate would be + to, internally, query the number of messages sent in the room since its + inception and divide that by the number of hours since its inception. + Such an implementation is likely to be expensive, in particular for large, + high-traffic rooms.

+

In order to cater for that, the Business Rules + allow for some significant leeway in how implementations approximate the + number of messages per hour.

+

For implementations where fetching the number of messages in a certain + time frame is too expensive, the following simplified approach is + outlined: For each MUC, allocate a shift register of 25 counters. Whenever + an eligible message is broadcast through the MUC, increase the first + counter. Every hour, shift the counters onward (so that the first counter + becomes the second and so on) and reset the first counter to zero. Whenever + the message rate is requested (via disco#info or otherwise), sum the + counters two through 25 and divide the sum by 24.

+

That way, only constant storage per MUC and constant CPU time per message + and request is required. As a trade-off, this introduces a latency of one + hour for updating the counter.

+ + +

This specification does not introduce new user interaction concepts.

+ + +

Services MAY translate the label attribute of the field according to + the language indicated in the requester's IQ stanza.

+ + +

Services MUST choose a sufficiently cheap algorithm to provide the + message activity indicator. Otherwise, they are open to trivial + denial-of-service attacks by high-rate disco#info requests.

+ + +

Services MUST NOT publish message activity indicators for MUCs which are + not publicly listed (muc_public feature flag) or where users + would need some kind of specific authorization to join (such as a password + or the member affiliation).

+ + +

No IANA interactions required.

+ + +

The form field should be registered, eventually.

+ +