ILIAS Push Notification Service

1 Initial Problem

Only pull information handling

Users are typically informed by getting informations delivered. ILIAS supports this behavour only by using mails. Since not all ILIAS notifications are supported by ILIAS mails it is necessary for users to pull informations by visiting the ILIAS instance. This leads to the problem, that students may struggle to keep up with deadlines and assignments. A push notifications handling could help students by providing timely reminders about upcoming assignments, quizzes, and exams.

Several device types are used

With the increasing wide range of devices (Laptop, Desktop, Mobile) used by students it is crucial to get all these addressed. There is a lack of a Userfriendly integration for all device types.

Lack of interaction and communication

Furthermore, there is a lack of communication and interaction between students due to the fact, that, despite ILIAS mail, no real-time notifications are supported.

Amount of mails

ILIAS only supprt notifications via mail. These are for example used to inform about a course partipation. If multiple other notifications shall be transported by ILIAS, there will an amout of mails. Important mails may be missed due to the amount of mails send. Due to this, the visibility for users regarding new events is insufficient.

Missing of a volatality level

ILIAS only has two extremes of volatile notifications. The toast, which is very volatile and therefore has a risk of being not acknowledged. And the mail, which is not volatile at all and therefore has a risk of being outdated to the time it is acknowledged.
Conceptionally, there is no way to provide a notification that is guaranteed to be delivered to a certain user, but also timely depend and potentially dismissed if a certain period has passed.

Missing mobile friendlyness

Regarding to a survey from ILIAS.nrw running at HSBI, students mostly are using mobile handheld devices. These users have claimed a lack of mobile communication and interaction with the used learning management system.

2 Conceptual Summary

Learning Management Systems take a huge part of modern learning. Since students are more and more using mobile devices they are used to get Informations via push notification. Push notifications can help students stay informed, especially in the aspect of time-dependend votality of information. They can also be used to deliver personalized feedback and encouragement, which can boost student motivation and engagement.

