Amethyst 1.16 ajoute les paiements BOLT12 et un tableau de fitness

BOLT12 entre dans le parcours de paiement habituel

La modification des paiements fusionnée affiche dans la barre de paiement du profil les offres BOLT12 publiées dans des événements kind 10058. Un destinataire qui publie une offre peut aussi devenir payable dans le sélecteur de zaps lorsque le portefeuille Nostr Wallet Connect par défaut de l'expéditeur annonce la capacité pay.

L'interface conserve une seule action Lightning au lieu de demander à l'expéditeur de choisir d'abord un protocole. Amethyst choisit le chemin au moment de l'envoi. Si le portefeuille refuse une offre BOLT12 et que le destinataire possède aussi une adresse Lightning, le client peut essayer le parcours zap BOLT11 ordinaire.

Ce repli est volontairement limité. Amethyst ne réessaie que les erreurs indiquant une instruction inutilisable, dont EXPIRED, NOT_FOUND, BAD_REQUEST, NOT_IMPLEMENTED, UNSUPPORTED_PAYMENT_INSTRUCTION et UNSUPPORTED_NETWORK. Il ne réessaie pas après un délai dépassé, PAYMENT_FAILED, une erreur inconnue ou un paiement sans reçu. Ces situations peuvent être ambiguës, et une seconde tentative automatique risquerait donc de payer deux fois.

Les tests de la pull request couvrent les règles de nouvelle tentative, mais son auteur a indiqué que le parcours complet du refus au repli BOLT11 n'avait pas été testé de bout en bout avec un vrai portefeuille NWC. La disponibilité de la version ne prouve donc pas que toutes les combinaisons de portefeuilles et d'offres se comportent de la même manière.

My Fitness garde le tableau sur l'appareil

Le nouveau tableau My Fitness résume les entraînements récents de l'utilisateur. Il compare la semaine actuelle à la précédente, calcule une moyenne sur quatre semaines, regroupe le temps par activité et affiche les meilleurs efforts, les jours actifs et une série de jours consécutifs.

Le tableau combine les données d'Android Health Connect avec les événements d'entraînement kind 1301 de l'utilisateur. Il élimine les doublons probables selon le type d'activité et l'heure de début, en préférant l'enregistrement Health Connect lorsque les deux sources décrivent la même séance. Les calculs se font sur l'appareil et la publication d'un entraînement reste une action facultative pour chaque séance.

La modification fusionnée comporte une limite importante. L'écran My Fitness n'envoie pas sa propre requête aux relais pour les événements 1301. Après un démarrage à froid, il peut n'afficher que les entraînements déjà chargés par un autre écran, et l'historique publié peut sembler incomplet jusqu'à ce que le client récupère ces événements ailleurs. Le tableau dépend aussi de Health Connect, propre à Android, comme source locale de données de santé.

Une frontière plus légère pour le code partagé

La version 1.16 comprend aussi une séparation entre le code partagé sans interface et la couche Compose. Selon le projet, cela retire environ 40 Mo de dépendances Compose et Skiko des distributions en ligne de commande. Le même changement annonce 34 corrections de fonctionnement et de performances dans les relais, les caches, l'analyse de texte, le stockage chiffré et les flux.

Pour les utilisateurs, le changement visible dépasse une seule fonction. Les paiements trouvent les offres BOLT12 à davantage d'endroits, les données d'activité obtiennent un tableau privé avant toute publication facultative et le noyau partagé porte moins de dépendances d'interface. Les limites documentées restent importantes : l'interopérabilité des portefeuilles demande une confirmation réelle, les boutiques peuvent être en retard sur GitHub et My Fitness peut omettre des entraînements issus des relais après un démarrage à froid.