現在このステップにいるというお知らせです
「いいね！」 5
素晴らしいですね！
最近、Mastodonサーバーを運営しているCoSocial Co-opのためにDiscourseサーバーをセットアップしました。OAuth2プラグインをセットアップし、Mastodonサーバーからのログインのみを受け付けるようにしました → https://members.cosocial.ca （非常にシンプルな新規インストールで、「OAuthの証明」のみです）。
私の質問/機能リクエストは、MastodonのアクターをDiscourseアカウントにステージング/マージできるようにすることです。これにより、Mastodonのアカウントが返信したときに、関連付けられたDiscourseアカウントによってリンク/所有されるようになります。
Lemmyがこれをしない方法
Lemmyがこれをしない方法を文書化しました。Mastodon経由で対話でき、そのMastodonアカウントのLemmyアカウントが作成されますが、MastodonアカウントでログインしてLemmyのファーストクラス機能を使用することはできません。
「いいね！」 4
それは議題にあります…
そして、すでにレビューのためにキューに入っています
「いいね！」 3
素晴らしい。私のDiscourse OAuthプラグインのユーザーは、このAPプラグインと相互運用するために「再度確認」する必要があるということですね。
現段階では全く問題ないと思いますが、競合しない限り、OAuthサーバーをもう一つの角度として指摘しておきたいと思います。「あれば嬉しい」のは、「MastodonサーバーとのOAuthの場合、APアクターIDを自動的にリンクする」ことです。これは完全に将来的なもので、この種のセットアップに特有なものです！
（そして、その部分を確認するためにページを開かなかったことをお詫びします！素晴らしいです！）
「いいね！」 1
この一連の機能を追加するPRはマージされました。
Angusが上記で述べたように、次にOAuthトークンによるユーザー認証を行います。
「いいね！」 2
以前、生のMarkdownがそのまま表示される問題がありましたが、メタでも同様の問題が発生しているようです。私は@feature@meta.discourse.orgをフォローしており、数時間前にこの投稿がそのアクターからフェデレーションされました。
これはMastodonでは以下のように表示されました。
Elkでは、もう少しマシな表示になります。
今、純粋なMastodonアカウントで@feature@meta.discourse.orgをフォローし始めたばかりですが、もちろんこの特定の投稿がそこで見られるのは遅すぎます。 
したがって、以前自分のインストールから見た埋め込みMarkdownは、データベースが悪かったわけではなく、もしそうだったとしても、メタと共有されたデータベースの問題であり、おそらく私のテストとは関係ないでしょう。
「いいね！」 2
はい、再現できました。MastodonインスタンスとIvory（iOSアプリ）で同様の出力が見られます。
「いいね！」 2
これが正しく機能しているかどうかわかりません。プラグインは有効になっており、ActivityPubが有効になっているカテゴリにトピックを作成しましたが、投稿の横にバッジが表示されません（カテゴリのactivitypubアクターをフォローしようとしたところ、フォローを手動で承認する必要があるサーバーのように動作しているため、失敗したようです）。
Metaでも同様の問題が発生していることに気づきました。 Feature
「いいね！」 1
制限の最終目標を、中間状態を気にすることなく理解できると素晴らしいと思います。
例えば、PRで、プラグインが有効になっている場合、投稿の所有者を変更することがブロックされるという参照を見たと思います。管理者として、私はまれにその機能を使用しなければなりません（例えば、カテゴリモデレーターを変更する際に、新しいプライマリカテゴリモデレーターをスティッキー投稿のカテゴリの所有者にします）。最終的には、これが削除と再投稿、あるいは単に無視されることを期待しており、所有権の変更をブロックするのではなく、そうなることを願っています。
また、投稿をカテゴリ間で移動することについても疑問に思っています。特に新しいユーザーが間違ったカテゴリに投稿した場合、私はかなり頻繁にそれを行う必要があります。私は、1つのカテゴリのアクターがブーストを削除し、新しいカテゴリのアクターがブーストを追加する結果になることを単純に期待しますが、基になる投稿を削除するのではなく、他の誰かが投稿をブーストしていても、カテゴリのアクターのブーストがなくなっただけでそのブーストが消えないようにします。
一般的に、現在指定されている機能開発が完了した後、このプラグインが追加されたときに何が許可されなくなるのかを知ることは、現在実施されている制限に関係なく、非常に役立ちます。
「いいね！」 1
「いいね！」 2
さらなるご報告ありがとうございます。調査中です。
ご報告ありがとうございます。調査中です。
お気持ちは理解できますが、
- プラグインは現在積極的に開発中であり、現時点でそのように説明しようとすると非生産的になる可能性があります。説明が変わるかもしれません。
- プラグインはすでにかなりの数の異なるシナリオやエッジケースを処理しています。現時点でそれらすべてを物語形式で説明するには時間がかかりすぎます（つまり、この長い投稿を何度も行うことになります）。プラグインにはすでに400以上の仕様があります。
- それでも、制限については、PRやコミットのコメントで物語形式で説明されることがよくあります。そちらはすでに読んでいるかと思います。
これはPRで詳細に議論されました。
APトピックでは、管理者であっても、投稿の所有者の変更と投稿のウィキ化を制限しました。これは、リモートAP投稿は元の投稿の忠実度を維持する必要があり、両方の操作がその忠実度を損なう可能性があるためです。
ウィキと投稿の所有者の変更の両方でフェデレーションが機能する方法があるかもしれませんが、これは将来のPRで「機能」として追加することをお勧めします。これは、複数のプラットフォームにわたってフェデレートされたオブジェクトのアクターを倍増または変更する必要があるためです。インポートされたAP投稿（ノート）の投稿所有者の変更は、「削除」というよりは、ノートを「表示しない」という選択であるため、決して許可できないと思います。
投稿の移動には、かなりの数の異なるシナリオが関わってきます。現時点では、あなたが言及した特定のシナリオ、つまり投稿をアクティビティパブが有効になっている2つの異なるカテゴリ間で移動する場合に対処します。
投稿が間違ったカテゴリに最初に投稿され、すぐに移動される場合にのみ、投稿がカテゴリ間で移動されると仮定しています。では、投稿から4か月後に、特定の投稿コレクションを別のカテゴリの新しいトピックに統合したいので、その投稿を別のカテゴリに移動した場合はどうでしょうか？そのシナリオで元のブーストの「取り消し」を送信することは理にかなっていますか？
これは、最初の投稿構成か、完全なトピック構成かによって異なります。前者については、カテゴリ移動シナリオを特別に処理するために、最初の投稿を手動で公開するためのボタンを追加します。後者については、自動的にブーストを追加することが理にかなっているかもしれません。もう少し考えてみます。
お気持ちは理解できますが、フェーズ2の仕様で、すでにかなりの詳細を共有しました。その仕様を超えて、できるだけ穏やかに言うと、皆さんとDiscourse.orgチームと深く議論しながら作業するには、ユースケースやシナリオが多すぎます 
フェーズ2が完了したら、予想される動作の一般的な概要をOPに更新します。
「いいね！」 1
この問題は再現できません。テスト用のMastodonアカウントからfeature@meta.discourse.orgをフォローしましたが、MastodonでもDiscourseでもエラーは確認されませんでした。
「いいね！」 1
このインスタンスが何か変わったことをしているかどうか、関係があるかもしれません。
おっと、明確な質問をしようとしたところ、多くの作業を依頼しているように聞こえてしまいました。誤解を招いたことをお詫びします。丁寧なご回答に感謝いたします。
私が求めていたのは、このスレッドでの継続的な詳細な更新ではなく、それでした。「現在指定されている機能開発が完了した後」の「後」は、明確化が役立つ時期を意味しており、将来の状態を今説明するように依頼する意図ではありませんでした。私の質問は曖昧な言葉遣いでした。申し訳ありません！
これが私が本当に理解したかったことです。大まかに言って、Discourseを標準のActivityPubがサポートするものだけに制限することが最終目標ですか、それとも、制限のないネイティブDiscourseエクスペリエンスからフェディバースにベストエフォートでフェデレーションすることですか？ Discourse統合に関する私の過去の経験からベストエフォートを期待していましたが、今では、開発中の一時的な措置としてではなく、Discourseの機能性を犠牲にしてでも、忠実性を追求する計画であることを理解しました。
私はそう想定していません。なぜ4か月がここで違いを生むのでしょうか？それは新しくフェデレーションされたカテゴリにありますが、なぜそれがフェデレーションカテゴリにそれをブーストさせないのでしょうか？少なくとも私は、そうなるだろうとナイーブに期待していました。私はしばしば、数か月前の投稿をブーストする人々を見かけるので、これが異なる特別な理由があるとは知りません。
そしてはい、元のブーストの「元に戻す」を送信するのは理にかなっていると思います。それは一般的であるようです。（実際、「元に戻す」してから新しいブーストを行うことは、コンテンツを「バンプ」するための一般的なメカニズムのようです。この目的とは関係ありませんが、「元に戻す」が一般的に使用されており、他のActivityPub実装に問題を引き起こすべきではないことを示しています。）
現在、feature@meta.discourse.org についても同様の状況を確認しています。これは、プレーンなバニラ Mastodon を実行していると思われる mastodon.cloud からのものです。
「いいね！」 1
個人的には、どちらとも考えていません。Discourse.org が全体的なアジェンダを設定しますが、大まかに言えば、決定はそれがどのように機能するか、そして何が現実的かに基づいて行われます。投稿の出所に関係なく、すべての投稿の作成者変更を可能にする、合理的で持続可能な方法があるなら、それは素晴らしいことです。
元のブーストの取り消しに焦点を当てると、その特定の Undo は目的を果たしていないように思えますか？また、シナリオによっては少し驚くべきことであると、私の例は示そうとしました。カテゴリの移動の意図は、コンテンツの元の「発見可能性」を（Undo で）取り消すことではないかもしれません。それは、別の理由で、後でコンテンツの編成を変更することを目的としているのかもしれません。
別の言い方をすれば、Discourse でのカテゴリ変更に対する元の Announce の自動的な逆適用は、一部のシナリオでは機能しますが、他のシナリオでは機能しません。そして、より理にかなっているように見えるシナリオでさえ、元の Announce は実際には何も害を及ぼしていません。したがって、最小限の害と最小限の驚きの原則を追求すると、元の Announce をそのままにしておく方が理にかなっているように思えます。何か見落としていることがあればすみません。
別の角度から考えると、カテゴリ アクターの Announce アクティビティを、カテゴリ自体の分類学的役割と同等に考えるのは正しくないと思います。Announce は、カテゴリ アクターがフォロワーとコンテンツを共有する方法ですが、それ自体が分類ではありません。それは、Fediverse 内でコンテンツが発見される方法の 1 つです。カテゴリ アクターの Announce アクティビティとカテゴリの間に 1:1 の関係が必要だとは思いません。
「いいね！」 3
ああ。では、それは本当にチームへの質問ですね。
それも理にかなっています。ブーストを元に戻すことにあまり価値がないということには同意します。
したがって、それはエッジトリガー信号になります。それは「投稿が、作成されたか、またはカテゴリに移動されたことによって、ちょうどこのカテゴリに入った」ことを意味します。これは概念的に単純です。
それなら、投稿の作成者を同様の方法で変更することを考えます。それは、新しい作成者の投稿に対する新しいアクティビティを作成する新しいアクターになります。古い作成者の下で行われた古いアクティビティについては、古い作成者は編集を行うことはなく、新しい変更の責任を負うべきではないため、何もする必要はありません。彼らは実際にDiscourseで投稿を削除したわけではないので、元の作成者のアクティビティを削除することは、必ずしも基本的な真実を反映するわけではありません。しかし、古い作成者のアクターが以前に投稿したものは、彼らが書いたものであり、それらの投稿を削除する理由はありません。そして、誰かがDiscourseへのリンクをたどった場合、彼らは現在のコンテンツと作成者を確認し、（十分な権限があれば）編集履歴を表示できます。
同じロジックがウィキにも当てはまります。それらはDiscourseでは単一の作成者として表示されますが、他の人が書くことを許可します。他の作成者による更新は、広く帰属表示されません（履歴を読むのに十分な権限がない限り）。その帰属が、Discourse内のWebビューのアバターによって表示されるか、または別のレンダリングパイプラインのもう一方の端にある人間読者に提示される帰属であるかに関わらず、実際にはあまり意味がありません。
「いいね！」 1
うーん、同意できるかどうかわかりません。この結果、Fediverseには異なるアクターによって作成された2つの同一のノートが表示され、どちらも複数のプラットフォームで表示されたままになります。初めてそのコンテンツに触れる人にとっては、異なる人物によって作成された同じコンテンツが表示されます。逆に、Discourseで著者を変更すると、基本的に履歴が書き換えられます。初めてコンテンツに触れる人には、新しい著者だけが表示されます。そこには違いがあると思いませんか？
よく理解できません。Wiki投稿へのすべての編集は、ユーザーに関係なく、元の投稿者（つまり、投稿した人）に帰属する標準的な更新アクティビティとして扱われるべきだということですか？
これは、このPRの主題であり、説明的な注釈が添えられています。
「いいね！」 4