Since ILIAS has a Notification Service, certain notifications shall be handed over to the browser as push notifications. This is supported by the great majority of browsers (mobile and Desktop versions). (https://developer.mozilla.org/en-US/docs/Web/API/Push_API#browser_compatibility )

It should be possible to deactivate the functionality by the administrator. Since the browser displays a request to allow notifications an additional option within the personal settings is not necessary, but could be implemented. Nevertheless, an option to (de-)activate several ILIAS notification channels / categories should be implemented later. (c.f. mockup)

The push notifications shall provide an additional ILIAS Notifications Channel. A notification can link to its cause to allow the user a direct interaction if this is reasonable. However, there may also be notifications that only provide a "read-only" functionality due to semantical or security reasons.

3 User Interface Modifications

3.1 List of Affected Views

• Administration / Communication / Notifications
• UserSettings / Push-Notification

3.2 User Interface Details

Administration / Communication / Notifications

Since the feature is an extention of the exsting ILIAS Notification Service and works stand alone it shall be located in the Notification area below the Settings for Pop-up-Notifications.

If Push-Notifications are deactivated globally the tab within the User Setting will not appear.

• (De-) Activating the Push Notification Service globally

This toggle will be deactivated as default.

UserSettings / Push Notification

The user could active or deactivate the Push Service by themself. This tab will only appear if the usage of Push Notifcation is activated globally within the Administration

With upcoming Implementations of this feature channel-based selection (see https://docu.ilias.de/go/wiki/wpage_8160_1357) will be located here as well. If the toggle is turned off, all checkbox shall be automatically deactived.

The toggle will be activated as default, if the administrator enables the functionality.

Push Request

Push Request (mobile View)

Depends on the browser

Push Content

Push Content

Depends on the browser and the operating system. (Example given for Chrome/Ubuntu)

• Label: Name of ILIAS Instance
• Description: Notification Title
• Badge: Icon of ILIAS Instance
• Action: optional (context-sensitive)
• Photo: optional

Any content of push notifification is not part of this FR. It will be disscussed in upcoming FR with propose the target notifications.

3.3 New User Interface Concepts

There are options to create a individual request for push allowance by ILIAS.
However, this is not recommended since the default presentation if used conventional but most providers and an own interpretation could cause issues wihtin the ongoing development of implementation to verifiy the consumer rights (just like cookie acceptances and AGBs). This resulted from the disscusion with the UI Experts.

3.4 Accessibility Implications

4 Technical Information

Notifications are delivered via an internal service worker. The service worker will be registered through the allowance of push notification.
Initially, the registration implies the subscription, and the unregistration removes the subscription.
The removal of a registration leaves no trace of the service worker inside the browser beside a "deletion" entry.

In future ILIAS could provide multiple subscriptions for different cases. In this case the registration would be permanent until it's directly removed from a user via the development tools. (That is a common approach. Service workers are not meant to be actively removed)

Service Worker and their provided notifications are application-specific. There is no way to synchronise workers (e.g. of the same user) via the Push service automatically.
(There are ways for manual synchronisation, but those are not recommended)

Every host can only implement one service worker. Since no service worker is implemented currently inside the core, this does not cause any conflicts.
This might affect plugins if one intends to implement a service worker or already has implemented one.

There are no plans to extend the service worker for other services except the internal push notification service. There is no intent to provide an interface to collect another service worker handling.
(For clarification: this does not affect push notifications, only their handling).

Service workers don't work with polling like toasts. Therefore, the global activation and deactivation has no effect on the browser/webside performance or behaviour itself.
However, the push of a huge number of notifications in one request (internally) may result in a recognisable workload and minor delays. Statisticly speaking, such calls are very rare and should be resolved by queueing.

The distribution of Push notifications will be integrated into the already consisting ILIAS Notification System. Any new kind of Push notification will be provided over this interface.

Browser Compatibility

This List refers to: api.PushEvent

Date: 2024-09-11

This List refers to: api.PushMessageData

Date: 2024-09-11

5 Privacy

Notification are handed over to a internal service worker via a cloud service provided by the browser (e.g. FCM for Chrome).
The usage of such services is content of the general AGBs of target browsers and no matter of ILIAS.

Push notification are shown publicly on a device without any user interactions and therefore should not display sensible data. They may link to such data via an action.
Future Push Notifications with sensible content should therefore be discussed by the Jour fixe.

Subscription data of the service worker will be saved internally inside the ILIAS database and will be linked to the user ID.
The required data does not contain any information about the device or endpoint from which the subscription is received, that data is stored inside the cloud service provider.
The data can be used to send push notifications but nothing else.

Criterias for push notification will be derived from the linked user_id only.

Furthermore this service could be deactivated globally in the administration.

6 Security

Push notifications are verified through a generated VAPID Key. This key should be part of the ILIAS setup and not accessible within the UI.
In the current state, the implementation of an internal service worker requires algorithms of the NodeJS libraries "http_ece" and "crypto" and therefore depends on their security (which is non-critical currently).
A fully independent implementation is assumed to be possible.

Push notifications are secured by paired algorithms of SHA256 and P256 as an elliptic curve, which is considered save.
Further, push notification are required to use SSL by the browser/provider.

7 Contact

• Author of the Request: Stake, Sebastian [sstake], Szmais, Ingmar [iszmais]
• Maintainer: Jansen, Michael [mjansen]
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• Technische Hochschule Ostwestfalen-Lippe
• Hochschule Bielefeld
• ILIAS.nrw

9 Discussion

Szmais, Ingmar [iszmais] 25 SEP 2024: We reworked this request conceptionally due to the now investigated option of providing an internal service workers and considering the given questions of the UI Clinic. With the new advantages most of the initial technical concerns can be handled internally and most UI concern are hand over to the browser and are not part of ILIAS anymore. Therefore we consider this Feature Request ready to be proposed to the JF.

Klees, Richard [rklees] for the Technical Board (2024-10-18):

Dear Ingmar and Sebastian,

we discussed this Feature Request in our Technical Board meeting on tuesday. As some of us already expressed on JF, we again had a hard time to understand what it is that was actually appreciated or approved here. We discussed several questions regarding the actual content of this request but had doubts in the possible answers to these questions and also had a hard time to find definitive answers in the feature requests. Some of these questions were:

* Is this about a general appreciation that ILIAS should support Push Notification for some use cases? If so, why are there mock ups and so many detailed information about implementations etc.?
* Is this looking to actually make existing notifications available as Push Notification? If so, why is this request so vague regarding the actual notifications that will be available via Push Notification? Why do the mock ups contain e.g. "...weitere Ideen"?
* Is this about a new channel for the Notification System? If so: Why does the titel indicate a new "Service"? Why won't it be available for existing notifications?
* Is this about a new service that shall be available to other components besides the Notification Service as well? If so, why are there no considerations regarding the question if we actually want a service that triggers Push Notifications independently from the Notification System? Why are there no information about the interface to such a service? Have developers been asked, as the colleagues from the UI clinic suggested?
* The request mentions some existing implementation and NodeJS libraries. Is this a way to look for approval of the general implementaton or a way to look for approval of the mentioned dependencies to the core? Why did we discuss code in the form of a Feature Request on the JF?
* What is the actual functionality that you are requesting via this FW entry? There is a conceptual summary and some mockups, but both contain conditionals, such as "could be implemented", "...weitere Ideen". There is no actual description of a coherent concept from the perspective of functionality. How would someone derive some expectation towards this "feature" (?) and its functionality? How would one write testcases based on the sparse conceptual information?

We are not asking you to write down answers to these questions now, but we are a afraid that this is not clear to you, us and other people in the community and hence will cause friction down the line. We had problems in the past with feature requests that had no clear target functionality or concept. Frankly, this feels a little like a solution looking for a problem. This would have been a lot easier to discuss starting with an actual problem, e.g. "Students are not aware that Excercises end".

Please make sure to understand, that we are neither pro or contra Push Notifications. Based on this request here we simply cannot tell. Also, we are not vetoing this, as we find it hard to understand the actual content of this, as described above. We would suggest though, that you clarify these points and present a more concise version at an upcoming JF to avoid future problems and unexpected discussions. If you decide against this we ask you to move on carefully regarding this topic. Please understand that there most probably will be questions and discussions down the line that will arise when you try to translate this into actual functionality.

As always feel free to ask for concretization and advice.

Thanks!

10 Implementation

{ The maintainer has to give a description of the final implementation and add screenshots if possible. }

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Privacy

Information in privacy.md of component: updated on {date} by {user} | no change required

Approval

Approved at {date} by {user}.