「相互ミュート」のやり方は？

開発
1

編集：私は賢いと思っていたが、そうではなかった。次のメッセージをご覧ください。

こんにちは、私が気づいたことを共有したかっただけなんです… 私は既存の会員サイト上で Discourse をフォーラムとして使用しており、既存のサイトでは会員同士が互いをブロックできます。ユーザー A がユーザー B をブロックすると、ユーザー A とユーザー B の両方が互いを見ることができず、相互作用もできなくなります。

Discourse にも同じ機能を適用する必要がありました。これをどう実現するか頭を悩ませていましたが、ようやく解決策を見つけました：

  1. Discourse の webhook を設定してイベントを受信し、user_logged_in イベントをキャプチャできるようにしました。

  2. ユーザーがログインすると、既存のサイト上の「ブロック」リストを走査します。

  3. ブロックしようとしている他のメンバーごとに、Discourse API（これは SSO とは全く関係ありません）を使用して、そのユーザーを「無視」設定にします。

  4. そしてここが巧妙な部分です：Discourse に、もう一方のユーザーにもログインしているメインユーザーを無視させるように指示します。つまり、ログイン中のユーザー A と、ユーザー A のブロックリストにあるユーザー B の両方が互いを「無視」する状態になります。

  5. 「無視」メッセージを送信する際、その機能が TL2 以上でしか利用できないため、対象ユーザーが少なくとも TL2 であることを確認する必要があります。TL2 未満の場合は、「無視」を完了する前に素早く TL2 に昇格させる必要があります。ユーザーを TL2 に昇格させると、discobot の高度なスクリプトが起動したり、バッジが付与されたりといった他の副作用が発生するため、それらに対処する必要がありました。

あ、それから、メインサイトにはブロックされたユーザーを管理するインターフェースがあるため、Discourse のユーザープロフィールにある「無視」リストは単純な CSS で非表示にしています。Discourse のメンバーに Discourse の無視リストを全く見せたくないからです。

この情報が、同様の機能が必要な他の皆様の参考になれば幸いです…

「いいね！」 2
2

さて、問題点をお伝えします。Discourse の「無視」機能は、他のユーザーを完全に隠すわけではありません。メッセージを非表示にする機能は（実際、非常にうまくやっています）が、代わりに「x 件の非表示メッセージを表示」というリンクが表示されます。これは CSS で簡単に隠せるので、大した問題ではありません。

しかし！ブロックされたユーザーが引用された場合、引用そのものは表示されませんが、メッセージにそのユーザーのアバターと名前、そしてメッセージ返信インジケーターにもアバターと名前が表示されてしまいます。困りましたね。

つまり、私のサイト上でユーザー A がユーザー B をブロックし、私が前回の投稿で説明した「双方向無視」トリック（お互いに無視する）を適用すると、ユーザー B（自分自身はユーザー A をブロックしていない）は、ユーザー A がフォーラムに投稿する際に奇妙な表示を目にすることになります。そして、ユーザー A にブロックされたことに気づいてしまいます。これにより、ユーザー A が誰をブロックしているかという個人情報がユーザー B に漏れてしまうことになります。私のサイトでは、これは絶対に好ましくありません。

うーん

というわけで、ついに Rails (RoR) を学ぶ必要があるかもしれません :wink: 。既存の「無視」機能を拡張するプラグインを作成し、「無視」リストにあるユーザーの痕跡を本当に完全に消去できるようにする必要があります。そうすれば、私の「二重ブロック」案に戻ることができます…

「いいね！」 1
3

その通りです。Discourse の「無視」機能は、完全な「ブロック」機能ではありません（そのため「ブロック」とは呼んでいません）。コミュニティガイドラインに違反しているわけではないが、少し厄介な相手がいる場合などに適しています。

完全なブロック機能の要望は以前から出ていましたが、私たちは一般的に以下のように考えています。

「いいね！」 8
5

クリスさん、返信ありがとうございます。

さて、警告します。ここからは少し防御的な愚痴めいた話になりますが、これはクリスさんというより、私に「ブロックは必要ない」と言い続けてきた人々全体に向けたものです（笑）。

私は長年、コミュニティ運営の現場で働いてきました（AOL、CompuServe、GEnie でメッセージボードやチャットルームのコミュニティ運営をしていた時代も含めて）。現在では、自分自身のコミュニティサイトを運営しています。フォーラムはサイトの一部であり、サイトのコミュニティの多く（すべてではありませんが）がそこで交流しています。

ブロックが望ましくない理由については、完全に理解しています。本当に理解しています。Meta.Discourse で見つけられる限りすべてのメッセージを読み、無視機能の必要性を訴える人々や、それがなぜ望ましくないのかについて行われた議論、そして最終的に皆さんが折れてソフトウェアに無視機能を追加した瞬間も見てきました（笑）。

