@ Hub構想
背景
indigoのbgs(big-world-server, bigsky)では以下のような構成で投稿を保存している
# なんかいい感じの図
各アプリケーションの投稿の実体はcarstoreデータベースの内部にDAG-CBORとして格納されている: 参考 。 例えばapp.bsky.feed.postはbigskyではbgsデータベース内のfeed_postsに各投稿が格納されているが、レコードにはcarstoreから投稿の内容を呼び出すためのcidとrkey、user id(auhor)が記録されているのみである
ここから読み取れるのは、app.*なサードパーティアプリであってもlexiconによって型が共有されていればbigskyはどんなアプリケーションでも受け入れ可能ということ
つまりbluesky公式が言っていた「blueskyはリファレンス実装」で「サードパーティアプリじゃんじゃん作ってくれよな！」っていうのは実装上もその前提になっていたっぽい
ここまで前置き
俺の考えた最強SNSアプリケーション
上記の背景を踏まえると、big-world-serverを通して複数のアプリケーションが簡単に繋がれるんじゃね？
さらに言うと、PLCサーバーにあるDIDを単一のアカウントとして、TwitterもYoutubeもSignalもDiscordもpixivもインスタもTikTokもその他いろいろ全部一緒になったスーパーアプリ体験を提供できるんじゃね？と考えました
そこで、複数のサービスの使用状況を表したウィジェットを組み合わせて自分だけのプロフィールページ作れるサービスとか面白くない？という発想が浮かびました。これってATProtocolサービスのHubじゃん！
サービス間のつながりを図にするとこんな感じ
# いい感じの図
Hubで作ったプロフィールページは多分こんな感じ
# いい感じのモック（作れるか？）
よいところ
同じことは例えばGoogleが全部作る or 全部買収する or 全サービスにAPI開放してもらう、で実現可能ですが...
ATProtocolならAPI開放前提だし、lexiconによって型共有もできるので最初からオープンです
基本的にOSSなのでサービス運営が潰れてもすぐ代替サービスに切り替えられます。型に対してサービス運営側は密に結合していないので
各国の法へのローカライズも、それぞれの法的基準に対応したPDSやbig-world-serverを選べば良いです
一言で表すと、スーパーアプリだけど機能毎に分業されていて代替可能性があり、アプリケーションとしての持続性が高いです
大変なところ（もうちょっと具体的な開発の話）
機能毎に自由にPDSを変えられることが持続性をキープする上での大前提なので、認証情報をbskyが握っているのはきつい
問題点の詳細
理想的には、認証用のOSS-ATProtocolなアプリケーションがあって、それ自体も代替可能になっているのが望ましい
bskyと認証サーバーを一緒にするのはbsky側がサービス終了する時に認証も一緒に終了することになりリスクが高い
そもそも分業できるのに一緒のアプリケーションとして開発するのはATProtocolの思想的にどうなん？
解決案
認証用アプリケーションを立ち上げてbskyにはそこにOAuthしてもらう。これならlexiconの追加だけで済むので破壊的変更は起こらない サードパーティアプリの作成、もっと言えばlexiconを追加するためのドキュメント、参考事例が足りない
解決案
頑張って自分で作る、時間かける、流行る
開発者のモチベーションになるわかりやすいインセンティブがあると良い？
もっと先のはなし
ひと、じかん、こうすう
Hub運営がモデレーション基準握っちゃわない？
labeling機能でバランスが取れないかなと思っている
つまり、各機能で貼ったラベルに合わせて各Hubが表示内容を調節する。Hubサービスをまたいだ交流はBGS経由で行う
これなら各機能はラベル貼りだけやれば良いしユーザーもAlgorithmic choiseができる？
要するに、発信は自由に、受信は各自で制限する。ちょうどATProtocolのこの資料が同じことを説明してます それはそれとして
今一番ユーザーが欲しいのは多機能じゃなくて情報の流通のコントロールだよなぁ
余計なものは流れてこない、嫌な人からは認識されない、インプットとアウトプットのコントロール
DiscordとVRChatが比較的上手くやれてると思うので、もうちょっとオープンにできないかなと思ってる。これは別テーマ
VRChatの部屋の種類、public(スラム)→friend+(友達の友達, 大体のイベント会場)→friend only→invite+(招待受けた人が招待できる)→invite only(部屋主の招待のみ)って細かく分けてるのが流用できる？
この区分けで言うと今のbskyはinvite+のみのひとつの部屋があるって感じ