Keᷟiͣzᷤoͭuͦ@6ͩ4ͦ0ᷠ0 @keizou@mstdn.guru

正月の暇つぶしにしよう

むしろボクの高校生時代の冬の季節はスチーム暖房器の間にレトルトカレーやシチューなどのパックを挟んておいて昼にアツアツのモノを食うのが当たり前だったｗ

更にボクがPC用のファンを使って温風式ヒートファンを開発すると白飯も温められるという技術的進歩が起きたｗ

更にそこから同級生が水へ浮かびモーターで前進する潜水艦模型を改造し温水式循環ヒートパックを発明ｗ

ヒートファン方式はほんのり温かだったけれど、ヒートパック方式は白飯もアツアツになる大発明だったｗ

https://mstdn.guru/@furoneko/103385347016794527

あけおめ予約投稿を使ってみたけれど、Subway Tooterの時刻指定の振る舞いは思想がわかれる感じだよねぇ

こういう振る舞いするのは非常に理解できる、理解できるが誤入力する人は絶対に居る

何が正しい振る舞いというのが全くないので難しい

#subwaytooter

我が家センター受け取りにしてる

これ親父がやっていた技をそのまま継承したｗ

実家が自営業なのでボクが受け取ってしまう可能性がままあり、編み出した技らしいｗ

https://mstdn.guru/@trigon/103367551894904160

コミュニティに属さないチャットルームを追加してみた

Matrixの面白いところは、所属しているMatrix
サーバがAであろうがBであろうが、この画像にある全てのroomに参加できるという点だね

コミュニティはSlackやDiscordへログインした際に表示されている既設のチャンネルを一覧化する機能だと思えば良い

つまりコミュニティへ参加するとSlackやDiscordのように様々なチャンネルを一度に知ることができるというわけだ

そしてコミュニティは非公開にすることが可能というのも面白い

これまでのコラボレーション系チャットは組織外の人を招待するのはちょっと面倒だったし、Slackなどはその辺をなんとかしようと頑張って居るけれど、Matrixはそもそもの仕組みとして組織外の人を呼びやすい仕様になっているんだね

Matrixクライアント「Riot」のブログを漁っていたらビデオチャットについて書かれている記事を発見した

https://medium.com/@RiotChat/riot-im-web-0-12-7c4ea84b180a

ウィジェットとして表示するらしいので、つまりJitsiのビデオ・ボイスチャットルームがRiotのroomとして表示されるわけではないっぽい？

柔軟なコミュニティ機能があるらしい

https://medium.com/@RiotChat/communities-aka-groups-are-here-announcing-riot-web-0-13-riot-ios-0-6-and-riot-android-0-7-4-933cb193a28e

理解が間違っていなければ掲載画像のような感じ

Matrixは他のMatrixサーバへ所属しているユーザを自Matrixサーバのチャットルームへ招待できるのだけれど、Discordのようなコミュニティ下位へチャットルームを設置することもできるということらしい

こともできる、なのでコミュニティへ所属しないチャットルームも作成できる

う〜ん・・・なるほど面白い

よくよく考えたら検索エンジンの実装の方式によっては過去に起きていた検索エンジンクローラによるサーバへの負荷が再燃するから、小規模サーバの多いFediverseではあまりにも高性能すぎる検索エンジン作られても結構困っちゃうことになるんだよなぁ

Tootdonのこともあって現状考えうる検索エンジンってだいたい画像みたいな感じ(わかりやすくするため細かいとこ省いてる)

重要なのは検索DB内へ保存されてるデータが現在でも存在するかどうかを確認する問い合わせbot

これ検索リクエストがある度に走らせるのが理想なんだけど、つまりその度に分散SNSサーバへ負荷が掛かるということなので、高性能な検索エンジンで人気出ちゃったら分散SNSサーバ管理者が涙目になる可能性が高い

結局のところトゥートの検索ってどうなったの2019 | Cutls Code Archives https://code.cutls.com/toots-search-2019/

ピカール

こんな変態端末作ってみたい

クラムシェル型曲がるディスプレイでハードウェアキーボード付スマートフォン

Twitterが考えている分散化とはたぶん木構造的なSNS分散化

「この構造だとサードパーティサーバにはメリット無いのでは？」と思うかも知れないけど、おそらくはサードパーティサーバではUser Streams APIが使える、クライアントアプリの制限がないみたいな施策を打ってくると思う

負荷の高いAPIはそれぞれのサードパーティサーバが負担すると良いみたいな考え方で分散化するのではなかろうか

ボクたちが考えるSNS分散化ってメッシュ構造なので「中央集権SNSの負荷を分散させただけ」という評価を受けてしまうのではないかな

絵心と製図能力は違うんだと力説したい

嫁も「立体図のクオリティはめちゃくちゃ高いのに絵心ないの本当に謎すぎる」っていつも言うｗ

絵心ないのにこういうのはサッと描ける理工系あるあるｗ

絵心が行方不明

お昼にも投稿した分散SNSでWebTorrentなどP2Pシステムを活用する方法について、誤りを直したり色を変更して少し見やすいようにした

早い話が下記の通り

1. ユーザが分散SNSサーバへ投稿したテキスト情報は一定時間単位でアーカイブ化されtorrentファイルが生成される

2. テキストアーカイブシードはそれぞれの分散SNSサーバで独立して持ちFediverseで共有されない

3. ユーザは所属する分散SNSサーバのテキストアーカイブtorrentファイルを共有する

4. 投稿に含まれるメディア情報のアーカイブ化はせず、それぞれのメディア単位でtorrentファイルを生成する

おそらくこういうシステムならばお一人様分散SNSサーバでもメディアの送受信による負担が非常に減るであろうし、ユーザ数の多い分散SNSサーバほどテキスト情報をも含んだ送受信量が減る

DMとかどうすんの？という疑問もあるだろうけど、DMなどはDMユーザ間専用のテキストアーカイブtorrentファイルを生成すると良いと思う

これ以上ないってレベルでWebTorrentを分散SNSで活用する方法を解決した

あとは法的な問題を解決するだけ