何とは言わない天然水飲みたさ

ぼくのかんがえたさいきょうの SNS (のメモ)

分散 SNS の(ユーザに面した)設計の在り方について考えたことのメモ。

……と思ったけど、よく考えたらこれ分散関係なく SNS 全般について言えるわ。

前提

話題による選別

たとえばあるユーザ A がいたとしよう。 A は、主としてお絵描き(全年齢)、お絵描き (R18)、政治的な主張、プログラミングの話題、学校の友人との会話を行うものとする。

さて、あなたは A の投稿を自動的に受信したいと考えている。 ただし、精神の安寧を守るため、政治的な主張は閲覧したくない。 (また、 A とは学友であるとしよう。)

既存のアカウントベースでのフォロー関係やタイムラインは、こういった用途での利用にあたっていくつかの問題を抱えている。

送信者のマルチアカウント

twitter をはじめ、既存の SNS サービスで既に用いられている手段である。 たとえば「お絵描き(全年齢)」「お絵描き(R18)」「知り合い用」などのようにアカウント(「垢」)を複数用意し、使い分ける。

しかしこれは簡単に破綻する。 「学友とプログラミングについて会話する」とき、プログラミング垢と知り合い垢のどちらを使うべきだろうか。 一方のみを使えば、この話題に関心を持つかもしれなかったもう一方のフォロワーに話題が届かない。 かといって両方で同じ投稿をすると、両方ともフォローしている人に重複した邪魔な投稿が届くことになる。

また、いずれの分類にも属さない話題で投稿したいとき、「その他」などのアカウントも用意しなければならないとすれば、あまりに微妙である。 こういった自明でないアカウントが存在すると、「 A の投稿を全て受信したい」というユーザにとっては面倒である。 A もまた、自分のアカウント一覧を作って(それぞれのアカウントから)提示する必要性を感じるかもしれない。

送信者のハッシュタグ付加

ハッシュタグにより、投稿に特定の(0個以上の)文字列をキーワードとして指定することができる。 しかしこれは、特定の(それなりに狭い範囲の)話題について追い掛けたい場合は有効に働くが、雑談であったり情報量の低い投稿に付けるのには向かない。 加えて、個々人によって表記や名前に揺れなどがあるにも関わらず、ハッシュタグはサービスやインスタンス全体で共通のものである。

たとえば、 A がイラストを投稿するとき「#イラスト」というタグを付けるだろうか、それとも「#おえかき」というタグを付けるだろうか? あるいは、 A がお絵描きの技術を語るとき「#イラスト」というタグを使ったらどうなるだろうか? あなたは、 A が投稿したイラストを、ハッシュタグによって漏れなく取得できるだろうか?

もっと広い話題ではどうだろう。 A が特定の政治的な問題について発言をするとき、必ず「#政治」などという一般的すぎるかもしれないタグを付けることを期待できるだろうか?

問題

上に挙げたような仕組みの問題を要約すると、以下のようになる。

  • ユーザや話題は、排他的でない複数の属性を持ちうるが、アカウントによる分類は排他的である。
  • ハッシュタグは、ユーザローカルでなく、またその表現するところも曖昧である。
    • 「#ほげ」は「『ほげ』に関係する話題」程度の情報しか提供しない。
    • また、タグは本文と分離されたメタな文字列情報としての特性を利用し、セルフツッコミ等に利用されることもある[0]ため、用途が安定しない
    • べつの言い方をすれば、ハッシュタグはシステムとしての意図が明確でない
  • ハッシュタグは、任意の文字列により表現される性質ゆえ、発信者にとって入力が手間である。
    • ハッシュタグを簡単に選択したり自動入力するクライアント等も存在するが、これは全てのクライアントに共通の機能ではない。
    • この実装の差異も、システムとしての意図が明確でない(あるいは、そういった用途で使うことが明示・推奨されていない)ことが一因であると考えられる。
  • ハッシュタグは、事前に提示されるとは限らず、また任意の文字列により表現される性質ゆえ、受信者にとって予測が困難である。
    • 過去に「#お絵描き」を使ったからといって、未来に投稿されるイラストで「#お絵描き」が使われる保証はない。 「#落書き」「#イラスト」「#おえかき」などになるかもしれないし、安定せず複数が使われるかもしれない。
  • ハッシュタグは、広範囲な話題での選択を支援できない場合が多い。
    • ハッシュタグは、ある意図を示す詳細なハッシュタグがあるとき、それを包含する汎用的なハッシュタグが使われるとは限らない。
    • たとえば、「#ポインタ」「#C言語」タグを使った人が、わざわざ同じ投稿に「#プログラミング」「#コンピュータ」などのタグを付けてくれるとは限らない。 付けてくれたとしても、多くの受信者にとっては冗長になるだろう。
    • この性質は、「特定の広範囲な話題を選択したい」という要求の実現を困難にする。

