コミュニティプラグインレジストリとバンドル

レジストリは2つの部分から成り、どちらも個々のDataCoreデプロイメント自身のデータベースとは意図的に 分離されています。これにより、独立したインストール間で共有できます:

• registry/ — バックエンドAPI、ユーザーアカウント、SQLiteバックエンドの掲載データストア。
• community-site/ — 独立したウェブサイト (独自のReactアプリ、独自のDockerサービス、ポート 5273) で、DataCoreの他の部分を一切実行せずにコンテンツを閲覧・投稿できます。これがレジストリに 独立した到達先としてアクセスする主要な方法です — メインアプリのリソース/プラグイン画面にも利便性の ためのパネルがありますが、すべて同じ registry APIと同じデータを参照します。

2種類の公開掲載をホストします:

• プラグイン — 名前、説明、作者、バージョン、プラグインのリポジトリへのリンク、(任意で) Docker イメージ参照とタグ。
• DataCoreバンドル — 共有可能なリソースの「レシピ」: リソース定義 (名前、タイプ、ソースURL) の 一覧と、それらを処理したパイプライン (ステップの順序とどのプラグインか、名前とリポジトリリンクで 相互参照)。完全な流れはバンドルの共有とインポートを参照してください。

投稿によって実際に保存されるもの

どちらの掲載タイプもメタデータとリンクのみを保存します — 実行可能なコードは決して保存されず、 (バンドルの場合) 処理済みの生の成果物データも決して保存されません。これは意図的なスコープ判断です:

• 見知らぬ人が投稿したコードを他人のインフラが自動的に実行することを許可するのは、サプライチェーン /RCEリスクです。そのためプラグイン掲載は、あなたが自分でクローン・レビュー・デプロイするリポジトリ へのポインタです。
• バンドルは元のソース (URL) とパイプライン定義へのポインタです — インポートするとそれらのソース を再取得し、インポート者自身のパイプラインで再処理します。エクスポート元の実際のSummary/Vector/ 分析出力が送信されることは一切ありません。

アカウント

どちらの種類の掲載を投稿するにも、確認済みメールアドレスを持つ無料アカウントが必要です (閲覧には 不要です)。登録、メール確認、パスワードリセット、GitHubサインインについては ユーザーアカウント を参照してください。

使い方

実際に稼働しているインスタンス community.datacore.wakewakanai.com にアクセスするか、 メインWeb UIのパネルを使用してください: プラグイン → コミュニティを見る、および リソース → バンドルとして共有 / コミュニティからインポート。これらはすべて (コア ウェアハウスAPIではなく) レジストリサービスを直接呼び出します — レジストリAPIリファレンス を参照してください。

自分のDataCoreチェックアウトに対してローカルで実行するには、registry + community-site は このリポジトリのメインの docker-compose.yml とは別の docker-compose.registry.yml に定義されており、 デフォルトの docker compose up では起動しません:

docker compose -f docker-compose.registry.yml up -d --build

自分自身のレジストリインスタンスを運用する

この方法で起動した registry インスタンスは、ローカルデモや信頼できる社内デプロイ向けの単一ノード インスタンスです。複数の無関係なチームが投稿する、本当に公開されたインターネット向けのレジストリが 必要な場合、公開前に以下を追加する必要があります (稼働中の community.datacore.wakewakanai.com インス タンスは、モデレーション/CAPTCHA以外はすでにすべて備えています):

• モデレーション — アカウントとメール確認は存在しますが、管理者によるレビューキューはなく、 掲載を削除できるのはその所有者のみです (モデレーターによる上書きはありません)。どのデプロイにも まだ追加されていません。
• 実際のメール配信 — SMTP_HOST が設定されていない場合、確認/リセットメールは送信される 代わりに registry/data/outbox/ に書き込まれます。SMTP_HOST/SMTP_PORT/SMTP_USER/ SMTP_PASS/MAIL_FROM を設定するか、送信ドメインにSPF/DKIM/DMARCを設定したセルフホストの リレーを指定してください (稼働中のインスタンスはこの方法でメールを送信しています)。
• 固定の JWT_SECRET — 設定しない場合、コンテナ起動のたびにランダムなシークレットが生成され、 再起動のたびにすべてのセッションがログアウトされます。
• より強力な不正利用対策 — 基本的なIPごとのレート制限 (20件/時間の投稿、15分あたり20回の認証 試行) はありますが、実際の公開デプロイではCAPTCHAなどを追加すべきです。どのデプロイにもまだ 追加されていません。
• TLS + 実際のドメイン — 証明書を持つリバースプロキシの背後にデプロイし、各DataCoreデプロイメント のフロントエンドを、同居する registry コンテナではなく、その共有URLに向けてください。

モデレーションとCAPTCHA/より強力な不正利用対策は、まだどこにも実装されていません — 信頼された ネットワークを超えて自分のインスタンスを公開する予定がある場合に、サプライズではなく情報に基づいた 判断ができるよう、ここに明記しています。