その中で、一部の人が見落としているのは、すべてのサイトが「Discourse のみ」または「フォーラムベースのコミュニティのみ」で運営されているわけではないということです。

私の現在の状況では、Discourse が登場する前から、すでに当サイトに強力なコミュニティが存在していました。以前のフォーラム（使い物にならない古いソフトウェアを使用していたもの）だけでなく、サイトのチャットルーム機能（常連客がおり、フォーラムのコミュニティと重なり合う独自のコミュニティが存在）や、他のコミュニティ中心の機能も含まれます。

良いか悪いかは別として、私のサイトはこれまで常に、他のメンバーを「完全にブロック」する機能を提供してきました。これは部分的にはコミュニティ上の問題によるものですが、主に私が支えるコミュニティが、法的な懸念などを含むいくつかの理由から、プライバシーに対して非常に敏感であることを期待しているためです（真剣に）。

「ブロックは良いアイデアか？」という問いは、私にとって今の時点で問うべき正しい問いではありません。個人的にはブロックのアイデアを好んでいませんが、その船はすでに出港してしまいました（笑）。

（もう少し背景を説明します。私の古いフォーラムは、サイトの前所有者の判断によりかなり有害な状態でした。双方向ブロックを求めた人々の一部は、フォーラムで起きたようなことが理由でした。Discourse への移行と全く新しいフォーラムの導入に伴い、私は損傷したフォーラムコミュニティの修復にも取り組んでいます。）

繰り返しになりますが、非常に明確に申し上げます。ブロックが一般的に健全なコミュニティの兆候ではないことは、完全に理解しています。実際、以前はブロックに頼りがちだったメンバーに対して、少し落ち着くよう働きかけているところです。

さて。

もし私が全く新しいコミュニティを立ち上げるのであれば、間違いなく Discourse から始め、双方向ブロックは必要ないでしょう。

もし、すでに双方向ブロックが利用可能なサイトを持っていなかった場合（あるいは、以前双方向ブロックをサポートしていたフォーラムソフトウェアからの移行でなかった場合）、Discourse において双方向ブロックは必要ありません。

もし、現在のフォーラムコミュニティがすでに損傷していなければ、双方向ブロックは必要なかったでしょう。しかし、彼らは過去にひどい経験をしており、ブロック機能の導入が求められました。私はそれを実装せざるを得ませんでした。現在、Discourse への移行はコミュニティに大きな変化をもたらしており（私が持っていたものとは大きく異なるため、プロセスが必要です）、そのタイミングで「ところで、ブロック機能は廃止します」と言うのは適切ではありません。そうすれば、反乱が起きるでしょう。

ともあれ。返信が長くなりすぎたことをお詫びします。私が防御的になりすぎているようであれば申し訳ありません（笑）。単に、ブロックが「健全ではないこと」についての哲学的な議論に巻き込まれたくないだけなのです。

私は依然として、完全なブロック機能を必要としています。

すべてのフィードバックとサポートに心から感謝しています！私がこれほど長く書き綴った理由の一つは、Discourse コミュニティに貢献したいという思いからです。

最後に申し上げます：Discourse は現在、私が求めているものを完全に提供しているわけではありません。しかし、かなり近いです！Discourse チームにソフトウェアへの追加を説得しようとしているのではありません（その議論は私が参画するずっと前から始まり、終わっていたため）… しかし、私は手元にあるピースを使って目標を達成しようとしています… ここで見かける賢く、創造的な思考者やコーダーから助けを求め、その過程で発見したことを他の人々と共有したいと考えています。

「いいね！」 5
6

多くの点に同意しますが、この点についてコメントさせてください…

小規模から中規模のフォーラムでは、自動ブロック機能がないことも許容されますが、大規模プラットフォームにとっては必須だと個人的には考えます。

その主な理由は、メンバー数が増えれば投稿数も増え、それによって対人関係上の問題がより多く発生する可能性があるからです。10 人のモデレーターチームであれば、1 万〜3 万人規模のフォーラムを適切に運営できますが、メンバー数が増えると、それ以外の要素はさらに急激に増加します。より多くの声 → より多くの投稿 → より多くの問題。

このことが、すべての大規模ソーシャルネットワークプラットフォームがブロック機能を提供している大きな理由の一つです。もう一つの理由は法的観点からです。あるユーザーが別のメンバーからいじめられていると報告し、サイト側が何の対応も取らなかった場合（例えば「いじめは発生していない、それはその人の思い込みだ」と判断した場合）、そのユーザーが自殺した場合、サイト側に責任が問われる可能性があります。誰かが本当にいじめられていると感じているなら、それがその人の実感です。あなたや私の考えは関係ありません。重要なのは、私たちはメンバーに対するケアの義務を負っており、その不安感を和らげる最善の方法の一つは、その相互作用を断つことです。それは、苦痛を与えている相手をユーザー自身がブロックできるようにすること（あるいは場合によっては、運営側がそれを強制的に適用すること）によって最も効果的に実現できます。

