Notifications : construire un standard interopérable pour l'ensemble de l'écosystème Ǧ1

R&D
1

Notifications : construire un standard interopérable (compatible inter-app)

Pourquoi ?

Actuellement, il est difficile de joindre efficacement l’ensemble de la communauté.
Dans de nombreux écosystème, les notifications deviennent vite tellement nombreuses qu’elles sont ignorées. Bien concevoir les notifications nous aidera à éviter/limiter le problème.
Dans la V2, l’offre logicielle sera plus diversifié, si chaque logiciel gère les notificaitons à sa sauce, il sera encore plus dur de joindre l’ensemble de la communauté.
Certains événements sont plus important que d’autres.
La pertinance de certaines notification n’est que temporaire.

Comment ?

Dans la V2 nous avons un système d’indexeur qui sera requêté par tout les clients, ce qui nous ouvre des possibilité technique pour les notifications assez chouette.
On peut probablement combiner ça avec des données issue de data-pod, ou mettre certaines info de notification qui nous semble essentielle en blockchain via les remark.

Mes idées

Distinguer plusieurs types de notifications :

  • les notifications simple : le logiciel de consultation emetra une trace automatique pour notifier de la lecture sans besoin d’action dédié par l’utilisateur.
  • les notifications AR : quand l’utilisateur affiche la notification, celle-ci n’est pas considéré comme lu tant que l’utilisateur n’en confirme pas explicitement la lecture par une action manuelle de confirmation.
  • les notifications primordiale : non seulement il y a AR, mais le système tentera d’alerter l’usager par tout moyen à sa disposition (email, sms, notif aux certificateur…)

Chaque notification a :

  • un id unique
  • un auteur et un rôle en qualité du quel il emet la notification
  • un type suggéré par l’auteur (simple, AR, critique)
  • une date de péremption
  • un titre
  • une date d’émission
  • un contenu
  • une classe de diffusion (personnel (juste pour moi), comité technique, forgerons, membres, tout les comptes identifiés, probablement d’autres à l’avenir)

Chaque type de notification à également :

  • un maximum simultané (exemple : pas plus de 5 notif simple, les anciennes seront automatiquement remplacées)
  • un système de droit : qui/quel rôle peut émettre ce type de notification ?
  • des tags de qualification pour la catégoriser
  • un pattern de tags autorisé à écraser/remplacer avant péremption (incluant l’auteur ou rôle autorisé à écraser)

Les signaux de lecture contiennent :

  • un type (logiciel, manuel)
  • une date (sauf si en blochain dans ce cas le bloc l’incluant suffit’)
  • une évaluation de pertinance si renseignée (problématique/dangeureuse, dérangeante/spam, innutile, utile mais dispensable, nécessaire, primordiale)
  • des tags complémentaires (suggéré par l’interface lors de l’évaluation). Exemple : qualification de l’auteur de la notif “dans mon carnet d’adresse”, “dans mon historique de transaction des 30 derniers jours”, “dans mes certifiés”, “dans mes messsage envoyé”, mais aussi, pour les notifications collectives “pour ce type de notif”, “pour les autres destinataires de cette notif spécifique”, ou encore la possibilité de dire “obsolete” si la peremption est réglé trop tard

L’évaluation de pertinance sert à faire évoluer la catégorisation d’une notification vers simple, AR ou primordiale (ou en sens inverse) et ce avec des pondération différente pour l’utilisateur qui évalue, et pour la communauté dans son ensemble. Cela peut aussi servir à définir des règles d’écrasement de notification en cas de surnombre, pour ne garder que les plus pertinante plutôt que les plus récentes.

Idéalement, les notif périmées et/ou lu, restent consultable en archive (avec éventuellement une date de dernière consultation des archives pour distinguer les notif archivée depuis)

Chaque utilisateur peut indiquer ses préférences :

  • Catégorisation globale : Une réglette pour indiquer le % de prise en compte issue des réglages manuels de l’utilisateur, le % issue du type suggéré par l’auteur, le % de révaluation selon les évaluation individuelle, le % issue des évaluations collectives
  • Activer le déclassement des notif les moins prioritaire d’une classe de priorité si :
    • le maximum de notif à été atteint durant les n derniers jours (n = 1, 7, 30, 365, ou désactivé)
    • des notifs avec AR ou superieur ont périmé sans être lu au cours des n derniers jours
    • des notifs simple ont périmé sans être lu au cours des n derniers jours

