アホが暴れない SNS の要件、「承認欲求を満たせない」というのが必要な気がしてきたな

たとえば直接のフォロワー/フォロイー以外からの RT / fav を認識できないとか

コミュニケーションと承認は一致しないので、承認欲求を満たせない SNS というのが本質的矛盾を抱えているとは思わないです

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

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

ﾂｲに限らないけど、ブロック自動化 (動的ブロックリスト共有) の仕組み欲しいよなぁ

リストのエクスポート/インポートは駄目 (更新されないため)

欲しいのは「ある瞬間に誰かがブロックしていたアカウントのリスト」ではなく、「特定の人が特定の名目でブロックした/するであろうアカウントのリスト」なので、将来における変更を反映できなければソリューションとして適切であるとはいえない

？

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

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

vendor c/psgo@v1.3.2 by vrothberg · Pull Request #4197 · containers/libpod
https://github.com/containers/libpod/pull/4197

libpod やっと cgroups v2 対応か……

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

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

シンプルに「クソッタレのために割いてやるコストはねえし、構ってほしけりゃ金払え」くらいの気持ちでいる

物分かりの悪い連中には「オメーには苦痛を受けてまで関わる価値はない」とはっきり言ってやるべきなんだけど、はっきり言ってやる価値もないので静かにブロックするわな

インターネットに何十億人いると思ってるんだろう、アホどもをブロックしても世界に有益な人間はまだいくらでもいるわ

あと「反対意見をブロックし続けるとエコーチェンバーになる」とかもアホな話だよなぁと思う。反対意見なら何でも不愉快でブロックしたがったり “改心” させたくなるお前らと一緒にしないでほしいわ

私の進めたい分散は権利の分散であって人間性には全く関係ない話です

というか「分散」という言葉も微妙な気がしていて、本来「サービスに関する権利を個々のユーザの手に取り戻す」というものなのよね

本来ひとつだったものが「分散」するというよりも、「委託を余儀なくされていた権利をユーザに返す」というのが私の感覚です #distsns

べつに多数決とは言ってませんが……

分散は「自分の意思で『特定の人間がブロックしたがった人』を同様にブロックする」という個人の意思決定と矛盾するものではないと考えますが

「本人の意思による」というのはよーするに「拒否による不都合が発生しない状況で、本人の理解と同意のもとで機能を利用するか」という話なのであって、ブロックリストが必ずしも分散により取り戻した権利を再び失うことを意味するわけではない
(実際そうならない機構も考えられる)

こういうときだいたい最初に検討すべきなのは Web of Trust をベースとした信用・信頼の伝播と減衰のモデルなのよね (割と適合する)

本丸があるかどうかは関係なくて、「『声が大きいユーザー』の大多数に従」うことをオプトアウトできるかどうかというのが本質。 twitter でそれはできないし分散 SNS ではそれを可能にできる

オプトアウトできるかというか、「オプトインであるか」が正確だけど。

twitter で強いられていたあらゆることを廃止すればより自由になるというのは違って、自由であるというのは何らかのメリット・デメリットを取るか捨てるか選択できるということ

これは「選択をあとから変更できること」というのも暗に含んでいる

ここ最近の特筆すべき絶望、「お絵描きできないので 3D モデルを作ろうとしたけど、三面図がないとまともな造形にできそうにない」ということに気付かされてしまった瞬間などがあります

まあいろいろ調べて三面図なくてもいけそうなメソッドを見付けたので試すだけ試してみたりはしてるけど、根本的に完成図のビジョンというかバランス感覚がないので険しい道程になりそう

セレブのようになったブロックリストを継続利用するかどうかはユーザに委ねられているし、むしろその愚かな選択をできることこそ自由でもあると思いますね。

システムで人間の愚行を抑えるにも限度があるし、そんな不毛なことが「愚劣でない人間がデメリットを飲み込む覚悟とともに危険な機能を利用できる」ことよりも大切だとは思いません

