Telegram

Make the following config:

"Telegram": {
  "notifications": {
    "public": {
      "streams": {
        "types": {
          "Streams/interest": 1,
          "Streams/experience": 1,
          "Streams/calendar": 1
        }
      }
    }
  }
}

When people subscribe to streams of this type, the Node.js will skip Device notifications and send the notifications to public chat, if the community $publisherId publishing the stream has an xid which is a chat_id with a bot. You'll have to do Users_ExternalTo::select("userId" => $communityId, "platform" => "telegram") in order to get xids from communityId, you may get one or more bots (appId) and chats (xid).

For each one, send a message with the notification text from device.handlebars template, that might include an inline keyboard (with URL to open mini app, and see the standard URL from notification).

If the stream has an attribute ("Telegram/topic/id") then please specify this topic as "message_thread_id" when sending the message. Don't worry about how the streams will have this attribute, for now. However, you should also have a hook for when a stream of the given type is created, so you can create the topic, and set the attribute "Telegram/topic/id" on the stream. When creating topic using this method you should set the "name" to be the stream's title at the time, and "icon_custom_emoji_id" (skip specifying topic color) would be taken from "Telegram/topic/emoji" attribute, if it exists, otherwise skip it also.

For widely accessible streams, we want to use channels instead of individual delivery, because it is far cheaper. Not just public streams, but we might end up having Telegram chats for small groups of paid subscribers, to receive updates from our forum or community etc. We might eventually even have a Discourse forum tied to a Qbix stream, which posts to a Telegram channel.

The types of messages posted would, as usual in Qbix, depend on the Streams_SubscriptionRule. See Streams.Message.deliver() in Node.js . Typically we subscribe users to "Streams/relatedTo" and "Streams/updatedRelateTo" types of messages, to know when a relation was added or its weight was changed.

The value of 1 in the config is the minimum weight of the relation before posting. For now, we post every message. In the future, we will wait until the relation has a minimum of X weight before delivering a notification. Don't worry about this part.