[mixi]SNS 2.0 - mixi2.0: mixi×Web 2.0を考える

[1] mixiユーザー 03月02日 19:15

読んでみて思ったコト。

mixiが外部のAPIという点で弱いのなら、内部からアクセスAPIを充実させるのはどうなんだろうと、ふと思いました。内部APIっていう言葉が適切かわかりませんが、ログインした人だけが使えるAPI集というか…。

アドバンスなモードの日記（？）に
recentAccessMyUser();
って書くと、表示が
「中野宗」と置き換わったりとか。

で、それのAPIの募集もMixi内でやっちゃう。

他のサービスとの組み合わせは、外部からMixiと何かをつなげるのはなく、Mixi内から外部のAPIを呼び出しちゃう。そういうインターフェースを持つ感じ。

非常に閉じた世界になりますがユーザーが多いだけに面白い使い方をする人も出そうです。

Web -2.0ぐらいになるかもしれませんが。

[2] mixiユーザー 03月02日 19:46

私もちょうど今、似たような事を考えていたのですが。

信頼のおけるサードパーティが設置した外部Webサーバ上に
mixi専用ブラウザまたは RSSリーダを提供して、
そこ経由で外部サービスを呼び出す
(mixi情報はタッピングしない)
という方法が、現実的なのではないかと。

[3] mixiユーザー 03月02日 19:50

まったく話それますが、こういう議論、開かれたBlogosphere
と、閉じたSNSをまたがって議論や雑談が続くことって、これ
からはどんどんあると思うんだけど、うまく担保する仕組み
はないのかなぁ、とか。

coComment - clear conversation in the blogosphere
http://www.cocomment.com/

とか流行ってるので、ふと思いました。

[4] mixiユーザー 03月02日 20:07

closedなSNSと、publicなblogにまたがる議論とは厄介ですね。
興味ある方は両方に参加するだろうし、
本人は興味なくても重要な人は招待すべきだろうし、
本当に重要な話は、publicな方にコピペする人が現れるだろうし、
その内容を本当に保証したいなら、(中野さんのおっしゃる)公証役場的な機関が必要になるでしょうし。

そういえばmixiにはtrackbackがないので、
blog世界と対等に渡り合う存在ではない、
と私は認識しています。

[5] mixiユーザー 03月02日 20:13

>まったく話それますが、こういう議論、開かれたBlogosphere
>と、閉じたSNSをまたがって議論や雑談が続くことって、これ
>からはどんどんあると思うんだけど、うまく担保する仕組み

そこで、まとめWikiみたいのが役立つのかなあと思います。

[6] mixiユーザー 03月02日 20:32

> (中野さんのおっしゃる)公証役場的な機関

これはちょっと見当違いでしたね。すんません

coCommentとは
　blogosphere上の複数のblogで、
　trackbackコメントという形で行われる分散的な議論を
　まとめあげて一つのビュー(ページ)として示す
　blogコメントまとめサービス

という解釈でよろしいでしょうか？>>中野さま

[7] mixiユーザー 03月02日 20:59

です。

coComment以外にも、2.0系のそういうサービスが最近あれこれ
出てきているような印象があります。

[8] mixiユーザー 03月02日 22:09

ふむふむ。

あ、kara_dさん指摘の「まとめWiki」の存在を忘れてました。

[9] mixiユーザー 03月02日 22:13

mixi内Mashup、アリかも、と思ったんですが、昨日今日と
Yahoo!360°と行ったりきたりしてみて、

-Remix/Mashup以前に、そもそもmixiは検索系が貧弱。
マイミク、参加コミュ、自分の過去の日記にたどり着くのが
えらく大変。
-いろんなアイテムにTaggingできたら便利だなー。
Y!は一部やってるし、コミュでもやるよって宣言してるし。

ってとこですかね。

ソーシャルデータベースって情報にまともにアクセスできて
こそだと思うんですが、今のmixiの使い勝手はYahoo!ディレ
クトリしかなかった頃のWebみたいです。

//ってまた話それましたか…。