chaque type de notif est glissable dans la classe de notif qui nous conviens le mieux :

  • Notif non classés

    • tags : transaction reçu
      • ecrase automatiquement la précédente : oui/non
    • tags : manque de certification dans 30j
      • ecrase automatiquement la précédente : oui/non
    • tags : manque de certification dans 7j
      • …
    • tags : compte membre à renouveller d’ici 30j
    • tags : compte membre à renouveller d’ici 7j
    • tags : status membre obtenu
    • tags : echec de validation de la règle de distance concernant votre compte
    • tags : echec de validation de la règle de distance concernant le compte d’un de vos certifiés
    • tags : rôle forgeron obtenu
    • tags : invitation au rôle forgeron
    • tags : invitation a devenir membre (indiquez votre identifiant/pseudo)
    • tags : certification reçu -5 (alors que vous en avez moins de 5)
    • tags : certification reçu +5 (alors que vous en avez davantage que 5)
    • tags : certification reçu +5 de quelqu’un de votre carnet d’adresse
    • tags : certification reçu +5 de quelqu’un parmis vos proches en attente de certification
    • tags : certification reçu +5 de quelqu’un que vous avez déjà certifié, mais pas renouvellé
    • tags : vote considéré par la communauté comme utile
    • tags : vote considéré par la communauté comme nécessaire
    • tags : vote considéré par la communauté comme primordiale
    • tags : notif primordiale non-lu depuis 24h par un de vos certifiés
    • tags : notif primordiale non-lu depuis 48h par un de vos certifiés
    • tags : notif primordiale non-lu depuis 3j par un de vos certifiés
    • tags : article vendu
    • tags : enchère remportée
    • tags : annonce ancienne, à re-confirmer
    • tags : nouvel article correspondant à une de vos demande/recherche
    • tags : plafond de paiement quotidien atteint
    • tags : plafond de paiement hebdomadaire atteint
    • tags : compte courant vide (plafond de paiement mensuel atteint
    • tags : prêt à certifier (et proches en attente de certification dans votre carnet d’adresse)
    • tags : prêt à certifier (et proches en attente de certification dans votre carnet d’adresse)
    • tags : message privé reçu
    • tags : message privé reçu de quelqu’un à qui vous avez déjà répondu
    • tags : message privé reçu de quelqu’un de votre carnet d’adresse
    • tags : message privé reçu d’un auteur ayant le rôle “forgerons”
    • tags : message privé reçu d’un auteur ayant le rôle “enquete double compte”
    • tags : vous êtes taggué sur un site au quel vous vous connecté en SSO via ce compte (résumé SSO)
    • tags : quelqu’un à répondu à votre commentaire sur un SSO
    • …

  • Notif ignorées

    • rigidité de la catégorisation : Une réglette pour indiquer le % de prise en compte issue des réglages manuels de l’utilisateur, le % issue du type suggéré par l’auteur, le % de révaluation selon les évaluation individuelle, le % issue des évaluations collectives

  • Notif simple/mineure

    • max simultanée
    • % de priorité aux plus récente vs % de priorité aux plus utile en cas de surnombre
    • rigidité de la catégorisation (pour ce qui est rangé manuellement dans cette catégorie)

  • Notif AR/nécessaire/importante

    • max simultanée
    • % de priorité aux plus récente vs % de priorité aux plus utile en cas de surnombre
    • rigidité de la catégorisation (pour ce qui est rangé manuellement dans cette catégorie)

  • Notif essentielle/primordiale

    • max simultanée
    • % de priorité aux plus récente vs % de priorité aux plus utile en cas de surnombre
    • rigidité de la catégorisation (pour ce qui est rangé manuellement dans cette catégorie)

Pour les notif personnelles, l’algo détermine la classe de notif par un score, et l’utilisateur est notifié dans la classe de priorité de notif la plus proche du score en question (dans sans changement de réglage ou d’évaluation, chaque notif du même type arrive dans la même classe de priorité.

Pour les notifs collectives, en fonction du nombre de personne qui evalu la notif et des évaluation données, le nombre de personne notifié par classe de notification sera ajusté avec une seed correspondant au hash du bloc suivant celui où est émise la notif pour choisir qui est notifié comment de manière déterministe.

Concrètement mes questions

êtes-vous ok sur le principe avec :

  • avoir 3 classes/niveaux de notification ? (simple, avec action de l’utilisateur pour confirmer, et avec notification aux certifieurs en cas de non lecture) + la classe/niveau “ignoré” pour permettre aux utilisateurs qui le souhaite d’ignorer certaines notifications.
  • confier aux indexeurs la responsabilité de lister les notifications à afficher à chaque compte ?
  • envoyer sous forme de remark en blochain les confirmations de lecture de notification ? (confirmation automatique de présentation de la notif à l’usager par le logiciel, et le cas échéant confirmation d’action utilisateur engendré par la notification qu’il s’agisse d’une simle confirmation manuelle de lecture ou d’une action en lien avec la notif)
  • associer à chaque notification une date de péremption pour éviter leur désintérêt par surnombre ?
  • avoir un maximum de notification simultanées actives, pour la même raison ?

Si ça on est d’accord dessus, c’est déjà pas mal.
Dans un second temps, question ouverte :

  • pour pouvoir mettre en place des algo fin et adaptatif de catégorisation des notifications, compatible avec tout les clients, il faudrait un service dédié, façon oracle ou data-pod spécialisé. Ce service devrait avoir accès aux préférences utilisateur en matière de notifications. Ces préférences sont elles des données sensibles à envoyer de manière chiffré à un prestataire mandaté pour leur gestion, qui déterminera seul du sort des notif à destination de cet usagé, au risque d’abus de confiance dans ce prestataire mandaté ? Faut-il les envoyer à plusieurs prestataire mandaté pour réduire le risque d’abus, et laisse l’indexeur fusionner les résultats des prestataire en excluant ceux incohérents ? Ou faut-il considéré ces données comme publique, et permettre à n’importe quel service de les consulter ?
  • faut-il laisser toute latitude à l’utilisateur de choisir les notifications qu’il souhaite recevoir, ou y’a-t-il certaines notifications que l’on considère collectivement comme nécessaire à faire parvenir et qui ne soit donc pas désactivable ? (exemple : suspission de double compte, merci de vous rendre disponible pour une vérification d’unicité) Dans le cas ou certaines notifications sont obligatoirement activées, qui et comment décide-t-on d’émettre des notification de ce type ?
  • si certaines des notifications changent de niveaux/classe selon des données utilisateurs privées (comme la présence ou non d’un compte dans leur carnet d’adresse) comment fait-on pour que le service de notification ai accès à cette information sans la rendre publique ? → prestataire mandaté je présume, éventuellement plusieurs prestataire pour éviter les abus par recoupement des résultats. Qu’est ce qui vous semble pertinant ?

Voici mon premier jet de réflexion à ce sujet. Vos retours sont très bienvenues !

2 Likes
2

Ça ferait beaucoup d’extrinsics, et le consensus global est inutile ici.

Si on a un seul client, on peut même se suffire du stockage local pour identifier les notifs lues.

Cette information pourrait plutôt être dans les datapods, et si possible être chiffrée, car il est inutile qu’elle soit publique. La simple modification de cette valeur donne déjà des informations qu’on pourrait ne pas vouloir publier (à quelle heure on se connecte (= quand on est chez soi, par exemple), est-ce qu’on lit bien toutes ses notifs). Avec exception éventuellement pour les messages spéciaux avec mesure d’audience.

En tout cas, l’accusé de réception et la confirmation de lecture en ligne doivent pouvoir être désactivés dans les paramètres.

À condition que l’UI l’explicite, sinon on ne peut pas faire confiance aux notifs (sont-elles toutes là, si non lesquelles ont disparu et pourquoi). Pour les notifs automatiques ça pourrait être réglable par l’utilisateur, avec une valeur par défaut définie par le client. Il ne me semble pas nécessaire que la spec force cet aspect.

1 Like
3

Justement, mon enjeu est qu’on arrête de partir du principe que les gens n’utilise qu’un seul client. Que ce soit parcequ’ils en essaient plusieurs, ou parcequ’il en utilise plusieurs selon les situation, ou qu’ils ont plusieurs appareils (mobile + PC par exemple)

Mais stocker en datapod plutôt qu’en remark, oui carrément.

Je ne suis pas d’accord que c’est inutile qu’elle soit publique. Pour moi, de la même manière qu’il est utile qu’un signalement de spam soit fait publiquement pour que les autres utilisateur voir le même message cataloguer comme tel, avoir des mécanique d’ajustement de priorité des notifications selon la réaction des utilisateurs me semble utile publiquement.
Après est-ce suffisament utile au regard de l’impacte coté vie privée, là je suis d’accord qu’on peut se poser la question, mais dire que ça n’est pas utile, je ne suis pas d’accord.
Et pour réduire les métadonnées transmises, faire un aggréga quotidien des accusé reception de notif et autre retours utilisateur, plutôt que de les avoir au compte goute avec toutes les info d’horaire d’usage associé, ça me va très bien (si le client est capable d’envoyer son rapport à heure fixe, ce qui ne sera pas toujours le cas, donc ça pourrais être : premier lancement de l’app, il envoie dès que l’utilisateur valide la notif. Puis stockage local de quand l’app est lancé, et si elle l’est au moins 1 fois par jour : envoi de l’agrégat de la veille à chaque lancement, et si l’app est active y compris en arrière plan, plus de 6h par jour, selection d’une horaire aléatoire parmis celle ou l’app est généralement active, et envoi systématique à cette heure là.

Tout à fait d’accord, en indiquant les conséquences en terme d’UX de les désactiver.

Pour moi, c’est à l’émetteur de notif d’indiquer la date de péremption (quitte à ce que l’utilisateur ajoute un délais max s’il le souhaite, mais l’enjeux n’est pas le même).

Pour l’émetteur de notif, par exemple : votre compte membre va bientôt manquer de certification, l’émetteur au moment où il envoi la certif sais quel est le délais pertinant (sans nouvelle certif, le compte perdra son status de membre à tel date) du coup à cette date, il sera inutile d’afficher à l’utilisateur qu’il va bientôt manquer de certification, il sera plus pertinent de lui dire qu’il n’est plus membre, faute de certification.

Et dès lors qu’on peut avoir toutes les notif émises, même celles périmé/obsolete, via une page d’archive de notifications, si quelqu’un est perdu, il pourra aller voir ce qui s’est passé là.

Mais globalement oui, ça me semble utile que l’info de péremption soit inclue dans l’UI.

Pour le fait que la spec force l’aspect péremption : quelles notifications restent pertinente si l’utilisateur en prend connaissance 2 ans plus tard ? je pense qu’il y en a, mais pas beaucoup. Si indiquer une péremption est facultatif, j’imagine que par flemme, la plupart des notifs seront sans péremption, et donc que les quelques notifs qui serait encore pertinente 2 ans plus tard seront noyés dans celle qui ne sont plus que du bruit. Du coup, rendre le champ obligatoire oblige à se poser la question de la durée de vie utile de la donnée, et ça me semble une bonne chose.

En outre, si le champ est facultatif, il me semble plus probable que certaines app l’ignore et donc que ce soit le boxon aussi de ce coté là.

1 Like
4

Pour certaines notifications (message des devs, expiration à venir) je vois l’intérêt de fixer une date d’expiration à l’émission.

Mais pour d’autres (réception d’une certif), il faudrait connaître les habitudes de l’utilisateur pour savoir si la notif doit rester 3 jours ou 3 mois, à moins de mettre 2 ans directement.

Si les notifications incluent des phénomènes onchain (transferts, TdC), alors il risque d’y avoir des différences entre les données affichées et les notifications. Si les temps d’expiration sont mal calculés, on pourrait aussi voir des notifs attirant l’attention sur des choses qui n’existent plus (par exemple, certif reçue avant une révocation, la notif de certif reçue peut expirer après la révocation, si sa date est fixée, le client doit gérer ça).

Aussi, sur la provenance des notifs, est-ce que :

  • l’indexeur génère les notifs
  • l’indexeur choisit et autorise des fournisseurs à lui envoyer des notifs
  • le datapod choisit et autorise des fournisseurs à enregistrer des notifs
  • le client choisit son service de notifs
5

Spontanément pour moi, Réception d’une certif :
priorité basse (notification sans confirmation manuelle), durée de vie 2 ans (jusqu’à péremption de la dite certif), écrasable par n’importe quel nouvelle notification de certif (si je reçois une autre certif, la notification non lu deviens “vous avez reçu 2 certifications, pour plus de détail, consultez vos archives”

Pour moi, c’est au système de gestion des notif de gérer ça plus qu’au client qui se contente de les afficher.

Pour moi, dans ce cas, la notif de révocation doit écraser (et donc remplacer) toute les notif de certification reçue)

Mon idéal serait :

  • l’utilisateur indique les instances de service de notification habilité à gérer ses notif (avec un réglage par défaut pour qu’il reçoive des notif sans rien configurer) et ces services reposent sur les datapod pour le stockage.
  • les notifs produites par ces services sont transmises aux indexeurs pour que les clients puissent simplement requêter les indexeur pour avoir ce dont ils ont besoins.