アイディアページ
プロジェクト名決まったら(決まった) ロゴとか決めたい
藍ちゃんのようなマスコットキャラが欲しい
これらは追々決めていきます
メールアドレス必須(なしにしたらスパムが蔓延するので)
メールアドレスドメインのホワイトリスト、ブラックリスト機能
重複禁止
バックアップ用メールアドレスもできたら実装したいかもしれない
バックアップ用メールアドレスについては重複できる設計にしたい
アカウント登録方法
登録時にはCAPTCHAを使ってBotによる多量登録を抑制させる
オープン
オープンの申請の場合はCAPTCHA設定を有効にすることを強く勧めたい
申請式
登録フォームでメッセージなどを入れて申請する
招待式(クローズド)
招待URLを開くと登録フォームが出てきて、それで登録を行う
招待URLが作れる権限も設ける
2段階認証設定
TOTP方式
Google 認証システムとかAuthyとかそういうの。メジャーな認証方法。
WebAuthn(U2FやFIDO)方式
Yubikeyを使うための方式。
できれば実行ファイル一つだけあれば動かせるような構造にしたい(giteaみたいに) データベースはPostgreSQLを使う(MastodonやMisskeyもそれを用いてるため)
RedisでActivityPubのキュー管理
プール処理とかその辺の設計に悩む
ロールでできることの管理
常にできること(凍結、サイレンスしていないこと)
投稿(投稿範囲自由)
ホームタイムライン閲覧
再投稿(例:リツイートなど)
リアクション(Misskeyと互換性をもたせる)
フォローなどのユーザーリレーション機能
プロフィール設定
リスト機能
ブックマーク機能
ノートをまとめる機能(複数作れるようにして、入れられるように)にしたほうがいいな
自由に設定できる権限(ロール単位)
ローカルタイムライン
スマートタイムライン(Misskeyで言うソーシャルタイムライン)
グローバル(連合)タイムライン
アンテナ(Misskeyにもあるやつ)
データエクスポート・インポート権限
(エクスポート・インポート作業にはそれなりの負荷がかかると予想されるので、権限で利用できるかできないかを調整できるようにする)
管理権限
絵文字
ユーザー管理
作成
凍結
サイレンス
連合管理
連合のブロック
お知らせ管理
(随時追加)
ロール設定やコア設定(インスタンス設定など)はスーパーユーザー(インストール時に最初に作ったユーザー)のみ可
管理専用(スーパーユーザー専用)のアカウントに分ける?(検討事項)
管理系のパーミッションは、使用ユーザーとは別のアカウント分ける?(↑)
ロール設定についてはロールごとに表示や非表示を選択することが出来る
Misskeyのリアクションの互換性
MastodonのActivityPubのモデルを継承
インスタンスで管理権限のあるユーザーは、被ブロックされているユーザーでも、管理目的で表示できる権限
(賛否両論あるかも)
MisskeyのIssueでちょっと荒れてそうなのでやめておくことにした
被ブロックされてても、サイレンスとか凍結は通常通り行えないと管理上まずいのでこれについてはできるようにする
誰もが使いやすく、安全なSNSを目指す
整合性の取れるデータベースモデル
柔軟な権限管理(上記が一例)
ユーザーがタイムラインに収集したい情報の選択
指定したインスタンスのユーザーは、フォローしているユーザーを除き、タイムラインから除外できる
ブロックしているユーザー(されているのも含む)は一切表示しない
他のフォロー・フォロワーリストにブロックユーザーがいたら表示しないとか
指定ワードをタイムラインから除外
特定のインスタンスからのフォローは承認が必要な設計にする
ホワイトリストのように
ホワイトリストに入ってるインスタンスのユーザーはフォローを自動的に許可
承認が必要なリストに入ってるインスタンスのユーザーはフォローを保留にするなど
ブラックリストに入ってるユーザーはフォローを承認しない
WebSocketを使ったリアルタイムのストリーミング
ActivityPubの処理はJSON-LD compacted形式で処理する
ActivityPubのセキュリティチェック
管理者が必要に応じてセキュリティレベルを変更できる
低レベル
とにかくすべて受け入れる(受信してきたAPのIDを逆引きしてURLが存在していて、受信したものと合致するものであれば受け入れる)
中レベル(推奨レベル)
httpsプロトコルでない場合は受け入れを拒否する
ActorにpublicKeyプロパティが含まれていない場合は警告する
publicKeyが含まれていて、そのActorのHTTP Signature検証(Mastodonモデル)が失敗した場合は受け入れない
高レベル
※中レベルのセキュリティを含める
ActivityPubのデータに含まれるURIがすべて同じドメインでない場合は受け入れを拒否する
ActorにpublicKeyプロパティが含まれていない場合はそのActorの取得を許可しない(拒否する)
カスタム
以上の内容を個別に設定できる設計
一例
URIが同じドメインでない場合
publicKeyがActorのプロパティにない場合
など。
フロントエンドはAngularを用いる予定
参考:Mastodonはreact、MisskeyはVue.jsをフロントエンドに用いている
デザイン草案
ニューモフィズムなUIにしてみたい
Twitterのホームもあり、TweetDeckのようなマルチカラムも搭載したい
フレームワーク候補
テーマ
Goin Flow
主に青と紫を基本色とし、色相が高い紫を高いフローという意味合いを込めてこの名にした(仮称)
バージョンモデルはnightly, beta, stable(mainにするかも)の3つのブランチモデルで予定
詳細は決まっていないが、nightlyを中心にコミットがすすめられる
各ブランチの保護方針予定(GitHub)
共通(stable, beta, nightly)
GPG署名されたコミットであること
これらの設定は管理者を含める
stable, beta
マージ前にテスト(ステータスチェック)に合格すること
マージ前にプルリクエストのレビューを要求
nightly
マージ前にプルリクエストのレビューを要求
ただし管理者は例外とする
APIはRESTfulとGraphQLを予定
GraphQLは将来的に
CORSの設定を怠らずに
ライセンスはAGPL v3.0を利用予定
カスタム絵文字はアカウント画像の絵文字を標準でサポート(そのインスタンスのユーザーのみのサポート)
形式は:@username:←の形式でやるとYuzuRyo61.iconのように表示される(一例)
連合しないタイプのインスタンス設立もできるような設計(するかは分からない)
Google+、Facebookのように文字数制限上限なし(データベースの型に収まる範囲で)
オブジェクトストレージ
対応しているところが少ないので、後回し
投稿のHTML埋め込み
セキュリティ的にやめておく
アカウント登録時のCAPTCHA認証
reCAPTCHAでも良さそうだけどあっさりと通過してしまいそうなので独自 or 別のやつが良さそうな感じはある
通知用にServiceWorkerに対応させる
通報受信時など、管理に関わるお知らせを送信する時にWebhookを用いる
Slack形式にする
Discordと互換性があるため
投稿データ等のエクスポートをバックグラウンド上で行えるようにする(ユーザーに権限があること)
OpenIDにも対応させたい気持ちもある(需要があれば)
タイムラインの閲覧や投稿などといった、通常のAPI系列はフロントエンドフレームワーク(Angular)を用いる
メールアドレス・パスワードの変更、アカウントの作成や削除といった、APIで処理したくないものについてはサーバーサイドレンダリング(ビュー処理)で行う(CSRFなどで、外部からの不正アクセスを抑制すること)
通常のウェブクライアント用のアプリと、SSRページでNode.jsプロジェクトを作る
個々のアカウントのセキュリティ通知
通常のクライアントでログインがあったらメールで通知する
段階
ログインしたら常に知らせる
新たなIPアドレスからのログインがあったら知らせる(推奨レベル)
知らせない
短時間で不正なログインがあった場合
ログインを試みようとしたユーザーのメアドに不審なアクティビティがあることを知らせる
管理者側で通知の有無を設定可能とする
ログインを試みようとしたアクセス元の接続をHTTP 429などで一時的に遮断(遮断した場合はログに残すようにする。該当アクセス元のアクセス禁止については管理者側の裁量に一任する)
セッションを切れるようにしておく
セッション情報にはブラウザの種類(スマホのChromeとかいう情報)、地域(GeoIPはアカウントのサインアップをしなきゃいけないとかで面倒なのでやめることにした。IPアドレスさえわかれば地域特定はできなくないはず)、IPアドレス、ログイン日時などを記録しておく
アプリの認証を許可した場合のメール送信
新たにアプリを追加した場合は必ず送信するようにする
個々のアカウントの監査ログを確認できるようにする
個々の監査ログは削除できない(証拠隠滅をさせない)
監査ログが記録される例
パスワードを変更した
メールアドレスを変更した
新しいアプリを追加した
該当のセッションを終了(アカウント設定から切断)した
連携したアプリを削除した
サードパーティアプリを認証するための規格はOAuth 2.0を用いる予定
authentication_code形式
ウェブクライアント、フォローリレーションはインスタライク(フォローされていると直接的な表示をしない)にしてもよさそう
クライアント設定で任意でもとの表示(フォローされているとの表示)にもできるようにする
フォローしてない、フォローされていない、フォロワー数が少ないユーザーの通知(リプライなど)は通知しない設定
孤高モード(Lonely Mode)
誰からのフォローを受け付けないモード
需要あるかわからないけど、負荷を軽減するという観点を考慮したらアリかも
アカウント削除は猶予期間を設ける
30日ぐらいにしておく(ユーザー名を二度と戻すことが難しいので、1週間ぐらいだと猶予が短い)
今の設計だと削除後もメールアドレスは残ってしまうが、再利用はできるようにしたのでOK
メンテナンス機能
管理者のみができる
削除済み(論理削除)のアカウントの情報を削除(内部ID、ユーザー名、ActivityPub通信に必要な鍵は残す)
期限切れ(論理削除)の招待コードの情報を削除