Reprise du message précédent :
Oui, ça dépend le point de vue. Si MPS2 est un pré-requis ou un but final
Moi je vois bien essayer de proposer une UX commune aux 3 plateformes, avec des specs puis une implémentation en best effort

Le but c'est aussi de partager la donnée qu'on met sur MPS2, enfin pour ce qui est utile comme partager la liste des images uploadés et leurs hash de suppresion

Pour la prochaine étape de l'app RF2 j'aurai besoin d'avoir bien avancé sur MPStorage2, donc dans les prochains jours je vous soumettrai des idées/docs.
Dans tous les cas j'avancerai vite et on pourra se synchro plus tard, RF2 est encore en alpha, pas de soucis pour péter et réadapter le schéma/méthodo.
 
J'ai aussi en tête un tableau avec les 3 supports, lister les fonctionnalités qu'on veut en plus de celles de base du forum.
 
Je vais essayer de faire un truc digeste

Ok xatelite  

héhé
 
XaT de Shrodinger sinon

bon en fait je crois que jvais dabord foutre mpstorage1 et on verra plus tard
comme ça avec la support MP1 on pourra faire la transition vers MP2 avec reprise de la data

Ça me va    
 
Au passage, tu peux pas trouver un nom plus parlant pour ce topic ? pq un topic HFR sur HFR...  

hfr8k

Vazy propose

**Topic pour s'entendre et synchroniser les fonctionnalités, stockage données (mpstorage) entre web et app** ?

ok vazy renomme

t'as quoi toi comme favoris enplus ? Super Favoris ?
 
Je pense à avoir ces drapeaux en fonction du type sujet :
Mes sujets -> Cyan + étoile Jaune
Favoris -> étoile jaune
Lu -> drapal roug
poru ceux de base
puis  
MP -> drapal .. ?
MultiMP -> drapal .. ?
DT -> drapa .. ?
Super Favoris -> .. ?
 
Je pensais à Fushia pour les DT oui la couleur de merde comme à l'époque

si c'était moi j'en garderai 2: les favoris et les super favoris : ceux que tu suis de loin et ceux que tu suis tu pres. Le reste ça sert à rien
donc sur une vue des favoris, juste du doré pour les favoris (ou à peu près doré   )
et le reste est visible par tri: les MP, les lus...
je trouve qu'après on s'y perd rapidement, avec des couleurs qui en plus n'ont aucun sens sémantique
au final on fait des UI hyper compliquées pour calquer le forum alors qu'au final 99.9% du temps on fait du refresh en boucle sur 3 topics

mais bon ca râle déjà assez de mon côté

On a les users qu'on mérite
T'as sûrement raison mais je vais quand même continuer la réflexion

Je déplace des repo github sur l'orga forumhfr : https://github.com/ForumHFR/
notamment le mcp et le mcp github action
 
https://github.com/ForumHFR/hfr-mcp
https://github.com/ForumHFR/hfr-mcp-action
 
sinon redface2 commence à être conséquent

 
tiens faudrait que je teste ton mcp pour qu'il suive les feedbacks utilisateurs et qu'il les synchronise avec mon backlog

Oui c'est ce que je fais. J'ai du update le mcp. Là j'ai l'impression qu'il sort un vieux cache mais c'est sûrement côté Claude code
J'ai foutu les notifs mails. Une adresse en agentmail.to et basta enfin un cron pour qu'il check les mails quand même

J'avoue le @Claude c'est cool

tiens j'ai trouvé comme extraire la liste modo/admin/..
https://forum.hardware.fr/message-s [...] ponsable=1
mais pas d'association du modal avec sa section

On a commencé par auditer l'ancienne app et lire la doc de RF2. On a tout consigné dans une référence protocole où chaque fait est sourcé, avec un statut : lu dans le code, observé en live, rapporté par RF2, ou vérifié par une capture.
→ HFR-PROTOCOL.md (licence CC BY 4.0, réutilisable par tout le monde, RF2 compris)
Le tableau des fonctionnalités sur les 3 supports : cross-platform-features.md
 
Nos réponses aux questions du topic :
 
1. Remplacer MPStorage par une API REST sur un serveur tiers ?
On est d'accord avec XaTriX : on reste sur HFR. L'auth HFR est le seul vrai point fort de MPStorage, et un serveur tiers pose les questions d'authentification et de pérennité. Un OAuth côté forum, on n'y croit pas non plus.
 
2. MPStorage v1 puis v2
On sera compatibles v1 dès le départ : lecture et écriture, sans jamais écraser les namespaces des autres clients. Pour la v2, on est partants pour participer au design, surtout sur l'accès concurrent. Détails dans un message à part juste après.
 
3. L'API REST
On l'utilisera pour la navigation (catégories, listes de topics, drapeaux), avec le HTML en secours. Ça correspond à ce qui a été décrit ici : pas de MP, pas de contenu de post, et réécriture des liens /api/.
 
4. Drapeaux et favoris
On rejoint ezzz : par défaut, favoris + super favoris, le reste accessible par tri. Les couleurs par type pourraient être une option. Les retours du topic iOS vont dans ce sens : la plupart des gens rafraîchissent en boucle quelques topics.
 
5. Quote inline / tableaux façon Markdown
Bonne idée pour l'affichage, mais attention : c'est du rendu côté client uniquement. Pour ceux qui lisent sur le site, ça reste du texte brut. Il faudrait définir une syntaxe commune pour que les 3 clients l'affichent pareil.
 
6. Traduction des liens HFR (« topic X page N ») et egoquote
Oui pour les deux, c'est prévu.
 
