しらなかった

このアカウントは、notestockで公開設定になっていません。

既に当初の予定より30分遅い出発となっており >合宿

合宿中のハッシュタグ何にしよう(授業名でもいいんだけど何かあったとき困りそう)

いや授業名もう投稿したことあるし手遅れだが

pͪoͣnͬpͣoͥnͭpͣa͡inͥ しなければ余裕をもって到着できそう #攻防2合宿

腹がｸﾞﾙｸﾞﾙ言ってるんだけどこわいので考えるのをやめた #攻防2合宿

空が真っ白で、これスカイボックス手抜きではwww と思って写真を撮ってみたら存外にディテールがあったので、視力はすべてを台無しにすることがわかった

迷惑にならないなら電車で何をしようが勝手だと思う(化粧だろうと何だろうと)

化粧が見苦しいという理由でアカンのなら、あわれ見苦しい中年男性は通勤に電車を使えないということになるんだけど、ああいった発言は一体どういうつもりなのか理解に苦しむ

本人にとっての衛生面がどうというのは全く別の話

いえこれは文脈に乗っかっただけで某氏に言ってるわけではない

私たまにこういうことをやるのでよくない

Happy Hacking KoffeeBoard

オタクに乳液のことがわかるものか(適当)

化粧をテーマにしたエロゲとかありそうだけどどうなんです？

化粧にやたら詳しいが知識の使いどころは全くないオタクが出来上がりそう(適当)

尿素の方がエロくないですか？

https://twitter.com/47news/status/1034247709438304257 #tw
草も生えないぞ……

このアカウントは、notestockで公開設定になっていません。

キーボード自作勢、キー配列も妙なの使ってる人多いのではと勝手に想像していたのだが、実はそうでもないのか

dvorak は妙なんかではない！

ﾃﾞｮｽｺｰﾄﾞにもちょっと書いたけど、原則として Mastodon 含め各アカウント(が所属するサーバ)はエンドツーエンド原則に則って動いており、これは分散システムとしては理に適っていると思うんですよ。
リレーサーバは(より正確には「リレーサーバのはたらきで構成される FTL の常用は」)、そのエンドツーエンド原則を崩すことになる。簡単に言えばちょっとした中央集権ですよね

分散は、「データの本来の発信者が、当人のサーバからそれを行う」こと、また「受信者がある情報を受けとるのに、発信者 (RT の場合は RT した人)のサーバと受信者のサーバのみが関与する」ことにより為されるわけですが、リレーサーバはこの中間に割り込んで通信を奪ってしまう

ﾃﾞｮｽｺｰﾄﾞではあまりネガティブなこと書けそうな雰囲気でないので「せめて特徴付けがあれば(テーマ別インスタンスよりは分散に貢献するだろう)」ということをやわらか～く書きましたが、しっかり主張するなら、リレー機能は分散システム中に集権の余地を作り出すよくないものだと考えています。(特に LTL/FTL 常用勢が多い状況では。)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

そもそもテーマ別リレーサーバ相当の機能は RT 多めのユーザとか特定の話題に敏感なユーザをいくらかフォローすることによって自動的に達成されるし、そっちが正解だと思う

@noellabo 賛否両論戦わせようぜ！ という激しい雰囲気でなかったので、まあ最初のうちはお互い様子見しつつ和やかにいった方が……みたいなことを思っていました(議論チャンネル的なものができたら面白そうとは思います)

まず原理から検討しているので、リレーの負荷については特に考えていない(分散を阻害しないと思えたか手元で試そうという気持ちになったら考える)

なんか分散 SNS の話題にハッシュタグ付けるべきな気がしてきた(自分でも過去の投稿を掘り出すのに完全に断片的記憶に頼っている)

雑に #distsns でいきます

#distsns

やはり啓蒙だ(短絡的)

いやでも実際啓蒙しないと「マストドンとは jp である」みたいな誤解から逃れられる人は多くないだろうからなぁ

ブログや SNS でチマチマやるんじゃなくて、ちゃんと web サイト作るべきなんですよね、啓蒙

ﾊｲやります

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

ﾌｧｲｯ!

個人的にはインスタンスローカル投稿には反対。
そもそも LTL 常用による寄合所帯インスタンスへの集中を促すデザインそのものが、分散システムのアプリケーションとして問題があると感じていて、それを促進するものには当然同じ理由から賛同しかねる #distsns

解決策を探るとするなら、「複数人が同じ現象に言及するという状況での文脈」みたいなものをうまく表現できるようにしたうえで、それを追いかけたり参加ユーザをフォローしやすくしたりといった方向で考えたい #distsns

よーするに、話題をインスタンスに所属させるよりも、話題への参加者のリストが話題を構成する投稿それぞれに含まれているような、 self-contained とでも言えそうな仕組みの方が、健全に分散してくれそう #distsns

ActivityPub 自体も JSON-LD でスキーマ拡張できたりするし(たとえば地理データなどを機械可読な形で綺麗に埋め込めたりする)、インスタントな話題や文脈についてのメタ情報も互換性を損なわない形で ActivityPub に突っ込めると思うので、無理筋な話でもないと思うんですよ。
無論、まっとうなスキーマを設計するという作業は必要ですが。 #distsns

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

原理主義者を自称していますが、実際 P2P とかにそこまで思い入れがあるわけでもなく、多少は現実を見ざるをえないので、私はそれほどでもないです

このアカウントは、notestockで公開設定になっていません。

GNU Social に「グループ機能」があって、たしか

・グループはインスタンスに所属する
・グループにはリモートからも参加できる
・参加グループの投稿が HTL に流れてくる

