のえる DTP鯖管 @[email protected]

ざぼてくは生き残ると言うが、よそ様のリソースを間借りしてる以上はタグごとBANされても文句は言えず、引っ越すしかないやつだ

LTLにプッシュする権利とサーバのポリシーに同意する義務が天秤に掛けられてるが、運営的には仕方ないところか。サーバ運営は発信する内容に責任がある

公開TLがソーシャルグラフの一種ならば、サーバのポリシーが癒着してるからダメか？ということもない。なぜなら公開TLはログインしなくても見れる。自分が使いたいサーバと違うサーバの公開TLを快適に読めて反応を返せればOK。
問題は公式WebUIがそれをサポートしてないこと。

SNSの定義はソーシャルグラフを作れて外部から観測できること。流れてる内容は一文字でもYo!でもよい。
分散する目的は非中央集権化のためで、粒度は別に問われない。あるサーバのポリシーが気に入らなければ別のサーバを建てて、既存のユーザと交流し続けられる選択肢があるのが大事。
公開TLはソーシャルグラフの一種と見なせるので、あってもなくてもよい。というかスコッピングの観点からはむしろないと不便。

ツリー型の情報管理ツールと、階層のないPukiwikiが、という話もありますが、語らなくても想像できると思いますので省略します。

そういう諸々の経験から、仕組み作り込んでメリット考えても空回りするときはするし、

人々が自発的に楽しみながら使えて、それが何かを生み出すところにフォーカスして、それに従った仕組みを作った方がいいんだなということを学びました。

ディレクトリ型インデックスより、クロール型のgoogleの方が優れた助けになったということもあります。

多様性とノイズの中で、混沌の中で、価値が生まれるというワケです。

綺麗に正規化した構造もまた大事なんですが、これは人間が直接触るんじゃなくて、裏方で使うと活きてくるという知見も得ました。

あと、草の根BBSで個人的に経験したことも記載しておきます。

KTBBSと、mmmという、どちらもよく使われたシステムがあるんですが、対照的なところがあって、

KTBBSは、いわゆるLTLのように同じ場所に無限に書き込んで、レスじゃなくてエアリプで会話していました。

掲示板なんで、マイクロブログみたいに短い投稿だけでなく、長いメッセージもありましたが、とにかくなんでも一緒に流していくスタイルです。

ちょっと前の人の感覚だと2chですね。

mmmは、しっかりジャンル・目的毎に階層分けされていて、話題によって書く場所を綺麗にわけていました。それぞれに管理者・モデレーターを置いたりしてね。

レスポンスツリー（どこに返信を付けるかを意識）も綺麗に構築するタイプでした。

まぁ、なんでも書き込むところもあったりしましたがw

このへんはネットニュースの流れです。

だいたい、KTBBSの方が熱気があって流行りました。mmmの方が落ち着いて話せるんですが、ちょっとかしこまるんですね。

私はmmm系のMASHでしたが、良いと思ったけど、うまくいかないなぁという経験をしました。

パソコン通信からmixiまでの空白の時間は、今の状況を考える時に、大いに参考になっています。

パソコン通信は、大手と、草の根BBS（個人運営の小規模局）にわかれます。

大手BBSは、端的に言うと、いまあるものはほとんど何でもありました。

草の根BBSは、基本的にホスト局の外と繋がる方法がなかったので、LTL中心のサーバみたいなものでした。当時の通信につかわれていた電話＋モデムでの接続は距離と時間で料金が決まるため、物理距離の問題があり、近隣地域だけで人が集まっていました。地域サーバですね。

そうしたものが一回なくなって、インターネットに移行したら、不便すぎて、人々は繋がる方法を探したり、同じ場所に登録することを好んで、（中略）mixiとかtwitterとかそういうのが大流行したというワケです。

例によってちょっと昔話をしますが、

パソコン通信と草の根BBSから急激にインターネットに移行した頃、コミュニティが消えてしまったことがあるんですよ。

World Wide Webってんで、個人でホームページを持って、世界と繋がれるっていうことで、皆で個人ページを作った。

お一人様に分散している状況に似ています。

（どこが同じで、どこが違うか、掘りさげると意味がでてきます）

つながりがなかったんで、相互リンクページを作った。フォローとフォロワーみたいなもんで、フォロー先を辿って、新しいページを見つけたわけです。

あと、CGIで掲示板を作った。個人ページのミニコミュニティです。

そのうち、Yahoo!などのディレクトリ登録して検索できるサービスが出てきた。ジャンルとページ名とURL、キーワードと説明のようなものが人力でまとめられていきました。

端折る。googleなどのクロール型の検索エンジンが出てきました。

登録するとランダムでリンク先に飛ぶのもありました。リング。ちょっと違うけどリレーに近いかな。

で、mixiのようなコミュニティが再登場します。

いまうまく運営されているサーバは、もちろんそのままの方針で運営した方がいいですよ。

中小企業とかそうですけど、そとからみたらメチャクチャな経営してるみたいに映るんですが、そういうの、変えた途端に死にます。