その (おそらく想定では) 不適切に巨大なブロックリストを実際に利用するかは個々人の選択なのであって、それを阻止することが自由に貢献するとは思わない。
それが気になるならソフトウェアのプロジェクトみたいに fork してメンテするみたいな仕組みを用意することもできるだろうし、あるいはそもそもそういうことができない別のブロックリスト共有の仕組みを選択することもできるかもしれない。

むしろ「○○は愚行に使われるから人々に提供すべきでない」は人々から自由を奪う考え方ではないかとも思えるんですが

私の求めるものはあくまで「意思決定とそれに基く行動がともに阻害されない」という状況であって、人々を愚行から救うことではないです

人々を愚行から救うなら政治や教育の面からやっていくべき

そもそもそういう人々を救うのはレイヤーの違う問題であると考えているという話ですね

人々が檻の中に入っていくことを防ぐのは、技術的な阻止手段ではなく教育、キャンペーン、そういったものでやっていくべき。

この問題について技術レイヤーですべきなのは、その檻にある日突然鍵がかかったとき人々を中から逃げられるようにすることだと考えます

だからそれは全く別の話ですね

私は大衆の行動を技術でコントロールしようとは考えていません (たとえそれが良い方向へであっても)

私は人々に「ナイフで手首を切ると痛いし病気のリスクもあるからやめた方がいいよ」と言うかもしれないけど、いざ本当に手首を切ろうとしている人に「やめろやめろ！！」と喚いたりはしないし、あるいは「手首を切ろうとしている人が手首を切れないナイフ」を開発しようとも思わない

「手首を切ろうとしていない人がうっかり手首を切らないナイフ」なら素敵だと思いますが

手首を切ろうとする人が手首を切れないナイフを開発するよりも、「自分の手首を切ることを躊躇できるような思想を持ってもらう」方が正道だろうと思うわけです

@keizou TL; DR: そうあるべきではないかもしれないが、ユーザ設定が無視されたとしても問題であるとまでは言えないと考えます。

そもそも LTL や FTL は「誰の意思で誰のために用意されているのか」が極めて曖昧です。
たとえば「個々人の意思を一切仲介させず、あるがままのデータを機械的に見せる」ものかもしれないし、「鯖缶の親切心で、全ユーザに一律に特定の情報を見せる」ものかもしれない。あるいは、「個々のユーザが、自分で閲覧するためにサーバに情報をまとめるよう指示している」というモデルもありえます。

最初のモデルでいけば、一切のフィルタリングが機能しないことは正当であるといえます。
2つめのモデルでは、ユーザが要求していないドメインブロックなどの追加フィルタが最初から導入されていることが正当化できます。
最後のモデルを想定すれば、ユーザがフィルタを自由に設定・適用できるべきだという論拠になるでしょう。

その辺りの「誰の意思で誰のために」が曖昧である以上、どのような実装であってもおかしいとまでは言えないし、逆にお互いに別のモデルを想定して「ここは FTL の意義に合っていない」と主張することもできてしまうだろうとも思います。

https://mstdn.nere9.help/@orange_in_space/103012713964850428

これは「ソースコードを全部読んでないのにどうしてソフトウェアを使う気になるのか」と同じような話に思える。
一般に信頼の構築は必ずしもデータそのもののみによらないし、たとえば「誰が作った」「その誰かが今まで何をしてきた」で信頼の初期値を決めるのは極めて妥当に思われる。

問題の兆候があったとき、その中身を精査できるということが大事なのであって、「利用するあらゆるものを完全に精査する」というのはコストがかかりすぎるので、問題の兆候がないときこれを省略しようと考えるのは当然よね

小学生頃、ブラウザのマウスジェスチャに飛び付いたりしてた時期があって、結局全然使いこなせなかったんだけど、たまにそのことを思い出してあの頃は若かったなぁみたいな気持ちになる