提案: ユーザの『文脈』

仕様

  • ユーザアカウントは、0個以上の『文脈』を持つ。
    • ユーザアカウント @user に対し、『文脈』 context を @user/context と表現する。
    • 直観的には、文脈とは投稿の集合の、排他的でない部分集合である。
  • ユーザアカウントからの投稿は、投稿者ユーザアカウントに加えて、0個以上の『文脈』と紐付けられる。
    • たとえば @user ユーザから発信されたある投稿は、 @user/foo@user/bar に紐付けられるかもしれない。
    • 適当な文脈が見付からなかったり、部分的であれ自分をフォローしているユーザの全てに見せたい投稿は、文脈に紐付けないことができる。
  • ユーザは、アカウントそのものまたは『文脈』から、アカウントまたはその『文脈』をフォロー/ブロック/ミュートできる。
    • @user をフォローすればユーザの全ての投稿を受信でき、 @user/foo をフォローすれば、 @user/foo に紐付けられた投稿だけを受信できる。
    • @user をフォローし @user/政治 をミュートすれば、 @user/政治 に紐付けられた投稿以外を受信できる。
    • 自分のアカウントの各『文脈』ごとに、フォロワーの投稿が流れてくるタイムライン(いわゆるホームタイムライン)が用意される。
      • 一部の用途におけるリストの代替たりうる。
    • フォロー関係は、「アカウントまたは『文脈』」から「アカウントまたは『文脈』」への辺として表現されることになる。
      • 相互フォロー関係などを考えたい場合も、『文脈』がアカウントに属することを考慮すれば、アカウント間の関係へと簡単に落とし込むことができる。
  • 『リスト』には、ユーザアカウントまたは『文脈』を追加できる。 『リスト』は、ユーザアカウントに属する。
  • ユーザは、自分の『文脈』を自由に追加または削除できる。
    • 追加や削除は、フォロワーに対して何ら影響を及ぼさない。 投稿が消えたりすることもない。
    • ユーザから見れば、単に「ハッシュタグを使うのをやめた」程度のことである。

意義

排他的でなく、かつ(受信者にとっても送信者にとっても)選択しやすくノイズの少ない「分類」をシステムとして提供することが『文脈』の意義である。

そこで、『文脈』はユーザの「側面」を表現する手段を提供する。 人間の政治的な側面、学生としての側面、プログラマとしての側面、絵描きとしての側面……などなど、人間には多くの「側面」があるが、これらは排他的でないことも十分ありうる。 『文脈』は、それらの側面それぞれを表現するものである。

また、『文脈』を「話題」や文字通り「文脈」として利用することもできる。 これは、「側面」の更に一部分を表現したものと捉えることもできるだろう。

排他的でない『文脈』の存在によって、ユーザアカウントをひとつの人格と正確に紐付けて使えるようになる。 マルチアカウントと違って、話題によって人格を「分割」する必要がなくなるのである。 これは従来のマルチアカウントの利用を阻害するものではない。

『文脈』の特徴

  • マルチアカウントと違って、排他的でない
    • ひとつの投稿に複数の『文脈』を使うことができるし、その場合であっても投稿は重複しない。
  • マルチアカウントと違って、選択を強制されない
    • 『文脈』を紐付けないことができる。
  • ハッシュタグと違って、ユーザごとに名前空間が分かれている
    • 検索などにおいて、他のユーザが同じ文字列のハッシュタグや『文脈』を利用しても、検索結果が混乱しない。
  • ハッシュタグと違って、あるユーザについてリストアップが簡単である。
    • これは、『文脈』がハッシュタグと違って、投稿でなくユーザに紐付いており、ユーザによって事前に使用を宣言されているからである。
    • これにより、「ユーザが関心を持って情報を発信している分野」を暗黙に表明することに利用できる。
      • 無論、プライベートなものや R18 などのものは、リストアップから隠すことも(システムとしては簡単に)可能である。
  • TweetDeck によるマルチアカウントのようなインターフェースと相性が良い。
    • 発信者は、アカウントを選ぶのと同程度かそれ以下の手間で『文脈』を選択できるから、学習コストは高くない(はず)。
  • 『文脈』を考慮しないシステムとの互換性を簡単に維持できる。
    • 『文脈』の代わりにアカウントそのものを使うことで、フォロー関係等は従来のアカウント単位のシステムに簡単に落とし込める。