あと、どんなリスクが理論上は考えられるとしても、無用なこともあります。晩年になって好きな酒もタバコも禁止されて少しぐらい寿命が延びたとしても、本人幸せじゃないよね。環境を変えた方が寿命縮むよ。

そういうわけで、諸々検討したり話したりしていることというのは、上手くいっていない物事に対してだったり、これからに備えての話です。

サーバが増えることにより「分散」は達成しうるのかもしれないが、一方で「分散」を強いることは同時に「分断」をも強いていることを忘れてはいけないと思う
それぞれのサーバに醸成された文化が根付いている以上、サーバ内における価値観が外部の人間により否定されてはならない

@nieein56 コミュニティをサーバから分離するのは、分断のためではなくて、直交性のためです。

また、リモートから参加できるよう機能向上を意図する面もあります。

恐らくサーバと文化的に強く結びついたコミュニティの方がうまくいくと思います。

分離した上でセットで運用するのが良いと思います。

私もテーマサーバを運営しており、その方向で発展させたい意向です。

なぜサーバに縛られるという問題としての指摘をするかというと、概ねサーバの寿命の方がコミュニティやユーザーの活動よりも短命だということと、コミュニティやユーザーが追放され、独立を余儀なくされることがあるためです。

サーバがユーザーの生殺与奪を握って構わないのですが、同時にアイデンティティを喪失しないために、アカウントがポータブルであることが重要だと考えています。

繰り返しますが、ポータブルであることは重要ですが、どこかに帰属することが必要でして、サーバが人の集まりとしてある種の共同体（コミュニティ）であることは重要だと思います。

端的に言うと、私は分散過激派ではありませんw #distsns #fediverse

Understanding Decentralized IDs (DIDs) - Adam Powers - Medium
https://medium.com/@adam_14796/understanding-decentralized-ids-dids-839798b91809

Decentralized Identifiers (DIDs) v0.13
https://w3c-ccg.github.io/did-spec/
A Primer for Decentralized Identifiers
https://w3c-ccg.github.io/did-primer/

ユーザ ID がドメインや特定のオリジンサーバに依存してしまう点については、 decentralized identifier という規格が W3C によって提案されていて (勧告になるかはわからないけど)、そっち方面での技術的な解決も期待できますね #distsns

mastodonの立て方

1. 金を用意します
2. 立てられる人にお金を添えてお願いします（この際、お金に糸目をつけてはいけません）

おめでとう！鯖が立ったよ！

分散SNSでユーザーが特定のサーバに縛り付けられる要因としては、

ソフト（人間）の面ではLTLなどのコミュニティの繋がりがある。

ソフト（技術）の面では、署名と、UID、到達性の問題がある。

・個人の秘密鍵をサーバが預かっており、新しい鍵との交換をサーバに依存せずに実行する手段が確立されていない

・Actor、ActivityのユニークIDが、サーバのドメインに依存している

・オブジェクトのURI、inbox、outboxなどの重要なエンドポイントが、サーバのドメインに依存している

LTLなどのコミュニティについては、サーバから分離するスタイルが一般化することで解消できる可能性がある。

ハッシュタグタイムラインとリレーなどの手段があるが、ハッシュタグは中央管理されないので管理が不可能である。

Group Actorを活用した管理可能で連合するコミュニティが期待されるところである。

技術面では、個人が個々にドメインを保有し、サーバがそれを預かって運用するスタイルが一般化することで、解消が可能と期待されるところである。 #distsns #fediverse

Fediverseの特徴で、大事なことだと思うんだけど、

必ずオリジン（元の投稿）を参照することができて、投稿者も明確になっていて、ActivityPubを介して当人同士が直接リアクションできるというのがある。

キャッシュとしての複製は多数作られるし、削除が届かないこともあるけど、あくまでキャッシュとしての役割に徹している。

署名により、偽造が難しいようにも作られている。

Fediverseの外のコンテンツはActivityPubに対応していないから、この特徴を維持できない。

無理にFediverseに持ち込むと、持ち込んだトコロがオリジンになってしまう問題が発生し、オリジンとしての正当性がないから、内容が保証されないし、複数存在してしまう。そしてリアクションが届かない。

持ち込んだトコロが、得るべきでない情報や発生する利益を握ってしまう恐れがある。つまり、中央集権の問題が発生するのではないか。

Twitterについて言えば、なんらかの方法で、公式に、直接Fediverseのノードになってもらうしか道はないように思う。 #distsns #fediverse

It's kind of odd to read a blog post (rightfully) blasting the fedirchive guy but then recommending a Twitter mirror service that kind of does the same thing, is all

When you make a Twitter mirror service in the fediverse, do you consider that the mirrored accounts obscure their very real counterparts in search?

At the same time the copying of Twitter posts is essentially archiving without the author's explicit consent. It bothers me that there's like 4 such services out here and people keep making them

みんな、おしゃれの秘密教えてあげる

１：痩せろ
２：サイズにあった服を着ろ