思考が硬直しはじめた今となってはタブレット端末でのジェスチャも忌避してしまうやもしれず、まあ恐ろしいことではある (使いこなせるかはまた別の話)

「誰が作った」だけでは信頼するには足りないと考えるとき、「誰と誰が信用していて、私らその人々をレビュアーとしてどの程度信用している」みたいな間接的な信用を利用したアルゴリズムが輝いてきて、これこそ Web of Trust なわけです

https://mastodon.cardina1.red/@lo48576/103012570112559617

参考までに cargo-crev というプロジェクトが WoT を利用したソースコードレビューシステムで、とても良いものだと思うので概要だけでも把握する価値はある。
今は Rust のみの対応だけど、根本のシステムは言語非依存なのでそのうち js 版とか他言語への対応もしたいそうで

べつに「ブロックしている」ことは「ブロックしたユーザをどう頑張っても調べられない」ということではないし、そんなに気になるならブロックリストを上書きするホワイトリストを用意するとか、ブロックリスト一時無効化みたいなものを用意するとか他にやりようはあると思うけど

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

そもそも「特定のものを避ける」というのはテクノロジ以前の人間の行動自体の傾向であって、ブロックリストがなかったところで無視するものは無視するので、これが「何かを見ない」ことについて何らかの致命的なまずさを持ち込むだろうかというのはちょっと疑問

風呂

https://twitter.com/hncgu/status/1187053456265269250 #tw #potd #これすき

つよすぎてこれすき

㊰ですので……

人生そろそろ潮時か？？？？

自分より賢い人を殺せば偏差値は上がる。
つまり「天才の脳を食えば (相対的に) 賢くなる」は真です。

なお、これは死んだばかりの鮮度の高い脳でないと意味がないことに注意しましょう (適当)

これ currying

これ uncurrying

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

艦これ6話

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

本の虫: 2018 Jacksonville会議でC++のドラフト入りが決定した機能
https://cpplover.blogspot.com/2018/03/2018-jacksonvillec.html

基底クラスじゃなくてもサイズ0にできるようになったのか。継承より合成で実装を引き継ぐときのメモリロスをなくせるわけだ

いろいろ入ってるんだなぁ (追いかけなくなってから一気に疎くなってしまった)

C++ 、型システムがあまり豊かでないせいもあるんだろうけど、任意の問題を attribute で解決しようとしている印象を受ける (偏見気味)

noreturn みたいな

あくまで「最適化のため」なんだなぁという印象が強い (まあスタンスが一貫しているといえばそうかも)

/dev/neru

やっと目が覚めてきた、つらい

twitter に kb10uy 氏がいたので見る TL 間違えたかと思って脳が混乱した

tw10uy

2019 Roadmap Progress? - internals - Rust Internals
https://internals.rust-lang.org/t/2019-roadmap-progress/10862/7

わくわくするなぁ

std::get (std::variant)
https://en.cppreference.com/w/cpp/utility/variant/get

これ std::get<42>(v) と std::get<float>(v) どっちも使えるんか……ヤベえな

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

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

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

https://kiwifarms.cc/objects/0a330d8b-1400-4536-9a3e-03b9c8428bc8

爆笑した、だいすき

ALL CULTURES MATTER BUT I DONT WANT TO SEE ALL CAPITAL ENGLISH WHEN IM TRYING TO SCROLL THE MASTODON

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

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

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

「フィルタリングは受信側でかけろ」定期

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

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

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

送信者側でフィルタしろというの、つまるところ「他人を自分の都合の良いように操りたい」欲の発露だからなぁ

これは pawoo や jp に限らないけど、寄合所帯インスタンスはアカン奴がある程度いると、たとえまともな人が多くてもフィルタリングがインスタンス単位になったりして、まともな人を巻き込んだ対処になりやすいのでよろしくない

こいつらと一緒にすんなと思うような人と同じインスタンスに所属しないでほしい。独立して♡

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

