Current Code of Conduct Considered Harmful

[ariard]

At the very least a reasonable code of conduct should consider to have transparent and accountable process for the nomination of the moderation team (e.g recycle every 2 years) and an amendment process in case of concrete issues raising questions on the limitations of the current code.

Lack of this last point of an amendment process might put in catch 22 situation where a moderation team member is in a situation of conflict of interests, yet is blocking all amendment process.

As a reasonable code of conduct have to talk about the delicate question of the separation between professional matters and personal matters, and the handling of conflict of interests (of which past drama in the Rust community gaves a lot of examples), the discussion of the boundaries of the code of conduct might be better appropriate on a slow-paced, high-bandwidth and yet open communication channel.

[netlify[bot]]

✅ Deploy Preview for lightningdevkit ready!

Name	Link
🔨 Latest commit	abfb53fdd84bc0e9ff0a287514b9ed76df394013
🔍 Latest deploy log	https://app.netlify.com/sites/lightningdevkit/deploys/647d2e00ac71ac000785122e
😎 Deploy Preview	https://deploy-preview-210--lightningdevkit.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[TheBlueMatt]

I don't really see a reason for this? If someone can't be trusted to not take actions which harass others or otherwise distract developers from being able to focus on development they probably shouldn't be involved in handling security issues either - there being able to focus and avoid distractions is even more important.

[ariard]

If someone can't be trusted to not take actions which harass others or otherwise distract developers from being able to focus on development they probably shouldn't be involved in handling security issues either - there being able to focus and avoid distractions is even more important.

Of course developers trusted with handling security issues should bind to a proper behavior, or even the appearance of such behavior. Especially to avoid situation of moral hazard during handling of security issues.

The rational of this change is to protect the LDK security incident response from trolls and other type of social attacks. A malicious party can send forged claims to the Code of Conduct team accusing one or more member of the security team of improper behaviors and requesting them to take immediate corrections actions. If fooled and the Code of Conduct team lead to investigate on a security team member asking explanations under the 1 week target of resolution as proposed by current documentation. They might provoke a distraction during the handling of a security issue, which might reveal fatal for the LDK users funds security.

The two LDK teams (Code of Conduct and security) might not have the leisure to take time to coordinate on what is really happening as if the security issue is shared between other Lightning implementations or with Bitcoin Core or coming from an external disclosing party, they might have to take actions on timeframes driven beyond the consensus between LDK developers. The technical nature of the security flaw (e.g touching propagation of time-sensitive transactions) might add an additional constraint.

This type of advanced “Code of Conduct forgery” attack is not to exclude both for technical reasons, every day it comes easier to do “deep fake” with common man AI tooling (e.g GPT). And for social reasons, North Korean-backed hacking groups are already targeting smart contracts in the cryptocurrencies spaces. So this is realistic that LDK security might be targeted too by nation-state level adversaries in the future. This concern of psyops has been brought up during an open session at last CoreDev and a reason why not to have a Code of Conduct there, and I’m not the one who stated the concern (Chatham House rules applied).

For those reasons, it sounds very rational to me to harden LDK social process with such a change, firewalling security incident response from human incident response in everyone's minds.

[ariard]

As raised before, I think we should design our LDK community documents adopting an adversarial mindset, as social attacks by nation-state actors against cryptocurrencies devs is a real thing (cf. bleepingcomputer article on North-Korea sponsored fake job offer).

All that said, such conversation is better pursued on appropriate communication channels with the feedback of every active contributor in the community to ensure updated code of conduct reflects the aspirations and concerns of all.

There is one reasonable argument that updates to the code of conduct should be formalized themselves and at specified time interval to ensure the rules laid out in the document have a minimum of stability.

I’ll let open the issue until we have a formalized process to propose updates to the code of conduct. I still think the way the code of conduct has been introduced by the Spiral team as a “close deal” with #184 without previous community consultations or accepting grounded modifications is questionable in light of open-source projects history and practice.

[TheBlueMatt]

Closing due to lack of interest from reviewers, as mentioned at https://github.com/lightningdevkit/lightningdevkit.org/pull/209#issuecomment-1565942902 We can revisit if there's a concrete issue as an example that indicates more need for this.

[ariard]

Updated at c3ab1edbff with 2 basic procedural todos:

• a) accountable and transparent nomination process of the moderation team (e.g 2 or 3 years)
• b) basic formalization of the code amendment process (other we’ll hit a deadlock in case of concrete issue showing the limits of the code)

Thanks to re-open the issue and let it opened until my concerns are addressed, even if it takes years to build consensus on those 2 topics. And yet there is a deliberate wish to have it opened for everyone visibility.

I’ll observe you're both administrator of the communication space (i.e Github) and “party at case” as I’m questioning the behavior of your current employer in the issue. This is manifest situation of conflict of interest, and ethical practice would ask for you to not leverage your administration rights to close the discussion. After all I don’t think we have clear GH opening/closing criterias on when a sensitive issue lacks interest after a “given” time. In case of lack of understanding on this issue, I’ll raise the concern on the mailing list or reddit or stacker.news, calling out the clear abuse of your janitorial role in the current discussion.

Abstraction is made and in silence of any personal matters that have raised a lot of confusion in our minds in the current discussion. This just a question of good neutrality and transparency standards for an open-source project like Python, Linux or Tor are following. Our different of views in term of open-source culture in case of conflict have already raised before the introduction of a code of conduct for LDK (cf. Taproot bip editors janitorial role).

I fully understand Spiral has invested between $4-8M of engineering resources in the project during the last years and as such Spiral is protective of the project, however do Spiral claims the project coordination tools and its communication channels constitute a "private property” of Spiral ? I don’t think so and I believe I’ve invested as much technical “proof-of-work” on a personal title.

For external observers, I think the very same Spiral team used my personal open-source reputation in the past to promote the project (cf. podcast transcript of an interview of their current team lead), so from my view there is a qualified corporate hypocrisy in using someone name to build the project reputation and dismiss that person at the first different in term of formalizing project culture.

I’m perfectly sharing the concern to maintain a convivial and convenient communication space to center the discussion on technical aspects and shipping code. However in case of disproportionate moderation measures and encroachment on my professional interests, I’ll challenge the code team decision in competent courts for infringement of my freedom of expression, where an adequate due process is followed.

By the same communication, I invite the Spiral team to adopt better transparency standards next time they propose and enforce an unilateral change in years-long communication rules unless they’ve opted to make the development of the LDK project a closed one and no more a neutral and decentralized open-source project. I would be very happy we avoid to fight years from now on the domain names and communication space administration rights of the LDK project in front of the World Intellectual Property Organization Arbitration and Mediation Center :)

Anyway, I’ve made my griefs clear and I won’t comment further on this issue without more other reviewers interest, assuming it’s re-opened (otherwise I’ll do a post calling out Spiral hypocrisy on a more open communication platform).

[ariard]

I rather opened a new PR, this is the set of changes I’m judging adequate to satisfy my concerns at that time.