といった仕様だったように記憶していますが (訂正歓迎)、これもグループがインスタンスに所属するところがウーンという感じなので悩ましい。
たとえば「分散 SNS 鯖缶グループ」みたいなのが欲しいとして、これがどこか特定のインスタンスに所属し管理されるべきかといえば、おそらくそうでもない #distsns

https://odakyu.app/@ars42525/100625599281823461
「仕様」の意味が曖昧でよくわからないけど、

・実装や UI という意味であれば、無論勝手に変えれば良い(そうするべき)
・ActivityPub のプロトコル中核という意味であれば、これに準拠していないと実装間での互換性が失われて federate できなくなるので、プロトコル準拠は必須(ただし ActivityPub 以外の選択肢もある)
・JSON-LD によるスキーマ拡張を指すのであれば、無論好きにやれば良いのだが、実装に組み込んでもらえないと結局使われない

#distsns

あと、 LTL 反対派の多くは既に自分専用のインスタンス持ってて LTL なんて使ってないのではと思います #distsns

ぐぬそのグループ機能、内部的にはたぶん普通のアカウントに近いものになっていて、単に bot と RT 相当のことを UI レベルで誤魔化して RT に見えないようにしているだけなのではという気がするんだけど、記憶が曖昧だし確証はないので詳しい人に聞くか実装読んでください

乗り過ごして三崎口に来た #攻防2合宿

ユーザの目につく投稿(受動的に受信する投稿)はフォロー関係(やユーザローカルな設定)のみによって行われるべきだと思っていて、逆にユーザが見に行く投稿(能動的に受信する投稿)をシームレスに提示するのはクライアントの仕事であってサーバがやることではないと思っている #distsns

まあ Mastodon は UI がサーバ側にあるので事態がややこしくなりがちですが

これは「ユーザが見るものはユーザの意思や明示的許可によってのみ決定されるべき」という思想とも絡むわけですが #distsns

https://mastodon.cardina1.red/@lo48576/100547474099722005
https://mastodon.cardina1.red/@lo48576/100571681015237717
#distsns

このアカウントは、notestockで公開設定になっていません。

これ

やはり UI とバックエンド (ActivityPub サーバ)の議論は分離されてほしい…… #distsns

このアカウントは、notestockで公開設定になっていません。

まあ時代がどうとかで決める人の行動は時勢で変わるだろうし、そういうものでは

このアカウントは、notestockで公開設定になっていません。

https://mstdn.komittee.net/@kunimi_komichi/100625604558125378
私もおおよそ同意 #distsns

実は GNU Social にも LTL / FTL 相当のアクセスポイントがあるんですが、何故これが (Mastodon のそれに比べて)問題視されづらいかを考えてみると、やはりユーザのホーム画面で表示されないというか、メインで使う想定の UI になっていないというのが大きいのではと思われる #distsns

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

#攻防2合宿

このアカウントは、notestockで公開設定になっていません。

ゴルスタ丼(???)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

まあそれがほとんどの中央集権サービスの在り方だし、ユーザがそれだけ訓練されてしまっているという話でもある

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

これはわかる

twitter のアホを fediverse に呼びたくないというのはそういう話

fediverse をありがたいと思う人だけがやっていきすればいいし、十分に分散していればそれで持続する。過疎もクソもない

Mastodon は過疎ってて云々などと言われている時点で分散も分散への理解も圧倒的に不足している

授業 #攻防2合宿

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

まあ Mastodon が適当でないと思う理由を言語化して議論することには意義があるので、 Mastodon に変化を求めるかはさておき語る価値はある

このアカウントは、notestockで公開設定になっていません。

文脈これか

私が語るときの「分散」は Mastodon::分散 ではなく ActivityPub::分散 や 分散SNS::分散 の話なので、 Mastodon はその単なるいち実装としてどうなのかという話しかしていない

Mastodon がそういった後者の意味での「分散」にはあまり適しているように見えないというのは何度も延べていることろだけど、それは個々人にとって Mastodon がどうであるかとは別の話

そもそも OSS であり国際標準のプロトコルに乗っているだけである以上は原理的に代替可能なものだし、 Mastodon が世界の中心であるような語りをするつもりはない……

楽天のセキュリティの話を聞いた。ここに書いてはいけない系のやつ #攻防2合宿

Copy trait は「clone が memcpy 一発で可能である」という意味が第一で、代入がデフォルトで move でなく clone になるなどは単なる副作用というか、利便性を求めた結果であって最重要の性質ではないという理解です

もちろん

let i: i32 = 5;
let j = i.clone() + 3;
println!("{} + 3 = {}", i, j);

などしても正しいんだけど、 i32 はあえて借用せず clone しても何ら問題はないし、であればデフォで clone 扱いした方が(特にプリミティブ型や小さな型では)有り難みがあるよね、という程度のものです(個人の感想)

このアカウントは、notestockで公開設定になっていません。

RefCell の代わりに Cell を使えるみたいなメリットもたしかにありますね > Copy 実装した型

まあ Copy は marker trait なので、あくまでコンパイラとかの最適化を助けるものと考えるのが良いかと思います

Lang items
https://doc.rust-lang.org/1.5.0/book/lang-items.html

Box の内部実装はこのあたりに話が(ちょっと古いドキュメントですが)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

in_reply_to の仕組みが欠陥なんですよ

マホロバマインズ、パスワードなしで規則性のない無線 AP が無限に立っており、悪意ある AP 立てたらトラフィック何割か吸い込めそう #攻防2合宿

このアカウントは、notestockで公開設定になっていません。