裁判官兼陪審員として振る舞う時代はすでに過ぎ去りましたし、私たちがそのような立場になる必要もありません。何が他者を苦痛に陥れているかを判断するのは私たちの役目ではないのです。

これが、より現代的なモデレーションツールが必要だと私が考えるもう一つの理由です。モデレーターは、受け入れられない投稿を編集する（多くの場合、検閲と見なされます）立場に追い込まれるべきではありません。そのような投稿は表示から削除し、投稿者に編集を依頼し、編集内容をレビューキューに回すだけで十分です。

Discourse がこの分野で先導してくれることを願っています！

「いいね！」 2
7

非常に的確なご意見です。（これは必ずしも仮定の話ではありません：私のコミュニティでは、過去に法執行機関の関与を余儀なくされた事例があります。）このような状況を考え、メンバーに自己管理のためのツールを提供することは極めて重要です。そして、良質なコミュニティサイトを運営する誰にとっても同様に重要であると私は主張します。

同意します。そのようなオプションがあれば、非常に役立つでしょう。一般的に、私のフォーラムでは、まさにこの理由から、他の人の投稿を編集することはありません。メンバーは、私たちの手によって言葉が改変されることに非常に敏感になるでしょう。現在、Discourse で問題のあるコンテンツに対処できる選択肢は、(a) メッセージを削除するか、(b) メッセージを削除しないかの二つだけです。これは少し乱暴で、「手に持っているのがハンマーだけだと、すべてが釘に見える」という状況です。:hammer: :grin:（また、将来のモデレーションツールに関するこの議論は、別のトピックで話すのが適切だと理解しています。）

「いいね！」 2
8

素晴らしいアイデアですね。投稿者に責任を戻すという点が好きです。

「いいね！」 2
9

私たちは今、そのように促されています。しかし、投稿を編集するか削除するか（他の多くの理由から理想的ではありません）を迫られる理由は、投稿が他のメンバーに対して軽蔑的であったり、私たちが望むほど友好的でなかったりする場合は、他のメンバーがそれを見る前に削除する方がよいからです。一度他のメンバーがそれを見てしまうと、対人トラブルの発生を防ぐための機会が失われ、悪循環の始まりとなります。これは、時間とともに、関係する二人のメンバーだけでなく、はるかに多くの人々に影響を及ぼします。

……そして、モデレーターチームへの負担も大幅に軽減されます :smiley:

「いいね！」 2
10

投稿を「不適切」としてフラグを立てる代わりに、「アクションを実行」ボタンを使ってください。投稿は非表示になり、ユーザーは投稿をより受け入れられるように編集する機会が与えられます。その後、投稿は自動的に再表示されます。

ここで唯一不足しているのは、編集に対するレビュー項目をポップアップすることです。

「いいね！」 5
11

はい、フラグシステムがこの場合に非常に役立つと思います。上記に加え、ユーザーへ送信できる「推奨される変更」や何らかのメッセージを含めるのも理想的です（フラグがモデレーターから送信された場合、またはレビューキューで対応が行われた場合は、これを必須にするのも一案です）。

12

[quote=“AstonJ, post:6, topic:148133”]
これは Discourse が主導できると思います（願わくば！）。[/quote]
いいえ、それは実現しません。「ハードコアなブロック機能（これはそもそも歴史的にフォーラムソフトウェアの機能だったことが一度もない）」が絶対条件であれば、他の無料オープンソースソフトウェアへ移行すべきです。申し訳ありません！

とはいえ、現時点では API をベースにした相互無視機能は、良い回避策だと思います。

*「ブロック」とは、「私がその人の投稿を見たくなくなった」だけでなく、「その人が私の投稿を見られなくなる」という追加機能のことです。

「いいね！」 4
14

私の「相互無視」トリックの面白い副作用として、今ではこれらのメールが大量に届くようになりました。数十通もです。これらを抑制する方法はありますか？それらが消えてしまうのは残念です（潜在的なコミュニティの問題を察知するのに非常に役立つと思います）が、ブロックを機能させるために「無視」機能を流用しているため、これらの通知は意図しない副作用となっています。

image
image964×1774 111 KB

15

サイト設定を確認して、編集可能なしきい値があるか確認しましたか？それが私が最初に行うことです。

16

一部は読みましたが、少し難しすぎます。

