|
3319
|
1 ---
|
|
|
2 labels:
|
|
|
3 - 'Stage-Alpha'
|
|
|
4 summary: 'XEP-XXX: Cloud push notifications for MUC'
|
|
|
5 ---
|
|
|
6
|
|
|
7 # Introduction
|
|
|
8
|
|
|
9 This is an experimental fork of [mod_cloud_notify](https://modules.prosody.im/mod_cloud_notify.html)
|
|
|
10 which allows a [XEP-0357 Push Notifications App Servers](https://xmpp.org/extensions/xep-0357.html#general-architecture)
|
|
|
11 to be registered against a MUC domain (normally they're only registered against
|
|
|
12 your own chat server's domain).
|
|
|
13
|
|
|
14 The goal here is to also enable push notifications also for MUCs.
|
|
|
15
|
|
|
16 In contrast to mod_cloud_notify, this module does NOT integrate with
|
|
|
17 mod_smacks, because a MUC can't access a remote user's XEP-0198 queue.
|
|
|
18
|
|
|
19 Configuration
|
|
|
20 =============
|
|
|
21
|
|
|
22 Option Default Description
|
|
|
23 ------------------------------------ ----------------- -------------------------------------------------------------------------------------------------------------------
|
|
|
24 `push_notification_with_body` `false` Whether or not to send the message body to remote pubsub node.
|
|
|
25 `push_notification_with_sender` `false` Whether or not to send the message sender to remote pubsub node.
|
|
|
26 `push_max_errors` `16` How much persistent push errors are tolerated before notifications for the identifier in question are disabled
|
|
|
27 `push_notification_important_body` `New Message!` The body text to use when the stanza is important (see above), no message body is sent if this is empty
|
|
|
28 `push_max_devices` `5` The number of allowed devices per user (the oldest devices are automatically removed if this threshold is reached)
|
|
|
29
|
|
|
30 There are privacy implications for enabling these options because
|
|
|
31 plaintext content and metadata will be shared with centralized servers
|
|
|
32 (the pubsub node) run by arbitrary app developers.
|
|
|
33
|
|
|
34 ## To test this module:
|
|
|
35
|
|
|
36 The [Converse](http://conversejs.org/) client has support for registering push
|
|
|
37 "app servers" against a MUC.
|
|
|
38
|
|
|
39 You specify app servers with the [push_app_servers](https://github.com/conversejs/converse.js/blob/master/docs/source/configuration.rst#push_app_servers)
|
|
|
40 config setting.
|
|
|
41
|
|
|
42 And then you need to set [allow_muc_invitations](https://github.com/conversejs/converse.js/blob/master/docs/source/configuration.rst#allow_muc_invitations)
|
|
|
43 to `true` so that these app servers are also registered against MUC domains.
|
|
|
44
|
|
|
45 Then, when you enter a MUC, Converse will try to automatically registered the
|
|
|
46 app servers against the MUC domain.
|
|
|
47
|
|
|
48 Note: currently Converse currently doesn't let you register separate app servers for
|
|
|
49 a MUC domain. The same app servers are registered for the MUC domain and your
|
|
|
50 own domain.
|
|
|
51
|
|
|
52 ## To be done:
|
|
|
53
|
|
|
54 We currently don't handle "ghost connections", users who are currently offline
|
|
|
55 but the XMPP server is not yet aware of this and shows considers them online in
|
|
|
56 the MUC.
|
|
|
57
|
|
|
58 Prosody already checks for error bounces from undelivered groupchat messages
|
|
|
59 and then kicks the particular user from the room.
|
|
|
60
|
|
|
61 So these ghost connection users eventually get kicked from the room.
|
|
|
62
|
|
|
63 We now need a module that fires an event when a groupchat messages can't be
|
|
|
64 delivered to an occupant. The module can look up the undelivered message in MAM
|
|
|
65 and include it in the event.
|
|
|
66
|
|
|
67 In mod_muc_cloud_notify we can then listen for this event and send out a push
|
|
|
68 notification.
|
