Sylvain Leroux Conformément au RIP00015 :
Proposition de complément :
Sylvain Leroux
Personnellement j'utilise les services de Google qui sont gratuits et efficaces : https://translate.google.fr/?hl=fr&sl=en&tl=fr&op=translate
I understand the argument in favor of transparency by using a private communication channel that remains publicly readable. However, when it comes to the security of the ecosystem’s tools, I’m not convinced it’s a good practice to publicly disclose information about the protection of this ecosystem, or its potential vulnerabilities.
That said, I’m fully supportive of post-incident communications, like detailed post-mortems or technical breakdowns, once the security team has neutralized a threat. Sharing insights at that stage could strengthen trust and awareness without compromising active defenses. How do you feel about that approach?
JoeD That said, I’m fully supportive of post-incident communications, like detailed post-mortems or technical breakdowns, once the security team has neutralized a threat. Sharing insights at that stage could strengthen trust and awareness without compromising active defenses. How do you feel about that approach?
Thanks for your comment, Joe.
I also support the idea of post-incident analysis and communication as you describe it.
The question is whether this falls within the scope of this proposal. While developing the RIP00015, "communication" was not a primary concern for the commentators. However, I still did include, as part of the incident response procedure in the RIP00015, a requirement for the Security Committee to "Submit a detailed report to the DAO for analysis."
That said, the technical requirements for committee members remain relatively low. In my opinion, this is insufficient for conducting deep forensic analysis. For this first term, the Security Committee members' primary responsibility will remain to push the big red "STOP" button when needed.
As time passes and we hopefully attract more qualified members and candidates, we could consider raising our requirements and expectations. However, for this first term, our primary concerns remain to attract candidates and encourage their involvement and responsiveness.
What do you think of that?
Sylvain Leroux They gain access to a private communication channel.
PhilP Pour le comité sur le calcul des pouvoir de vote, il a été créé un Telegram dédié (https://t.me/powervoting_realtoken_dao) pour lequel tout le monde peut lire les échanges, mais seuls les membres du comité peuvent écrire. Ce qui concours à la transparence des échanges, sans les perturber. Ce pourrait être la formule utilisé par ce comité...
JoeD I understand the argument in favor of transparency by using a private communication channel that remains publicly readable. However, when it comes to the security of the ecosystem’s tools, I’m not convinced it’s a good practice to publicly disclose information about the protection of this ecosystem, or its potential vulnerabilities.
I think the two cases are different:
Sylvain Leroux Security Committee's internal communication channel: Should it be private, or publicly readable?
I explicitly mentioned in the first post that this issue remains open.
PhilP ajouter l'item suivant : Suivant la performance des membres du comité aux "alerte de formation" et à leur montant déposé, la DAO (sa trésorerie) devra compléter le Safe de dépôt (d'un montant qui serait au maximum 30 % des dépôts, si tous les membres ont 100% de réussite aux alertes de formation)
J'étais en train de faire le changement, et puis ravisé en réalisant qu'on parlait ici des coûts de l'élection à proprement perler, pas des coûts liés à la constitution du Commité de Sécurité.
Cette mention aurait plus eu sa place directement dans la RIP00015, sans oublier que stricto sensu le coût total n'est pas capé par la formule. Cela avait été discuté à l'époque (lien sur le premier post, suivre les réponses pour la discussion complète).
PhilP Un Proposer clôturera la présente proposition en indiquant les candidats retenus et ceux rejetés (pour mémoire, la présente proposition ne donne pas lieu à vote sur Tally, ce sont les candidatures retenues qui seront votés sur Tally).
Done
PhilP Proposition de modification pour ce chapitre, afin permettre un dépôt sur un Safe dédié au dépôt et sur le Vault Incentive :
ajouter après "Ces REG sont déposés dans le coffre-fort du Comité de sécurité" : "(privé et dédié aux dépôts des REG et différent du Safe publique de gestion du Comité)",
remplacer le dernier paragraphe par : Le candidat qui utilisera des REG dans le Vault Incentive devra, à la fin de l'epoch d'incentive en cours, les transférer dans le Safe de dépôt du comité et ainsi atteindre le montant qu'il s'est engagé à déposé (et indiqué dans le formulaire Google form).
Fait, mais es-tu certain de ce passage: "(privé et dédié aux dépôts des REG et différent du Safe publique de gestion du Comité)"
Comme les candidats doivent faire des dépôts dans le Safe, son addresse ne sera pas tellement privée 
PhilP Proposition de modifications pour ce chapitre :
remplacer "ouvrir un sujet sur le forum" par "ouvrir une Suggestion sur le forum",
ajouter après "premier message" : "qui pourra être suivi d'une présentation dans sa langue native, dans un second message"
Reformulé pour plus de clarté
être moins strict que "DOIT être conforme au modèle suivant", en mettant plutôt ""devra comprendre au minimum les informations suivantes"
J'ai remplacé MUST par SHOULD (cf RFC 2119)
S'il quelqu'un oublie une info, on pourra toujours lui demander directement.
liste des informations :
Motivation et vision pour postuler au rôle de membre du Comité de sécurité,
Compétence / Expérience dans le domaine de la sécurité du Web3, dans l'usage de Safe Wallet, ..
Depuis quand êtes vous investisseur en Realtoken (vs compétence sur les applications de l'ecosystem : YAM,RMM,Bridge..qui pourront être stoppés par le comité),
Conflits d'intérêts liés à la candidature,
Fuseau horaire de disponibilité,
Adresse du wallet qui sera utilisé pour le Comité.
Noté
Pour "Adresse du wallet qui sera utilisé pour le Comité.", tu es certain que c'est nécessaire (déjà dans le formulaire Googl Form, non?)
Sylvain Leroux tout à fait:
Le Safe du comité de sécurité sera public, ses signataires seront connus
mais
les membres y participant peuvent déposer leurs REG dans le Safe coffre-fort à partir d'un autre wallet, pas forcément le même que celui avec lequel ils signeront les transactions de participation aux alertes.
Dans ta proposition on parle bien de wallets (possiblement distincts)
Wallet address dedicated to the security committee's activities (will be public)
Wallet address of the candidacy REGs deposit (will be private)
Wallet address holding the required Ledger Quest NFTs (will be private)
Wallet address holding RealTokens for KYC verification (will be private)
Oui tout à fait. Je ne sais pas où j'avais la tête. Merci pour cette clarification. 
Je proposait de rajouter cet item au chapitre "Conformément au RIP00015 :", ce qui signifie bien que ce sont des rappels de ce qui a été écrit dans cette RIP.
Je pensais pertinent de faire ce rappel, pour qu'on ne pense pas que le comité ne coutait rien à la DAO.. Après on peu en rester là.
Sylvain Leroux Pour "Adresse du wallet qui sera utilisé pour le Comité.", tu es certain que c'est nécessaire (déjà dans le formulaire Googl Form, non?)
Les informations dans le Google form , sont un échange privé entre le candidat et RealT.
Pour éviter à RealT d'avoir à publier les informations du google form, qualifiées de publique, autant demander au candidat de les redonner dans sa candidature publique. J'essaie de limiter au maximum la charge pour RealT.
Sylvain Leroux Comme les candidats doivent faire des dépôts dans le Safe, son addresse ne sera pas tellement privée
Pour mémoire, j'avais fais la proposition suivante afin d'essayer de préserver au maximum l'anonymat des membres : PhilP .
Dans cette proposition , le Safe de dépôt n'était pas publique, juste connu de RealT (qui le crée) et des membres (qui dépose). Ces dernier ayant intérêt, pour leur anonymat, à ne pas en divulguer son adresse.
Je suis d'accord, qu'avec le temps, cette information finira par être connue. Mais il y a un second niveau de protection avec la correspondance wallet de dépôt (privé) vs wallet de sécurité (publique) connue que de RealT.
Sylvain Leroux Remarque : Les candidats DOIVENT choisir de déposer directement leurs REG dans le coffre-fort du Comité de sécurité ou d'utiliser tout ou partie de leur dépôt dans le Coffre-fort d'incitation comme dépôt de garantie.
Afin de simplifier le processus de validation, les candidats NE DOIVENT PAS combiner les deux méthodes de dépôt.
J'avais proposé que cette partie soit remplacée, donc retirée. Le candidat pourra utiliser les deux options en même temps, pour peu qu'il transfert à la fin de l'epoch ce qui manquerait dans le safe de dépôt.
Sylvain Leroux Done
Il me semble pas que cet ajout soit fait ?
Je remets une pièce dans la machine, mais quel est l'intérêt de rendre publique l'adresse de wallet servant aux activités du comité de sécurité ?
Est-ce que cela n'est pas une perche tendue à quiconque souhaiterait faire un lien entre un pseudo et une adresse de wallet ?
C'est la solution qui a été utilisée, pour le rôle de Proposer.
Un compromis entre :
Le candidat pourra créer un wallet, dédié son action au sein du comité, préservant ainsi son anonymat (sauf pour le tier de confiance qu'est RealT).
PhilP rajouter cet item au chapitre "Conformément au RIP00015 :", ce qui signifie bien que ce sont des rappels de ce qui a été écrit dans cette RIP.
Je pensais pertinent de faire ce rappel, pour qu'on ne pense pas que le comité ne coutait rien à la DAO.. Après on peu en rester là.
On peut couper la poire en deux en formulant pour préciser qu'il s'agit bien des coûts directement entraînés par les processus de vote, et renvoyer à la RIP00015 pour les autres frais.
Si je trouve une formulation adéquate, je fais ça.
[X] Précisions sur les coûts pour la DAO (v4.6-alpha)PhilP J'essaie de limiter au maximum la charge pour RealT.
Cela va sans dire. J'essaye d'être dans cet optique également.