だから「流行」を作るのはなぁみたいな気持ちになるんですよね

まず最初に思想への理解と了解を持った上で参加してほしいが

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

「流行」は「何もわかってない人がファッションの一環として入ってきて、文句言うだけ言って去っていく」のエイリアスみたいなものなので

これも何度も言ったことあるけど、分散 SNS はやたら多数の人々がいないと利益取って成立できないような中央集権商業 SNS とは根本的に違って、ユーザが少なくても成り立つものなんだから、何もわかってなくてこれからもわかるつもりのない人々を twitter 気分で呼び込んでもお互い得るものが少ないよ

私自身は思想から GNU Social に入った人間なので……
まあマイノリティなんだろうとは思います。残念なことに。

その「衰退」が中央集権商業サービス基準で考えてない？ という話をしています

たとえば極端な想定として「少数の根強いコアユーザが存在する」としたとき、商業だとこれは潰れるだろうけど、分散 SNS でこれが「衰退」することに何か問題があるのだろうか？人が増えなくなった slack チャンネルや discord サーバ並には有用だと思うけど

まあソフトウェアのメンテナンスとかはコストかかるので純粋にユーザ数だけ考えてもしょうがないんだけど。

まず衰退とは何を指すのかをはっきりさせるべき

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

であれば「流行しない」ことは「ユーザがいなくなること」と一致しないのでおしまいという感じですね

まあ真面目な話、分散サービスにおける衰退の定義は割と非自明な問題だと思う

たとえば特定クラスタの人間が皆去っていったとして、他のクラスタでは普及していたとする、このとき fediverse は「衰退」しているのか？

#distsns

いつぞやの Mastodon ブーム以前から、 GNU Social に定住していた人々は存在するわけで、そのくらいの規模で fediverse に価値がなかっただろうかといえば私はそうは思わないし、「流行させる」以外にも人を呼ぶ方法はあるだろうから、そっちを考えたいわねという気持ちがあります

分散 SNS は良いものです、権利をユーザに取り戻します、それでいいじゃないですか。
敢えて「ポスト twitter」などと twitter ユーザを煽って無知な人々を無知なまま誘導してくるような余計なお節介があまり素敵に思えないというくらいの話と捉えてください

「必要としている人々が参加できる」くらいのレベルで応援したい感があり、押し売りをする気力はないしその結果として荒れるのも嫌

いい話だった

firefox とか thunderbird はいつになったら Python 3 でビルドできるようになるんですか

これなんだよなぁ

回避可能な問題で延々と苦しむの、あまりに不毛

個人レベルで分散しような……

Firefox/Python 3 Migration - MozillaWiki
https://wiki.mozilla.org/index.php?title=Firefox/Python_3_Migration

なんとしてもエッジケースを突きたいマン、性質が完全にデバッガのそれ

気持ちはわかるけど私はあまり人間に興味ないのでそうなっていないだけで、モノに対してならまあわかる

https://mstdn.maud.io/@pakutoma/103016591498264492

たしか CUE + flac 使うと、曲の間のギャップ情報まで保存できるというのがメリットだった気がする。
あとはジャケットファイルがトラック間で重複しないので若干容量削減できるとか

私は基本的にトラック毎に flac だし、 flac で表現できないレベルのハイレゾは wavpack 使ってます

昔は flac + cue + jpg in mka なんてのも試してたことあったなぁ

全員が個人インスタンスなら、たとえば DM とかも当事者間のみでの通信になるのでプライバシー確保できるんだけど、少なくとも一方が寄合所帯インスタンスだとそっちの鯖缶が DM 覗き見権限持ってるからなぁ

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

改札で前にいた人の Suica 残高が18円で、ンン！？ww ってなった

Rust and C++ on Floating-point Intensive Code - Math, Numerics, and Software
https://www.reidatcheson.com/hpc/architecture/performance/rust/c++/2019/10/19/measure-cache.html

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