さすがあっちゃん、人気ある……。
QT: [https://dtp-mstdn.jp/@noellabo/102638488079176714]
さすがあっちゃん、人気ある……。
QT: [https://dtp-mstdn.jp/@noellabo/102638488079176714]
このアカウントは、notestockで公開設定になっていません。
なお https://fedibird.com は、私が新設した、LTLのないFediverse志向の汎用Mastodonサーバです。
Fediverse技術の実験場でもあり、最新のMastodon本体の機能や、独自仕様の提案・実験の場ともなっています。
HTL運用、リスト運用、ハッシュタグ運用に向いている他、予備アカウント置き場、テストにも向いていると思います。
コミュニティ色の極めて薄いサーバになりますので、コミュニティ疲れした方や、そういう場所の方が好ましい、企業アカウント、広報アカウントにも向いているかもしれません。
現在、既に稼働しており、ユーザー登録を受け付けています。
……登録していただいてもLTLがないのでお互い全然わからないんですがw、そういうところも含めて楽しめる段階ですので、興味のある方は遊びに来て下さい。
#fedibird
MastodonやFediverseのアレコレを語るアカウントを、DTP鯖のアカウントから分離することにしました。
こちらは、DTP関連、DTP鯖に関する活動、同人、カレー、その他の個人活動に引き続き使用していきます。
鯖缶・開発者向けMastodon情報などのうち、重要なものはこちらでもブーストしますが、基本的には @noellabo へ移行しますので、フォローされている方はご留意ください。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
勝手に作った #WaifuLabs クライアントがいい感じになってきたんだけど、勝手に公開するのもなあ…。どうしようかな。履歴を無制限にさかのぼって、好きな位置で好きな種類のバリエーションを生成できる。候補の一括保存も一応ある。試してみたい人いたらDMくださ
MastodonやFediverseのアレコレを語るアカウントを、DTP鯖のアカウントから分離することにしました。
こちらは、DTP関連、DTP鯖に関する活動、同人、カレー、その他の個人活動に引き続き使用していきます。
鯖缶・開発者向けMastodon情報などのうち、重要なものはこちらでもブーストしますが、基本的には @noellabo へ移行しますので、フォローされている方はご留意ください。
このアカウントは、notestockで公開設定になっていません。
Mastodon、WebPの対応が不完全であったため、機能が一旦削除されるようです。Remove WebP support · Issue #11589 · tootsuite/mastodon · GitHub https://github.com/tootsuite/mastodon/pull/11589
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ざぼてくは生き残ると言うが、よそ様のリソースを間借りしてる以上はタグごと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
@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
このアカウントは、notestockで公開設定になっていません。
分散SNSでユーザーが特定のサーバに縛り付けられる要因としては、
ソフト(人間)の面ではLTLなどのコミュニティの繋がりがある。
ソフト(技術)の面では、署名と、UID、到達性の問題がある。
・個人の秘密鍵をサーバが預かっており、新しい鍵との交換をサーバに依存せずに実行する手段が確立されていない
・Actor、ActivityのユニークIDが、サーバのドメインに依存している
・オブジェクトのURI、inbox、outboxなどの重要なエンドポイントが、サーバのドメインに依存している
LTLなどのコミュニティについては、サーバから分離するスタイルが一般化することで解消できる可能性がある。
ハッシュタグタイムラインとリレーなどの手段があるが、ハッシュタグは中央管理されないので管理が不可能である。
Group Actorを活用した管理可能で連合するコミュニティが期待されるところである。
技術面では、個人が個々にドメインを保有し、サーバがそれを預かって運用するスタイルが一般化することで、解消が可能と期待されるところである。 #distsns #fediverse