[10] mixiユーザー 03月02日 22:40

とりあえず、ここは雑談トピという認識でよろしいでしょうか？

>>中野さま

そこでgoo!が大活躍・・・かもしれませんね。
私はgooマーケティングディレクターの方がblogに書いていた
「mixiはユーザが、マイミクやコミュを増やすと、その管理に破綻する」
という意見に同意です。
その解決には、ユーザがマイミクやコミュの情報を管理したり
閲覧をやりやすくする仕組みの強化：
たとえば
　- 一覧性の確保/グループ化/階層化
　- プライベートなコメント付加
　- 重要度による重み付け
　- 情報フィルタリング/情報自動分類/ダイジェスト表示
等が必要かと思っています。

gooのコアコンピタンスである検索技術との関係は・・・うーん(笑
マイミクやコミュニティとのコミュニケーション記録(足跡やコメント等)
をデータマイニングして、ユーザに情報提供したり、消費者動向データ
として外部に売るのかな（汗
うん、SNSをビジネスに結びつけるにはきっとそれが重要だ(汗

話を元に戻しまして、外部API/内部APIの件。
ネタ元の｢外部API｣とは、mixiが外部サイトと協調する仕組みのこと、
nara_dさんのおっしゃる｢内部API｣は、mixiが外部サイトを勝手に呼び出す仕組みのこと
だと理解しました。
ただ、外部サイトとの協調関係構築や、mixiの機能追加には時間がかかるので、
mixiと外部サイトの連携を、サードパーティの専用ブラウザ上で行う方が手っ取り早いかな、というのが私の意見です。

(ご存知の事と思いますが)現状では、

・mixiにログインした人が使える｢API｣としては
　PerlのWWW::Mixiモジュール (いわゆるRobotUA)
　　http://digit.que.ne.jp/work/index.cgi?Perl%e3%83%a2%e3%82%b8%e3%83%a5%e3%83%bc%e3%83%ab%2fWWW%3a%3aMixi
　　関連コミュ⇒ http://mixi.jp/view_community.pl?id=43735

・画面書き換えをする機構としては
　Mozilla Firefox上のGreaseMonky
　　http://firefox.geckodev.org/index.php?Greasemonkey
　　関連コミュ⇒ http://mixi.jp/view_community.pl?id=21033

が、それに近い役割を果たしています。

ビジネスをするには、信頼のおけるAPIが必須ですが、
それ以前に、現状使えるものを使って、
具体的な応用サービスの試作/試行を進める事が
重要なんじゃないかなぁ、と私は考えています。

[11] mixiユーザー 03月02日 22:46

ネタ元のかなださんの登場を待ちましょう。(名指し

[12] mixiユーザー 03月02日 23:22

ちょっとだけ補足

> マイミク、参加コミュ、自分の過去の日記にたどり着くのが
> えらく大変。

とりあえずこの部分は、検索というよりデザイン上の問題かと。
で。
この課題は、Mixi ExplorerというPC上の専用ブラウザが、
サイドバーのツリー表示で、とりあえず解決しています。
(mixiの度重なる変更で、メンバー表示や情報更新が機能しませんけど)

[13] mixiユーザー 03月02日 23:34

> とりあえずこの部分は、検索というよりデザイン上の問題かと。

いや、ぼくもWeb屋なので一応マジレスしておきますが、
「デザイン上」の問題ではないと思います。

仮にUIを今以上にうまく設計しても、100件を超えるデータ
に時系列やら運営側が決めたルールでの配列に従ってブラ
ウズして辿り着け、ってのは情報デザイン上(ピー・自主
規制)です。B'(
//特に参加コミュ。

もちろんmixiだって機能を追加することと、サーバなどに
かかる負荷をトレードオフしてるんであろうことは推測でき
ますけど。

例示されているような追加ツールを使って補うというのは
アリですが、それは主にリテラシーの高いユーザーができる
という話ですね。

[14] mixiユーザー 03月03日 00:41

>｢内部API｣は、mixiが外部サイトを勝手に呼び出す仕組みのこと
>だと理解しました。

僕がいってた｢内部API｣は、Mixi内部にいるときだけMixi内部の情報にアクセスできる関数的なものです。日記やコミュニティの書き込み、プロフィール欄といったMixi内フォームなどから使うことが出来ます。
これと外部のAPIを組み合わせて何が出来るかというと、先にあげられていたWWW::Mixiモジュールでできることとほぼかぶりな感じがしてるのですが、もっと気楽に利用できます。

特定のキーワードに沿って、自分の友達だけのレビューとAmazon内のレビューを同時に引っ張ってくることとかがこれで出来たりとか。AmazonのAPIがレビューを引っ張るのができたかどうかは調べてませんが。

で、重要なのは、これがコピペで他の人も自分のプロフィールに追加したり（もちろん、自分の友達と他人の友達では内容が変わるので同じ表示にはならない）、改造してへんてこなものを配ったり出来るという点で、Mixi事務局は内部と外部のAPIさえ用意しておけば、どんどんMixi内で局所的な機能変更が起きるのかなと。

[15] mixiユーザー 03月03日 00:46

> それは主にリテラシーの高いユーザー

いちおう自己認識としては私も
Webコンピューティング分野の(略

それはさておき、
このようなツール作ったり使ったりしてるのは、
やっぱWeb関連の(略

アクセシビリティの件は、
私の過去日記(2/18)に
「専用ブラウザが提供する～すべき機能」として
雑文メモを書いた所ですので、
もしよろしかったらご参照下さいませ

ＤＢ負荷の件は・・・うーむ。
現在のＤＢ性能が足りてないなら、
キャッシュ・ファイルでも作って、。。。

[16] mixiユーザー 03月03日 00:58

＞kara_dさん

面白いですね。
一様なソーシャルデータベースを元にしながら、自分専用の
カスタマイザビリティも備えてるってことだ!

＞chakiさん

「(略」ばかりでは言いたいことが(略
ちなみにぼくが指摘したのは「アクセシビリティ」の話では
ないですよ。

[17] mixiユーザー 03月03日 01:44

ごめんなさい。
かみ合った話をするのが難しそうですね。

Web2.0系コミュに、
URL貼っただけで、主旨説明や詳細説明が不充分なトピを
多数お立てになって居られたので、
逆に、コメントの行間や他人考えを、素早く洞察できる方かと
勘違いしてしまいました。

一応、(略)部分を補足しますと、

＞いちおう自己認識としては私も
＞ Webコンピューティング分野の
　最初期から最前線に居た人間ですので、
　ツールを作成/試行するようなWeb関連業種の人と、
　 mixiが想定する一般ユーザ層の乖離は理解できます。
　そして、mixiの場合は、技術的可能性の検討よりも、
　皆が利用可能なサービスの提供こそ重視されている
　という事もよく理解しています。)

となります。

また私が「アクセシビリティ」と言っているのは、
以下のコメント部分のことです。

> 仮にUIを今以上にうまく設計しても、100件を超えるデータ
> に時系列やら運営側が決めたルールでの配列に従ってブラ
> ウズして辿り着け、ってのは情報デザイン上(ピー・自主
> 規制)です。B'(

その原因に「ＤＢ負荷」の考慮があるだろう、とおっしゃるのであれば、
確かにその可能性もあると思います。

ちなみに、Mixi Explorerのツリー表示では、
マイミクやコミュや、その下のトピが何百件あろうと、
ツリーのノードを一つ開くと
そのノードに対応する一件分のデータを
on demandで一回取得するだけです。(更新データ取得は不明)

mixiの通常のインタフェースでは、ある一つの操作のために、
同じようなページを何度も行ったり来たりする必要がある点を考慮すると、
ツリー表示にしたからといってＤＢ負荷が極端に高まるとは考えにくいです。

(もっとも、アクセシビリティが向上することで、
１ユーザあたりのアクセス数が増える可能性はありますが)

[18] mixiユーザー 03月03日 01:47

Webコンピューティング分野の最初期から最前線にいらっしゃ
った方に対して失礼をしました。

UIや機能設計のことを「デザイン上の」と指摘されたので、
「デザインじゃないよユーザビリティの話だよ」と反射して
しまいましたね。

あと、後半で展開されているMixi Explorerの話ですが、
膨大なユーザー数になり、かつソーシャルデータベースと
しての価値も高まったmixiで、Remix/Mashupといったいわば
付加価値強化の方向でなく、基本的なUIの改善なども、サー
ドパーティ製のツールを積極的に使うべきだという考えです
か?
それともやむを得ないから、ということですか?

[19] mixiユーザー 03月03日 15:38

ネタ元のかなだです(のこのこと登場)。

まず「API」って言葉が抽象すぎたなあと反省。僕が書いている「外部API」とは、Flickrの認証APIと同じようなものと思って下さい。

例えばmixiサーバ、mixi会員UA、第三者サーバの三つ巴の形になっていて、第三者サーバが何らかのサービスを行っている場合、mixiサーバと第三者サーバの間にどのような仕組みを作ればお互いにremix/mashupが可能か、という考察です。

1: kara_dさんの「内部API」というのは日記内に記述するマクロ言語のようなイメージでしょうか。これは実現すると面白そうですね。

「mixi内から外部のAPIを呼び出す」というのは、ネタ元にも書きましたが、今mixiが持っている「日記を外部blogに置換できる」機能がまさにそれなんですよね。でもあまり面白い化学変化が起きないのは、mixiが一方的に外部blogを叩いているだけで、mixiから外部blogにはほとんど何の情報も渡らないからだと思います。他にもプロフィールをFOAFに置換したり、レビューをsocialtunesに置換したりとか可能性としてはあるのですが、それでmixiや外部サイトが面白くなるかと言われれば疑問です。

2: chakiさんの方法は寡聞ゆえうまく理解できませんでした。外部Webサーバというのと外部サービスというのは別個のものでしょうか？また外部Webサーバとmixiはどういった情報のやりとりをするんでしょう。

10: chakiさん。WWW::Mixiは僕も便利に使っています。しかしmashupとなるとユーザーIDとパスワードが必要な点がネックになってますね。mashupを考える場合、マイミクマップのようにユーザーIDとパスワードを毎回受け取る(性善説を前提)か、第三者サーバがmixiのIDとパスワードを管理する(さすがに怖すぎる)しかない点が障壁になっています。クライアントが画面を書き換える手法については面白そうなので可能性を考えてみます。

本論と関係ないところだと、日記やコミュニティの管理が不便、というのは僕も感じています。ではなぜ不便な日記やコミュニティをユーザーが我慢して使っているのかと言えば、その不便な日記やコミュニティに「個人情報とその繋がり」という巨大な付加価値がぶら下がってるからだ、という元ネタの話に戻るわけです。

Mixi Explorerというのは使ったことがないですが、あるコミュニティが「不便なUI・有意な情報」というジレンマに陥った場合、ユーザーが勝手にUAを作りあげ、コミュニティが運用者の意図しない方向に向かうというのは、古くはNiftyServeとか最近では2chなどで見られてきた現象ですね。

15, 17: chakiさん、失礼ですが「アクセシビリティ」ではなく「ユーザビリティ」ではないですか？

[20] mixiユーザー 03月03日 19:38

> 2: chakiさんの方法は寡聞ゆえうまく理解できませんでした。
> 外部Webサーバというのと外部サービスというのは別個のものでしょうか？
> また外部Webサーバとmixiはどういった情報のやりとりをするんでしょう。

ここでわたくしが言う外部Webサーバとは、
　・古くは電総研のdelegateサーバ
　・新しくはモバイルmixi のように、
ユーザUA と目的サーバ(mixi) の間にproxy として入って、
　・両者の通信を仲介する
とともに、付加価値として
　・情報やページの適切な変換、編集、集約や要約
　　　(例えばコンテンツを携帯電話向けに変換したり、
　　　　主要な情報を１ページに編集しなおしたり、
　　　　ISBN番号をamazon.co.jpへのリンクに書き換える)
　・そして外部サービス呼出
　　　(例えばコミュのイベント開催通知で場所を指定すると、
　　　地図や交通手段、周辺店舗情報を取得して、
　　　最終的にページ上に画像や追加テキストとして表示する)
を行うものです。

　　　　　　　　　　　　[外部Webサーバ]
ユーザUA　　←→　　･専用ﾌﾞﾗｳｻﾞ　　　　　　　　←→ 　[mixi]
　　　　　　　　　　　　 (・RSSﾘｰﾀﾞ)　　　　　　　　　←→ 　[blog]
　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　↓↑

　　　　　　　　　　　　外部サービス

これは、仲介者パターンと言うような名前で、
ビジネスモデルの世界でよく知られているものだと思います。

>　「アクセシビリティ」ではなく「ユーザビリティ」

はい、ユーザビリティです (汗

[21] mixiユーザー 03月03日 19:50

> あるコミュニティが「不便なUI・有意な情報」というジレンマに陥った場合、
> ユーザーが勝手にUAを作りあげ、
> コミュニティが運用者の意図しない方向に向かうというのは、
> 古くはNiftyServeとか最近では2chなどで見られてきた現象ですね。

それは、mixi運営者との利害関係次第だと思います。mixi運営者とユーザの間で、目的が共有できていて、かつその目的への到達が早ければいいのですが、そうでない場合は、なんらかの試作/試行を以って説得材料にする必要がある、と認識します。

[22] mixiユーザー 03月04日 13:46

> 10: chakiさん。WWW::Mixiは僕も便利に使っています。
> しかしmashupとなるとユーザーIDとパスワードが必要な点が
> ネックになってますね。mashupを考える場合、
> マイミクマップのようにユーザーIDとパスワードを毎回受け取る(性善説を前提)か、
> 第三者サーバがmixiのIDとパスワードを管理する(さすがに怖すぎる)
> しかない点が障壁になっています。

このトピのお話の主旨、MACHUさんのblogを拝見して、
ようやく理解いたしました。

[解決すべき問題]
　SNSｰ外部サービス間連携で、外部サービスからSNSを呼び出せるようにしたい。
　ただしSNSのID/パスワードを、外部サービスや仲介サーバに委ねることのない、
　安全な認証システムを構築したい。

[解決方法]
　SNS側に「委任状の発行/受入の仕組み」の設置をしてもらう。
　ここで「委任状」とは、ユーザの事前許可に基づき、
　個別のSNS資源への(通常一回限りの)アクセスを許可するような、
　引換券としてのトークン文字列を指す。

　ユーザが、外部サービス上の文章や写真といったオブジェクトに、
　SNSサービスを関連付けたい時は
　SNSの委任状を発行し、オブジェクトにタグ付けする
　(トークン文字列を埋め込む)

　外部サービス側は、
　(1)オブジェクトへのタグ付けのサポート
　　 (ユーザによるSNS委任状発行～トークン文字列埋め込み)
　(2)オブジェクト中のタグの検出と、SNSサービス呼出
　をする

そしてストーリーとしては、
SNS側にこの委任状システムを追加設置さえしてもらえれば、
あとは外部サービス側がなんとでもしますよ
(SNSソーシャルベースの有効活用を進めますよ)
という流れなのですね。

[23] mixiユーザー 03月09日 17:57

20: chakiさん
> ・新しくはモバイルmixi のように、

モバイルmixiはmixi.jpの管轄ですよね。サーバー構成も(www.)mixi.jpのproxyではなくて、同じDBを叩く別サーバなんじゃないでしょうか。

このモバイルmixiと「非公式mixiモバイル」(こっちは外部かつゲートウェイ的)を比べると認証の問題の根深さが分かると思います。後者はユーザーIDとパスワードの認証を仲介した上、何らかの方法(おそらくmixiが発行したCookieの保存)でmixiの認証情報をサーバー上に保持し、これをURLに埋めたセッションIDと関連付けているようで、お世辞にも安全な実装とは言えません。(他にもセキュリティ的にツッコミ所満載なのですが主旨から外れるので自粛)当然個人情報もこのサーバを通過します。

> [解決すべき問題] [解決方法]
元ネタに書いたように、この問題はFlickr方式辺りでクリア可能だと考えています。主旨はそこではなくて、

> SNS側にこの委任状システムを追加設置さえしてもらえれば、
> あとは外部サービス側がなんとでもしますよ

で済むような話だと思いがちだけど、外部サービスを個人情報が通過する以上、閉鎖系コミュニティであるmixiでは実現は難しいだろう、という話です(元ネタにもそう書いたつもりなんですが)。

[24] mixiユーザー 03月09日 21:10

> モバイルmixiはmixi.jpの管轄ですよね。サーバー構成も(www.)mixi.jpのproxyではなくて、同じDBを叩く別サーバなんじゃないでしょうか。

はい、「非公式mixiモバイル」の間違いです(汗。
話の流れ上、サービス連携で何ができるのか、イメージを膨らませやすいようにシンプルな例を書きました。そして私の主旨は、パーソナルなサーバ上でどんどんweb2.0的サービス連携を実験して、その可能性や課題を見極めましょう、という点にあります。
商業レベルのサービスでは、安全な認証方法や、ソーシャル情報公開ポリシーが重要な課題であり、そのための情報収集や検討は欠かせないでしょう。でも、結論が出て一般に利用可能になるまでには、時間がかかるだろうと思います。

> 外部サービスを個人情報が通過する以上、閉鎖系コミュニティであるmixiでは実現は難しいだろう

そうですね。実は私もかなださんと同様、ちょっと悲観的です。

【現状】
1. 現在、閉鎖系SNS(mixi)上に膨大なユーザとコミュニティがある
2. 他方、｢web2.0的｣と総称される(たぶん)オープンな情報流通に基盤を置いたサービスが次々と立ち上がっている。この潮流はユーザ的にもビジネス的にも無視できない。
3. 現在の閉鎖系SNSのソーシャル情報管理ポリシーは、web2.0的開放系サービスへの対応(ソーシャル情報の流通)を考慮していない。

でも、それを言ってしまうと本コミュニティの存在意義が(略・・・参加した意義が(略
というか、本コミュニティのタイトル「mixi2.0: mixi×Web2.0」が投げかける問題への解答が、｢実現が難しい｣の一言では寂しい感じがします。

どなたか、｢実現が難しい｣理由を考えて頂けませんか？

[25] mixiユーザー 03月10日 17:33

> パーソナルなサーバ上でどんどんweb2.0的サービス連携を実験
> して、その可能性や課題を見極めましょう、という点にあります。

実際色んな試みが行われていると思うんですが、認証や個人情報の問題でつまづいている部分は多いと思うんですよね。僕も以前keyword cloudを作った時に、その制約をうまくクリアできなかった経験があります。「非公式mixiモバイル」の実装は個人的には怖すぎて推奨できません(たとえ実験だとしても)。

> でも、それを言ってしまうと本コミュニティの存在意義が(略
> 「mixi2.0: mixi×Web2.0」が投げかける問題への解答が、
> ｢実現が難しい｣の一言では寂しい感じがします。

僕が「難しい」といったのはremix/mashup可能かどうか(以下、Tim氏に倣ってremixabilityと表記)であって、これはWeb 2.0の重要なポイントではありますが、Web 2.0の必須条件ではないと思いますよ。

例えばWikipediaはTim氏がWeb 2.0の典型例として名指ししてますが、remixabilityはmixiと同程度に低いと思います(せいぜいデータのダンプができる程度)。

……ともあれ、僕がコミュニティの議題を否定したと解釈されたのであればそれは誤解です。

評判に反して、実際にはmixiはWeb 2.0を意識して開発に尽力しているように思います。内部からはblogやニュース、amazon(レビュー機能)などとremixを行っていますし、「Users Add Value」はmixiそのものと言えます。携帯電話対応も謳っていますし、何よりロゴにはいまだに「β版」と描かれています(笑)

それでもなお、mixiがWeb 2.0的に見えないのは、一重にmixiが「純粋な閉鎖系」であるからでしょうね。

で、「閉鎖系」とremixabilityの両立は不可能ではないと思っているので色々と可能性を探ってみたいと思います(幾つかアイデアはあるのでまとまったらここか元ネタのblogの方に書こうかと思います)。

> どなたか、｢実現が難しい｣理由を考えて頂けませんか？

僕自身の考え方は元ネタの方に書いてありますが、分かり難かったでしょうか……？

[26] mixiユーザー 03月30日 00:20

ご自身が「ぐだぐだな文章」と仰っているblogの解釈論に
時間を費やすのは、非常に非生産的な行為だと感じ、
これまで御返答をためらっておりました。
(たしかに世の中には、その種の議論展開で煙に巻かれてしまう
　議論能力の低い方も多数居ますけどね:-p)

結局、通常の議論方法でいくら言葉を尽くしても、
なんら有意義な議論を進めたくないようにいらっしゃる。
オープンな議論を旨とする私のポリシーからすると、
現状は非常に心苦しいものです。
そこで、私が上記について考えたブレーンストーミング・メモを掲載させて頂き、この件のとりあえずの〆とさせて頂きます。

---------------------------------------------------------
トピの流れを、建設的な方向へと変えるための
　　　　　ブレインストーミング・メモ

o 自分の前レスのしめくくりがマズかった件：
　× どなたか、｢実現が難しい｣理由を考えて頂けませんか？
　◎ 他の方の意見が気になります。
　　どなたか、｢～の実現は難しい、しかし不可能ではない｣
　　という例を考えてみませんか？

o かてなさんのblogから読み取れる
　｢mixiが web2.0(の一例である remix/mashup )の『実現が難しい』｣理由：
　・mixiの成立基盤は『個人情報一元管理への信頼』にある。
　・remix/mashupでは、
　　(多かれ少なかれ)サイト間で個人情報のやり取りをする(事が多い)。
　・前者と後者は相容れない。つまり個人情報一元管理が崩れる。
　・web2.0全般ではなく、remix/mashupに限定した話である。

　・「閉鎖系」と remix/mashup の両立を検討している。(今回コメント)

　※1～3番目は、前コメントに【現状】としてまとめたつもり(汗)
　　自分自身が再確認しておくべき事柄：
　　・｢個人情報一元管理への信頼｣は、
　　　閉鎖系SNS共通の成立基盤であること
　　・mixiに人が集まった理由(mixiの成立基盤)は、
　　　他にもあること
　　　- 一般ユーザが馴染みやすいシンプルさ
　　　- 優良な初期ユーザの獲得
　　　etc.

o ｢『非公式mixiモバイル』のセキュリティが杜撰なので、
　目的を問わずproxy方式全般が駄目」、
　という印象を持つのは、行き過ぎだと思う。

o セキュリティの件は、最初から逃げ手を打っている(汗)
　「セキュリティ (や情報公開ポリシー)の件は、
　　商用サービスを実現する上で不可欠。
　　(同様に『収益モデル』も重要)
　　ただしmixiが提供するのには時間がかかるだろうから」(以下略)

o コミュのトピックとして、blog執筆者ご本人がblogで
　｢ぐだぐだと書いてしまった｣と言っている文章の
　解釈やら、真意を読み取れた/読み取れていない　という話
　を続けるのは不毛。コメントを書きにくい。
　(そして、そういう流れにしてしまった原因は自分にある)
　流れを変えるコメントの登場を期待。

o 課題：web2.0 remix/mashupについて、
　・分散オブジェクトやwebサービスのサービス合成
　・ポータルサイトやportlet技術が提供する情報集約
　との共通点/相違点(ユーザ参加etc.)　を確認しておく。
---------------------------------------------------------

今後このコミュニティで、
オープンで誠意ある議論が活発に行われる事を、
心から願って止みません。

ログインすると、みんなのコメントがもっと見れるよ