私の場合、DBのテーブル設計を考えながらアプリケーションの機能をまとめていくので、まずはどういうサービスにしたいのかを考えながら、ざっくりとしたテーブル設計を書いてみた。 利用者はパーソナリティ（personalities）テーブルで管理される。NetJockeyというのは、twitterライクなマイクロブログの語り手をラジオのDJ（パーソナリティ）、その言葉の連なりをDJのトークに見立てて名付けたネーミングだ。だからパーソナリティ（personalities）がトーク（talks）するという形でのテーブル設計となっている。 トークに含まれるURL（talks_uris）、ASIN（talks_asins）、タグ（talks_tags）、位置情報（talks_locations）などを抽出することで、同じ話題に関するトークをまとめることができる。またURL（uris）に関しては、URLのFQDN（uris.hostname）に別途インデックスを用意することによって、URL完全一致だけでなく、「あるドメイン上のURLに関する話題」のような範囲を広げた形で話題を追うことも可能にする。位置情報に関してもGIS関連機能を使って「○○近くの話題」などを追いやすくする。 NetJockey内部でのやりとりに関しては、twitterの「@～」に相当するパーソナリティ対パーソナリティ（talks_personalities）のほかに、発言同士の関連性（talks_talks）も管理する。特定の発言に対する反応を明示する仕組みだ。表記法としては2chライクに「>>発言番号」などで表してもいいかもしれない。 話題をフォローする方法については、発言者（following_personalities）のほかに、URL（following_uris）、ASIN（following_asins）、タグ（following_tags）、トーク（following_talks）、位置（following_locations）などさまざまな方法を用意している。ただ、これをユーザーが手動でいちいち登録するというのでは使い勝手が良くないように思うので、基本的には自分のトーク中に含まれるURL、ASIN、タグ、位置情報、発言者、トークなどを自動的にフォロー対象に追加していく（古いものは自動消去？）といった形にすることを考えている。これならば自然な形でこれらの機能を利用することができるだろう。もちろん明示的に特定のフォロー対象を追加・削除することも可能にする。 フォローの反対に、見たくない情報を見なくて済むようにする方法としては、人間単位でのブロック（blocked_personalities）を用意している。個人レベルでのブロック機能については、私はあまり重きを置いていないのだが、スパム対策としてはこの手の機能は必要だろう。また、システム全体としてのブロック（public_blocked）も用意しておく。こちらに登録されたパーソナリティは、いわゆるスパム系パーソナリティとして通常の表示対象から除去することができるようにする。その逆に、システムからの通知などを強制的に表示するためのシステム全体としてのフォロー（public_following）と言うものも考えているが、実際に利用するかどうか微妙なところだ。 認証（authentications）に関しては、1470.netと同様に外部認証系APIを主に利用することを考えている。はてな認証API、typekey、OpenID、携帯端末IDあたりが主な認証手段となる。また、APIなどで利用するためのサービスローカルなパスワードも一応保持しておくことを考えている。 本当はもう一つ、ディレクトリ（directories）という話題をまとめる単位を用意することも考えていた。ディレクトリとは、2chにおける板的なもの。あるいは、NetNewsにおけるニュースグループ的なもの。つまり、システム側である程度話題の分類指針を示しておき、利用者がそこから自分の好きなディレクトリを選んで発言することによって、半強制的に話題をある程度分類してしまう、というアプローチだ。このディレクトリ自体をWikiとしてユーザーが自分たちで編集できるようにしておくことで、世の中の話題のカテゴライズがリアルタイムで視覚化できるのではないか、などとも妄想した。 これはこれで非常に面白そうにも思えるのだが、それがなくてもすでに話題の分類のための手段は十分に用意されているし、ディレクトリ＋Wikiという仕組みはそれ自体がある程度以上に複雑すぎて、まともに立ち上げるのはすごく困難そうに思えた。そこでこの機能は割愛することに決めた。ただし、メインのサービスが十分うまく立ち上がった後に余力があれば、このアイディアは復活させるのも面白いように思っている。