7. Cache des avatars
Oui, prévu (cache local avec durée de vie).
 
8. Liste des smileys
roger21, si tu es d'accord, on aimerait s'appuyer sur ta liste et tes stats pour le catalogue de smileys de l'app, avec crédit bien sûr. Tu préfères quelle licence ou quelles conditions ?
 
9. Tableau commun des fonctionnalités
On en a fait une première version (lien plus haut), basée sur notre audit de l'app iOS, la doc RF2 et les retours du topic iOS. Elle est faite pour être complétée et corrigée, en particulier la colonne web/userscripts que l'on connaît mal.
 
Dernière chose : on a trouvé quelques incohérences dans la doc RF2 (remontées en issue sur GitHub), et ce qu'on a appris est déjà dans notre doc protocole. L'idée, c'est d'arriver à une seule base de connaissance HFR partagée, comme proposé au tout début du topic.

MPStorage v2 : quelques propositions, surtout sur l'accès concurrent
 
Côté iOS, on a audité l'implémentation MPStorage de l'ancienne app et lu ce que fait RF2. Le constat est le même partout : la v1 fait du « lis, modifie, réécris tout », sans aucune protection. Deux clients qui écrivent en même temps, et le dernier efface le travail du premier. Avec plusieurs scripts web et plusieurs apps sur le même document, ça arrive forcément.
 
Quelques propositions pour la v2, à discuter :
 
1. Découper par type de données
Comme proposé plus haut par ezzz : un post (ou un MP) par type de données (blacklist, bookmarks, positions de lecture, images uploadées…). Un client qui modifie ses bookmarks ne réécrit plus la blacklist. Ça réduit énormément les conflits et ça repousse la limite de taille.
 
2. Un numéro de révision par bloc
Chaque bloc porte une révision (un compteur) et la date de dernière écriture. Avant d'écrire, on relit le bloc. Si la révision a changé depuis notre lecture, on refait la fusion au lieu d'écraser. Après l'écriture, on relit pour vérifier (RF2 le fait déjà).
 
3. Règles de fusion simples et communes
Les listes (blacklist, bookmarks, images) sont fusionnées élément par élément, avec un identifiant et une date par élément. Les suppressions sont gardées comme « pierres tombales » datées, sinon un élément supprimé revient au prochain merge.
 
4. Ne jamais toucher à ce qu'on ne connaît pas
Un client conserve tel quel tout bloc ou tout champ qu'il ne comprend pas. C'est déjà la règle de fait en v1 (namespaces DTCloud, multimp…), à écrire noir sur blanc.
 
5. Garde-fous
- Une taille max par bloc.
- Refuser d'écrire tout caractère hors BMP : HFR tronque silencieusement au premier emoji, ce qui casserait le JSON.
- Un champ de version, et une migration v1 → v2 qui lit l'ancien document et ne le supprime qu'une fois la v2 vérifiée.
 
6. Données à partager en priorité
- La liste des images uploadées avec leurs hashs de suppression : c'est une plainte récurrente sur le topic iOS (« impossible de supprimer mes images »).
- Les bookmarks.
- Le suivi de lecture MultiMP.
- La blacklist.
 
Si ça vous va, on peut écrire cette spec ensemble, dans un repo commun ou dans la doc RF2.  
De mon côté, on implémente la compatibilité v1 tout de suite et on suivra la v2.

J'ai quelques questions:  

• @n0b0dy quand tu dis "on": tu n'es pas seul ?

Pour la version iOS:  

• On repart de zero?
• On travaillerai dans ton repo ou celui de Ezzz?

 
On a aussi une limitation sur la pagination: Dans les listes de sujets d’un forum, HFR n’indique jamais le nombre total de pages. Il affiche seulement des liens vers les pages proches, puis des sauts de 10 et de 100, qui s’arrêtent avant la fin. Par exemple, la page 1 de Hardware propose un lien jusqu’à la page 500, et la page 500 jusqu’à la page 700. Un client qui prend le dernier lien pour le total affiche donc un chiffre faux, et son bouton « Dernière page » ne mène pas à la vraie dernière page.

Jamais    
 
 

 
On continu la discussion avec ezzz en privé
   
 

 
Bon use case à garder pour les specs transverses. Android ou IOS si HFR ne présente pas les infos, trouver un workaround aidera des deux côtés.

Regardez ce que l'API REST propose pour la liste des topics dans les catégories, sinon.
Bon après je pense que je vais l'abandonner pour le listing des drapeaux, je sais pas encore mais elle pue un peu parce qu'elle oubli genre les topics pinnés dans les catégories. C'est bugué quoi.

Ya un truc qui me ferai vraiment plaisir, c’est des notifs, mais sans credentials sur un server c’est dead…

Notifs ? L'app sur le phone ça suffit pas ?

Je préférais avoir des notifs de réponses à mes sujets ou aux MP plutôt que recevoir des mails

Vous n'avez pas de notifications sur l'app iOS ?

Bah non, à moins d’avoir loupé un truc?

Je ne sais pas j'ai jamais eu iOS mais sur RedFace il y a les notifications en cas de MP.
Pour RF2 pas encore ajouté mais c'est prévu et notamment en cas de réponse à certains sujets en plus des MP.

Les notifs sur iOS sont à base de scheduler background et avec Apple ca reste à la merci du bon vouloir de l'OS de pouvoir exécuter ta tache de fond, y a rien de garantie surtout si tu as des trucs qui consomment à coté

J'ai pas encore étudié comment ça se passe côté Android mais je suis surpris que tu puisses pas faire un push respecté sur iOS ?