サイトの管理者が、ユーザーAがユーザーBを無視した場合、ユーザーBも無視され、ユーザーAの投稿にアクセスできなくなるように設定することは可能でしょうか？

ご協力ありがとうございます。この情報を管理者に伝えるために調査しています。

ラリー！

17

いいえ、Discourse で誰かを完全にブロックすることはできません。通常のユーザーが取れる最も極端な措置は「無視」です（無視された人はあなたのコンテンツを見ることができますが、あなたは彼らのコンテンツを見ることができません）。

18

@awesomerobot 管理者は、サイト全体または一部のユーザーをブロックできますか？

19

もちろん、それなしではスパマーを止められません。管理者は、ユーザーがさらにアカウントを作成し始めた場合に、ユーザー自体だけでなく、そのIPアドレスも禁止できます。

20

ここで発言させてください。なぜなら、多様性に富んだ当社の Discourse フォーラムでこれがどのように影響したかを目撃しているからです。

強制されたダブルブロックは、ひどく、ひどいアイデアであり、保護しようとしている脆弱な個人に対してフォーラムの意志を押し付けています。本質的に、「あなたがこのユーザーに対して不安や不快感を感じていることは理解しますが、単に彼らの投稿を非表示にするだけでは済みません。あなたがこれをやった事実を『発見可能』にしてしまうため、そのユーザーはあなたに対して『もう一つの理由』を持って爆発し、攻撃してくるかもしれません」と言っているのと同じです。

Twitter で公に女性と名乗る多くのメンバーが結束して、これがひどいアイデアであることを Twitter に理解させ、ユーザーを自分の表示やタイムラインから削除する「ミュート」機能（これを行った事実を相手に知らせずに）を可能にするまでには、多大な努力が必要でした。

これは現実世界でも同様です。ストーカーに対する保護命令を取得しようとする行為自体が暴力を招く可能性があります。実際、保護命令が下された後、ストーカーが命令を違反する可能性が高まることが示されています。

この理由だけでも、もしこれが Discourse に機能として存在するならば、それは モデレーターやサイトの意志ではなく、リクエストした本人によって選択される 必要があります。

私はこう言いたいです。もしユーザーが誰かをブロックするよう求め、サイトがユーザーに「ユーザー X によって同意なくブロックされた」と通知し、ブロックされたユーザーがエスカレーションした場合、サイト側から見てもこれは明確な責任問題となります。それ以上に、ブロック機能の 利用そのもの に 確実 に萎縮効果をもたらすでしょう（これは個人的な経験から見ています）。さらに、これは攻撃者に権力を譲渡することになります。「私をブロックできないよ、だってバレちゃうから！」と。

私はここで明確に同意せざるを得ません。これは Discourse の機能として 決してあってはならない ものか、あるいは リクエストした本人のオプトインのみ に限定され、エスカレーションの現実的なリスクが 明確に 示される必要があります。

投稿が削除された際、多くの人々が「検閲された」「キャンセルされた」と感じたり、自分が好まない権力関係が押し付けられたりして、非常に怒ります。しかし、何と呼ぼうとも、モデレーションは検閲であることに変わりはありません。そして、それにはメンバーを報復から守るという本質的な義務が伴います。これは、モデレーションの要請が匿名でなければならないのと同じ理由です。

「いいね！」 4
21

実装方法に問題があったように思えます。

メンバーにアプローチする際、私たちは通常、管理者の立場から次のように伝えます。「ユーザーX とのあなたの関係は修復不可能なところまで達していることが明らかになりました。そのため、関係するすべての人の最善の利益のため、今後はお互いを無視することが適切であると判断しました…」

私たちがいじめを理由にブロックを発令する必要に迫られたことは、すでに敵対関係が表面化していた場合のみです。そのため、上記のアプローチは私たちにとって非常に容易です。

22

いいえ、これはアプローチの問題ではありません。「このユーザーは私を不安にさせたり不快にさせたりするので、その人のメッセージを見たくない」という要望は完全に正当であり、モデレーターが同意するかどうかとは一切関係ありません。

フォーラム運営者として私たちが望むかどうかに関わらず、ユーザーが自分が消費する内容をコントロールできるようにすることは、高潔な目標です。

なぜなら、その代替案は、ユーザーがコミュニティを離れ、その貢献が失われてしまうからです。ユーザーは、サイトによる「二重禁止」や、無視されているユーザーへの通知の義務といった「微管理」に耐える必要はありません。あるいは、他の理由からそのようなオプションが必要である場合でも、それは_オプトイン_でなければなりません。

そうしないことは、他のユーザーへの懸念を表明したユーザーの主体性を否定することです。それは彼らの目です。彼らには、目に入るものをコントロールし、自分の決定について誰が知るかを決定する権利があります。

「いいね！」 3