このアカウントは、notestockで公開設定になっていません。
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
このアカウントは、notestockで公開設定になっていません。
これは in と inn = 宿 を掛けた #高度なジョーク です
他人の発言を勝手に #高度なジョーク 扱いする貴族の遊びです
https://social.mikutter.hachune.net/@akkiesoft/99484903821485751
これは布団に入るということと、宿泊のための施設のことを inn と言うことを掛けた高度なジョークです #高度なジョーク
このアカウントは、notestockで公開設定になっていません。
https://twitter.com/gnutools/status/1098972442796658690
Jakub Jelinek - GCC 8.3 Released
https://gcc.gnu.org/ml/gcc/2019-02/msg00121.html
🎉
このアカウントは、notestockで公開設定になっていません。
結局、どう UI を改善したところで、根本的に「Mastodon は分散システムの一部であって fediverse はそのビューに過ぎない」という事実は伝わらないと思われる (何故なら人々は分散システムという概念を知らないしわからないため) ので、もっと「お前は根本的に勘違いしている」とわからせるような突き放したデザインが必要なのではないかという気持ちさえ湧いている
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
個人的には、 fediverse はあくまで分散 SNS として設計されたプロトコルに乗っているのであって、その対象外の事象まで抱えようとすると猛烈に汚くなっておしまいなのではないかという気がしている #distsns
分散 SNS というか、「フォロー指向のユーザ単位マイクロブログ」と言う方が正確かな？
そうあることが自然なように定義されたプロトコルに、「フォローしてないけどやたらユーザに向かってくるコンテンツ」みたいなのがシステムとして用意されることが真っ当だろうかと考えると、私にはそう思えない #distsns
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
もっとシームレスにしようというのは同意だけど、分散 SNS であるという構造を隠すべきであるかは自明でないと思う
というのは、分散 SNS が分散するというのは単なる実装の話ではなく責任や権利の話でもあるので、最終的にその責任や権利がユーザ自身のみに帰属すべきなのであれば、本来分散すべきなのはサーバではなくユーザ自体なのであって、当然 fediverse の内部構造 (すなわち分散システムという概念) もユーザ自身が認識しているべきといえる #distsns
このアカウントは、notestockで公開設定になっていません。
https://sandbox.skoji.jp/@skoji/101636845046019913
たしかに、 fediverse 全体をひとつのシステムと考えたとき分散は内部構造ではあるけど、ユーザが本当に使っているものは責任がそれぞれの運用者に分担された別個のサービスであって、 fediverse はそのシームレスな結合にすぎない #distsns
https://mastodon.cardina1.red/@lo48576/101636846202238091
もちろん、最終的に個々のユーザが権利と責任を手に入れるべきであるという目標が否定されるのであれば、この話もまた変わってくるわけだけど……私は原理主義者なので、最も優先されるべきは個人単位サーバのユーザ(兼運用者)が最大限の恩恵に与れることだと考えます #distsns
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
これはこの前ラボの人と話したことなんですが、「概念」という概念をわかっていない/認識できていない人間が存外に多いみたいな話
正しくないモデル化や、事象のモデル化を拒むような人々の前では、あらゆる正しい理屈は無に帰しがちなんですね
ここでいうモデル化を拒むというのは、抽象化という概念を知らないゆえにモデル化という思考をできないということも含みます
https://mastodon.cardina1.red/@lo48576/101636864355719004
で、↑これは一般論なんですが、 fediverse に参加するサーバのインターフェースについても似たような話はできるのではと考えたりなどしました。
つまり、その UI はあらゆる無知なユーザを想定して「分散 SNS のモデル」を完全に隠蔽すべきなのか、逆に「分散 SNS のモデル」をある程度わかっている人間が最もシステムを自然に操作できるように用意されるべきなのか、ということです #distsns
あと、 LTL や FTL がユーザ発見に有用であることは確かですが、これが本当に「実用的に必要」であるかは疑問でもあります。
たとえば私を観測できる範囲にいるオタク各位には twitter がタイムラインを滅茶苦茶にしたりモーメント機能が登場するよりずっと前 (かつ公開タイムラインが死んで以降) から twitter を使っていたユーザも多いのではないかと思いますが、そのような状況で「自分のタイムラインを構築できなかった」だろうか、という話です
(無論、生存バイアスは考慮すべきではあるけど) #distsns
Mastodon から FTL と LTL を取り除いた実装は、ちょっと前の古きよき twitter 程度には十分に実用的に機能するはずで、であればそれらの機能が必要であるかというとそうでもないといえるかと。
#distsns
で、生存バイアスについては、 twitter は中央集圏的な商業サービスだった (そして結局広告が発生した) ので無作為にでもユーザを集めるインセンティブが強力だったけど、 fediverse で本当にそうやって無作為なユーザを集める必要があるか、と。
ひとことで言ってしまえば、「fediverse を使っていて楽しくない人は、 fediverse からそんなに得るものがない人だ」という考え方もできるのではないかという。
(で、 twitter はそういう人々まで拾うことがビジネス的には要求されていた、と。)
#distsns
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
結局人間的にはハブは欲しくなるんでしょうけど、ハブは fediverse やそれに参加するための実装から直接に提供されるべきでなく、交換可能かつオプショナルな形で外部的に提供されることができるはずだ、という考えです #distsns
たとえばモーメント以前から togetter があったように。
(まあ私は togetter の web ページ設計が嫌いだし、 twitter のモーメントの UI も嫌いなんですが……)
もっと別の言葉で表現するなら、機能への責任はもっと明確に分解されるべきだという話になるかも。
fediverse やそれに参加するための人間用サーバは、 ActivityPub により交換される情報や交換機能を提供することを第一とするのであって、他の機能をプライマリであるかのように喧伝するのは危険な気がするし、そういった「プライマリでない機能」を、ある程度特化してその機能提供に責任を持てるような別実装に委託するのが自然に見える (ﾎﾟﾖｸﾞﾔﾏ並感) #distsns
このアカウントは、notestockで公開設定になっていません。
https://mastodon.cardina1.red/@lo48576/101636921831378331
まあこれは「本質的機能とそうでもない機能を混ぜると、後者を前者であると勘違いする輩がテキトーなことを言い出す」みたいな人間のアカン面の表出を未然に阻止したいというような気持ちも若干あっての考えでもあるけど……
ActivityPub がデータ表現形式として使っている JSON-LD が RDF と強い互換性を持つものであるのだから、当然 ActivityPub も “自然な形で” ライセンス情報含むメタデータを綺麗に表現できるのではないかと思うわけだけど、ふーむ #distsns
結局のところ、いろいろなコンテンツ界隈を見ているとわかるように、人間がライセンスやコンテンツ利用状況という概念を十分に考慮できるほど優れていないというのがどうしようもないのかもしれない…… #distsns
法律で定義されている範囲でさえ、引用とパクリの区別も付けられず騒ぐ人々がいるわけで、さらに「自分の発するコンテンツにオレオレライセンスを付けて人々を制御したい」みたいな欲求にその道の素人が抗うのは相当に難しそう
その道というのはコンテンツ作成ではなくコンテンツ利用方面です
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
結局Twitter初心者だったころブートストラップをどうしていたかもそんなに思い出せないし、記録していくしかないんだろうなあ
なんというか、 fediverse は根本的にはレイヤーがかなり低いシステムで、「ユーザを発見したい」というのは本来それより上のレイヤーに乗る「アプリケーション」の仕事なんですよね。その辺りが混同されているからモヤっとするのかもしれない #distsns
うまく喩えられているかわからないけど、たとえばファイルシステムは情報を記憶してアクセスを提供するのがプライマリで必須の機能じゃないですか。で、その上にユーザの「データを発見したい」みたいな要求が乗るわけですが、これは通常ファイルシステムそのものが直接に提供すべき機能ではなく、ファイルシステムを扱って駆動するアプリケーションが担当すべき管轄なわけですよね。
fediverse におけるフォローや投稿などとユーザ発見についても、同様のレイヤー違いがあるのではないかと。 #distsns
無論、効率化のためにファイルシステムがそういうありがちなユースケースを全て吸収するということも考えられるわけですが、これは中央集権的なやり方なわけですよね。たとえばファイルシステムが複数あってその実装もばらばらだったりすると簡単に破綻するわけで
ユーザーレベル(もしくは投稿レベル)でそういうライセンスを設定できる可能性が十分にあるので模索されてほしい(その仕様が結果的に発散してしまうと意味がないが……)
このアカウントは、notestockで公開設定になっていません。
グループで集まりたいならグループウェアを使えというのは本当にその通りだと思う (グループウェアを使うからといって別メディアで集まれないわけではないし)
で、残念ながらここにも罠があって、クローズドなグループと情報を扱うグループウェアとオープンなグループや情報を扱うグループウェアは、本来別カテゴリになるべきなんだけど、区別されない場合が多い。
結果、隠される意味のない情報が無闇にクローズドな場でやりとりされることになりがち
https://mastodon.cardina1.red/@lo48576/101636864355719004
モデル化がうまく行われない例ですね
一方で、マストドンの問題として、マストドンがActivityPubとかから大幅に拡張した『規格』になってしまっていて、かつ オイゲン氏はそれを規格のように考えていない(仕様に長期的一貫性が無い)ので、マストドンその物に組み込まないと、横断的に一貫性があるUXを持つような(外部の)仕組みを作れないかも＞＜
この前もPleromaとか方面と、マストドンという『規格』で もめてたよね？＞＜
これはどちらかというと、いち実装を規格であるかのように神聖視しがちなアプリケーション実装者に責任があるように思われる (まあ “実用上” はそのように振る舞うことにも一理あるんだけど……)
このアカウントは、notestockで公開設定になっていません。
大抵のオープンなグループのグループウェアはクローズドな情報を扱う機能を持っているので……
このアカウントは、notestockで公開設定になっていません。
人間が愚かなのはまったくその通りなんですが、結局最初クローズドにした情報が公開されることってほとんどないと思うし、クローズド前提のプラットフォームは大抵そういう機能を持たないので (少なくとも discord 上で行われた機密でなく有用な会話が外に出ているのを見たことがない)
人間は愚かなうえに怠惰で過去の情報を整理しないので、だからこそ後から公開設定を変更可能だったりオープン前提の情報公開は人々にとって有益になる
ActivityPub、実用上Mastodonに合わせなければならない点が多すぎるのは本当にどうにかしたほうがいい
第一には認証まわりやストリーミングを含めたクライアント-サーバ API ですかね。あの辺りが十分でないうちは AP だけで動くクライアントは現れないのかな (規格熟読してないので詳細はわからず)
でも、じゃあ本当に規格化されていた部分だけを見て作ろう、マストドンの(長期的一貫性が無い)各振るまい各機能、それにどうにか互換性持った振る舞いを苦労して実装してるPleroma等々の各機能全部無視して、UXに一貫性があるもの作れる？＞＜
https://mstdn.nere9.help/@orange_in_space/101637023117701712
そもそも UX への責任は AP サーバが持つべきものではないと考えているので、ちょっとこれはよくわからないです
これはクライアントアプリケーションが責任を負うべきものであって、そんで現状の Mastodon や Preloma 等は単にサーバとクライアントが一体で提供されているから境界が曖昧になっているだけですよね
いつのまにか日本語訳が出現していたのか、ありがたい話だ
もっとこう、「規格を最低限実装するだけでも一定のコミュニケーションが確保される」ぐらいまでは策定するべきだと思うんですよね
本質的に悪なのは「特定の検証機構をこの文書で命令的に指定することはしない」の部分であって、指定しろよ
なんでしょうね、 web にありがちな感じのアレかな、別の規格でプラガブルに指定することでデファクトスタンダードが形成されるのを待とう的な
投稿や引用等の名称でさえ統一された規格通りになってないんだよ？＞＜ マストドンが最初に出会ったSNSだったユーザが「短文投稿の事はtootというのか」と学んで外部サービスを使ったら例えば全部「レス」と書かれてたら「レスってなに？」ってなるでしょ？＞＜
みたいな状況なのに「インスタンス」って言うのやめて「サーバー」にするんでしょ？＞＜(それ自体は賛成だけど)
オイゲン氏、規格というものがなぜあるかなんてなにも考えてないかも＞＜
それはまあブランディングみたいなやつで、「クライアントとしての Mastodon」の責任になるわけですが、「内部実装を不必要にユーザに露呈させるな」を忠実に行っているだけとも考えられるので、その考えによれば一概に否定できませんね
個人的に言わせてもらうなら、規格に存在する概念は規格の言葉を優先して利用するべきだと思いますが、人々はそういう堅苦しい/“専門的な”言葉を嫌いがちなので。
書いてて行き違いになったけど、各機能をなんと呼ぶか？も規格でありUXなんだよ？＞＜
https://mstdn.nere9.help/@orange_in_space/101637061533052071
「○○を△△と呼ぶべき」という規定が明文化されて発行されたならばそれは規格だけど、そうでない UX 上の事項は単なる人々の合意、デファクトスタンダードに過ぎないわけであって、これは倫理観と合理的判断により当然多様性が発生しうるという考えです
たとえば ActivityPub におけるイベントの単位は "Object" だし、投稿は "Note" 型のデータだったりするわけだけど、これをクライアントの UI において露呈しない、他の用語を用意するというのは十分に合理的に行われうるかと思います。
まあ "toot" が合理的かはまた全く別の話なんですが。
受信したコンテンツの検証、JSON-LDなどでどうにかなる問題ではないわけで明記せずにほっとける話ではないという表明をしたところで寝ます
それこそオブジェクトの検証が "MAY" だったら明示的に指定しないほうが望ましいかもしれないけどさあ…… SHOULD なんだからそこは指定しとけよ……
まあ暗号的事項の関わる場所はプロトコルを交換可能にしたいはずなので、規格設計としてはデータ交換形式の一部として特定の方法を明示しないのも一定の妥当性はあると思います
結局のところ、特定の認証方式が指定されないのが悪いのではなく、「認証方式として選択可能な標準が存在しない」のが悪い
「インスタンス」言うのやめて「サーバー」にする話でも、外部サービスがそれを「インスタンス」と呼んだままだったら、ユーザーはなんの事だかわからなくて混乱するよね？＞＜
そういう事も含めて、長期的に一貫性を持って約束して公言して規格にする事で、ユーザーはロックインされずに、自由に、分散されて、・・・・かも＞＜(語彙力)
オイゲン氏は約束せずに逃げてるとも言える＞＜
まあ用語をコロコロ変えるのが実装者として素敵でないというのはわかりますが。
これもデファクトスタンダードとなる用語セットがない黎明期だからこその現象と捉えることもできるので、今のところまだ私は寛容であろうと考えています。
用語が食い違っているのは ActivityPub 以前からだし……orz https://blog.cardina1.red/2017/04/13/federated-social-web/#terms-differences
UX上の各情報が何を指してるのかわからなければ、ユーザーは操作不可能という実用的な問題があるよ？＞＜
例えばマストドンで言うところの「インスタンス」を「クルトン」と呼んでる外部サービスがあったとして「クルトンを入力してね！」とか書いてあっても意味不明で「コーンスープは関係ないだろ！？」ってなるじゃん？＞＜(今食べたい)
合意というのは人々によって行われるべき事項であって、いち実装が責任を持てというのはおかしいかもしれないが、かといって規格がそれを明示すべきかというと、それは明らかにユースケースを制限することになりうるので危険そう
たとえば「業界団体」的なものが発足したり、メジャーな実装の実装者たちがどこかで議論をして、ひとまずこういう言葉を使いましょうと合意を取るというのが理想的なプロセスであって、だからこそ “デファクト” スタンダードとなりうるわけで。
UI や UX について規格が事細かに規定すべきでないという考えのもとでは、 user-facing な事項の用語ができるだけデジュレスタンダードであるべきだとは思いません
結局のところ ActivityPub はプロトコルの規格なのであって、たとえばマイクロブログ以外の自然な用法がありうる (たとえばブログ記事や動画サイトの動画へのコメントなどを投稿として表現しうる) 以上は、 UI で使われるべき用語はプロトコルの規格で規定すべきでないという立場です、私は。
でも、規格にしないで「単に実装の仕様なんです」って逃げて、それをコロコロと「改良しました！」と変えておろかな信者的ユーザーに「こっちの方が新しいし、古いのにこだわるのは老害」って言わせるの、自由に反するIT界隈の独占的な色々がやるロックインの手法の代表例でしょ？＞＜
それを『分散』のマストドンがやらかしてるのはどうなの？＞＜
べつに規格にしたからといってロックインから免れるわけではない (むしろ規格の在り方によってはロックインを推進しうる) し、自然言語によるラベリングはむしろ「人々」マターであって、どうしてもというのであれば「UI の規格」を作るべきではという感じ。
まあその UI の規格策定を押し通した twitter が我々の目にどう見えているかというのは御察しの通りなんだけど
でも、どこかで規格に(標準化)するか、デファクトスタンダードを作り出してしまった者が一貫性を持つことにより、機能する(ある程度信頼して使用できると言い換えてもいい)デファクトスタンダードにするかしないと、結局独占になってしまう＞＜
https://mstdn.nere9.help/@orange_in_space/101637168975300656
これには同意するけど、私は現状の Mastodon がデファクトスタンダードを確立したという認識について自信をもって肯定できないので、その点については賛同できないですね
つまるところ、 fediverse のサーバ実装や人々の認識は未だ early stage にあると思っているので、この段階で何らかの正しい概念が人々に深く根付いていると考えていない
なんなら、 Mastodon が人々に植え付けてきた錯覚 (特に LTL であるとか 「twitter と違って○○」 (実際は本質的に同じ) とか) については壊していく活動を今からでも活発にさせていくべきであるとも考えている
twitter と本質的にはだいたい同じ (あるいは twitter よりひどいことさえある) なのに勘違いされているの、典型的には「Mastodon は炎上しづらい」とか「Mastodon は強権をふるわれない」とか「Mastodon は twitter よりルールがユルい」とかですね
人々の認識をひととおりになるよう操作しようというのはある種の傲慢であって、だからこそ「人々」の合意としてのデファクトスタンダードや自然言語利用の枠内での新語拡散がなされるべきだと思っている
超ショートカットして最初の話に戻すと、外部のサービスとしてマストドンと互換性がある各実装向けのものを作っても、オイゲン氏の気まぐれで、それが使い物にならなくなるよって言いたい＞＜
独占主義的なIT屋の製品サービス向けのソフトウェアと同様に＞＜
https://mstdn.nere9.help/@orange_in_space/101637197235703387
これについては私は「Mastodon と互換性がある」ように作ろうというモチベーション自体が既によろしくないでしょうという意見で一貫しているので、それだけの話ですね……
標準でないものを標準であるかのように扱うならば、その悪い性質について実装者が責任を持つのは当然に思われます
標準が使い物にならないのであれば、標準をどうにかすべきなのであって、まあそれは理想主義と言われるかもしれませんが、私はウンコ食いたくないので料理ができるまで我慢します。あるいは私にできることがあるなら協力したいとも思いますが。
いろいろなレイヤーに望ましくない考え方や性質があっても、それらはそれぞれの属するレイヤー近傍において解決されるべき事柄なので、「標準規格レイヤーが駄目なので、代わりにアプリケーションの挙動レイヤーで交換可能性を引き出すぞ」というのはそりゃ大変な目に遭っても知るかよという感じです
用語等に規格が無いから(こそ)、代表かもしれないマストドンが規格のような立場になってしまっているかも＞＜ しかも、オイゲン氏は一貫性の事なんて考えていない(インスタンス/サーバー)という不幸な状況であるのに＞＜
これについては再三述べているとおり、「(ある程度安定したデファクトスタンダードに) 収束するまで待て」というお気持ちなので、現段階でそこまで大きく問題視していないです
その"我慢"こそ、発端の話である『周辺機能は外部サービスに・・・ができずに諦めてマストドンに実装するしかない状況』かも＞＜
https://mstdn.nere9.help/@orange_in_space/101637230654112190
これはその通りなんですが、同時に「妥協のために汚いことをしたんだから、汚物を被ることになるのも当然の帰結」というそれだけの話でもあります
べつに自分の判断で汚物を被るのが一律に悪いことだとは言ってないですよ。
ただ汚物を被ると大抵は苦労するものだし、あるいはユーザがちょっと臭いを嫌がるかもしれないですが。
「人々が汚物を被らざるを得ない状況を改善せよ」というのは至極当然の要求であって、それは標準において解決されるべきことなので、特定の誰か/何物かに標準として振舞えと要求するのはお門違いです (特定の誰か/何物かを標準として扱う方に問題がある)
つまり、本質的ではないサービスを外部サービスに切り分けるのも待つ？＞＜
それともTwitterAPIのごとく現状の仕様にあわせて作って、後にオイゲン氏が仕様変えてツイッタークライアントみたいに大量のコードがまとめてゴミにされるのを待つ？＞＜
待てない人は汚物を被る覚悟をしてくださいということです (マジで)
現状クライアントを作っている勇気ある方々は、 Mastodon の仕様変更という汚物を被る覚悟をしているわけですよね。尊敬はしますが真似はしたくない。
結局ウンコを食うか虚無を食うかという話で、前者がマシという人もいれば後者がマシという人もいる。
私は後者がマシだと思うけど、現状で Mastodon クライアントを作っている (しかも Pleroma とかにも対応しようとしている) 人々は前者がマシだと思っている。
そういう価値観の話。
・・・と言うことは、オレンジが最初に書いた通り、現状(つまり、待った先では無い)、マストドンその物に周辺機能も組み込む方向で考えるしかないってことだよね？＞＜
それを言ったら、そもそも ActivityPub が recommendation になる前に AP を実装しようとしていた人々もウンコ食う覚悟をしていたことになるわけですが、そこで待つ選択肢だってあったんですよ。
現状だってこれから先だって、規格が整うのを待つという選択肢は常にある。
待てない人がウンコを食う覚悟を決める。
そういう話。
https://mstdn.nere9.help/@orange_in_space/101637258937233748
なので、「待てない」というのを暗黙の前提にするのはフェアではないと思いますね
ここで「待つべき場面が多い」という現状も含めての、 ActivityPub を取り巻く環境が early stage であるという話でもあります
私だってどうしても待ち遠しい機能が必要なときはウンコ食う覚悟をして unstable な機能を使うんですよ。それで実際にウンコ食わされたことだってある。
だからこそ標準から外れることに慎重になるし、標準として用意されていないものを標準と並べないようにするんです
ウンコ食わされうるような勇気ある行動をしている人々、当然ウンコ食う覚悟あるんだと思ってたけど、もし実はそうでもないのだとすれば、それは人々の標準や安定という概念に対する認識の不足の問題なので、また別の話ですね……
具体的には、非標準や不安定に対しての認識が甘い/そういった機能を自覚的に使えない人々に対して、追加のコストを支払ってでも安定を提供すべきか、あるいはそういった人々の認識が正される/正しくない認識の報いを受けるべきか、という別の話です
iMast、そもそも日本での初期マストドンブーム(2017年春)のころにまともなiOSクライアントがねえって使い始めて、なんか最近まともなiOS クライアントが出てきたと思ったらみんな更新疎かになってるので(まあiMastもApp Storeだけ見るとアレだが…)、結局俺がMastodonやってる限りはどんなに破壊的変更が入ってもiMastの更新続くんだろうなとは思う
まあなんかMisskeyという同じAPIインターフェースが一年持つかどうかとかいう超unstableなSNSで生きてきたのでウンコ食いながらクライアント作るのに抵抗ないのかもしれんな
趣味の範囲だとウンコ食っても吐き出せばいいので「仕方ないにゃあ……食うよ」と言いながらウンコ食ったりするんですが、これが自分でない第三者に提供するものとなるとまた恐怖レベルも変わってくるので……
非安定 API を使うアプリケーションを継続的にユーザに提供しつづける人々、ほんとすごい精神力だと思います。私なら絶対途中で参る
オレンジ的には、それが自由に反するソフトウェアやハードウェアが囲いこみするための行動と同等であり、自由を謳うソフトウェアであっても同様にそのソフトウェアが独占的に囲いこみしてしまうのであれば、トートロジーだけど、自由に関する重大な問題だと考えるかも＞＜
特にそれが自由を謳うソフトウェアであるならば、行動に一貫性が無いと言えるかも＞＜
分散を不可能にしようと振る舞ってる囲いこみ主義のソフトウェア、マストドンって事になるかも＞＜
まあそうですね、標準があるにも関わらず標準から人々を非標準へ誘導しようとするのであれば、それは邪悪なロックインの試みと同等であると言えるんでしょうけど。
現状で Mastodon が人々を非標準へ誘導しようとしているかと考えると、ちょっと疑問ではあります
Mastodon は標準が存在しない領域を独自実装で埋めていますが、これが標準になることを妨げるものは (規格化に携わる人々の知的労働コスト以外には) ほとんどないはずだし、標準が策定されればきっと Mastodon はそれに追従するでしょう (OStatus のみならず ActivityPub に対応したように)。
これは本当にロックインと同等であるといえるでしょうか？ 私はそうは思いません
むしろ、独自実装を当然そうあるものとして標準のように扱おうとしている人々が (そんなのがいるとすれば)、「自ら進んで、抜け難い檻を作ろうとしている」みたいな光景に見えます。であれば、ロックイン的現象を発生させようとしているのは、他ならぬサードパーティクライアント開発者ということになる。
であれば、その責任を Mastodon に問うのはちょっとおかしい。
オレンジ的には、現実にどう向き合うか？とか仕様に従う開発者としてみたいなことよりも、自由や分散の思想の面で見るとどうだろうって事の方が大事かも＞＜
じゃなきゃ結局自由に反し、分散せずに独占される考え方の陣営(？)の発想の方がどんどん広まっちゃう＞＜
まあ Mastodon がいくつかの面で理想的とは言い難いというのはそうなんでしょうけど。
だからといって Mastodon にまつわる問題の全てで Mastodon に責任があるわけではないという話なので、私はどちらかというと問題の元凶を追いたい感じですね
何らかの不都合があって、人々が自分の判断で妥協を選択したのであれば、その結果についての責任は不都合だけでなく妥協そのものについても追求されるべきという感じです (一般論)
まあ結局たぶんウンコ食う覚悟の話になっちゃうんですけど
https://mastodon.cardina1.red/@lo48576/101637370771443608
雑に言うなら、「Mastodon はウンコを作り出すかもしれないが、それを食うのは食う人の選択だ」という。
そして Mastodon 以外にウンコでなく料理を作ってくれる実装を作ることは妨げられない。
それ、目の前の分かりやすい問題で言うとサードパーティークライアントが「インスタンス」なり「toot」なりをどう表現すればいい？＞＜
マストドンの用語をそのまま使えばマストドンにロックインされてるのと同じ、
各サードパーティークライアントがバラバラに用語を使うと、今度はそのサードパーティークライアントにロックインされてしまう＞＜
iPhoneユーザーが他所の電話器に乗り換えるのに障碍があるのと同じように＞＜
https://mstdn.nere9.help/@orange_in_space/101637373525885069
ユーザが用語セットを切り替えることは妨げられないわけで、私はこれをロックインであると捉えていません。
たとえば最悪な話ではありますが、クライアントが独自用語で統一性を出すことも可能ですよね
単にユーザが概念の更新や切り替えが嫌だからといって扉の開いた檻から出ようとしないのは、ロックインとはまた別の話 (たとえば「ユーザが不自由さに無自覚なのでまともな方に行かない問題」とでも形容すればいいのか？) だと考えます
まあロックインの第一歩としてそういったユーザの怠惰を利用することがあるというのは間違いないですが、だからといってユーザの怠惰の責任をなんでも実装に求めるというのは違うのではと
自由ではないシステムに対する妥協かも＞＜
オレンジがこういう話とか、デザインを変更する時は土下座するつもりでみたいなのも同様にロックインの問題でもあるんだけど、
各個別の問題その物よりも、IT界隈の多数派の考え方が「新しい物はより正しい」「規格がコロコロ変わる一貫性が無い物を追う事が正しい」みたいな事になって結果的に自由に反している現状を変えたいと考えていて、だからこそあれかも＞＜
これについては何度か述べたけど、
* 間違っていたものは正されるべき
* 人間は最初から正しいものだけを出せるほど賢くない
* 間違ったものを使い続けるよりは、正しいものに乗り換えるコストを払った方がマシ
という考えですね (特に第2項は重要)
『iPhoneは、窓から投げ捨てて他社の電話器に買い換える事ができる自由なハードウェア』みたいな話かもそれ＞＜
実際に iPhone 上のデータを完全に抽出したり移動できるならその通りで、 Mastodon では実際にそれができます。
何故なら OSS だしデータベースは管理者(理想的には個々のユーザ) の手元にあるので。
ロックインにも2つくらい段階があって、「代替があるのに完全な移行が封じられている」という場合と「代替はあるが移行は面倒」という場合で。
自由を語るなら重点的に論ずるべきは前者ですよね。
後者は自動化すれば「面倒」は相応に軽減できるので。
で、後者の「面倒」をあたかも越えられない障壁であるかのように語るのは、ユーザの責任転嫁に過ぎないのではと
WindowsはPCごと投げ捨てて自由なOSがインストールされたPCに買い換える事ができる自由なOSであるでもいいかも＞＜
それを自由って言うの実用上の意味無いかも＞＜
https://mstdn.nere9.help/@orange_in_space/101637425225408503
Windows 上のデータを全て抜き出せる (あるいは必要な仕様がすべて公開されている/隠蔽されていない/意図して利用を困難化されていない) のであれば、実際に Windows はロックインしていないといえるのでは。
仮にそうだとした場合、ロックイン状態を発生させるのは Windows そのものではなく「Windows 専用アプリケーション」ですよね。
Windows がそれらのアプリケーションに対して他プラットフォーム対応をさせない働きかけをしているなら、それは Windows によるロックインといえるでしょうけど。
ロックインの発生についてプライマリに糾弾されるべきは、移行を禁じている原因そのものです。
それは何らかのアプリケーションだったり、それを利用することを強要する組織やルールだったりするけど。
でも、あわせて書いたコードはごみにされるよね？＞＜
オレンジが言う文脈上のロックインってつまり、乗り換える時になにかを捨てさせる事で乗り換えを阻もうとする事であって、それはデータに限らず、例えば特異なデザインにユーザーを慣らせて(場合によってはそれを知財として独占し)それを達成することもあるし、用語もそうであるし、プログラミング関連だとライバルが互換APIを作る事を阻むために色々する事も同様かも＞＜
その要素が乗り換えの自由を阻むものであることにはかわりない＞＜
それこそウンコ食う覚悟の話では？
Linux が自由だからといって、 *nix 系でない別の自由な OS に乗り換えたいならコード書き直す必要性は発生しますよ
https://mstdn.nere9.help/@orange_in_space/101637453197160112
結局、原理的障壁と手間の問題を混同しているのが良くないと思っていて、そりゃ手間も軽減されるべきではあるけど、そこは本質的問題ではない。
特許として保護するとか、知財として独占するとか、暗号化や難読化で意味の抽出を不可能にするとか、実用上困難なレベルまで面倒にするとか、たとえばそういうのが私の言う原理的な困難です
極端に言えば、データをエクスポートする事がとても困難なApple製品であっても、仮に情報を画面に表示する機能が存在するのであれば、紙と鉛筆で書き写す事はできる＞＜
「乗り越える事に支障はあっても完全に不可能ではない」事が自由に反しないと言ってしまったら、世の中の自由に関する問題とされるものの大部分がそうではなくなってしまう＞＜
https://mstdn.nere9.help/@orange_in_space/101637472799486610
これは結局手間の問題で、たとえば「別アプリのデータをエクスポートするアプリ」が書けて実行が許さればそれで済むし、それがリリースされれば人類全体としてのコストはどんどん小さくできますよね。
そういうアプリケーションが書けない/実行できないという本質的不自由をもってはじめて、 Apple 製品 (や、それら専用アプリケーション) がロックインしているというべき
結局、自由なプラットフォームなら自動化も可能なので、そこでは (ユーザ数に対して) 定数コストの自動化ソリューションによって、手間コストが償却できます。
なので、手間だけをもって移行障壁の発生をロックインと呼ぶのは妥当ではないと感じる
むしろ、大抵のプロプライエタリプラットフォームは、自動化の阻止によってロックインを図っているとさえ言えるのでは？ (要検証)
定数コストを償却という発想、情報のオタクっぽくてアレだな
結局、私の考えるロックインを間違いなく成立させる要件としては、
* 法律や社会制度などによる禁止や金銭障壁
* 暗号化や難読化による原理的なアクセス制限
+ (その弱い形として、仕様の非公開化)→法的制度などによる解析禁止と連携すると効力増加
* 自動化の阻止
のいずれか或いは複数が相当するのかなと
この話で思いだしたけど、RubyとWindowsの関係のMatzのぼやきもあれかも＞＜
WindowsはUNIXでは無いのでWindows版のRubyが(昔)作れなかったって話＞＜
(当時)RubyはUNIX依存の環境であり、UNIXの囲いこみの被害者かもしれないと同時に、もしかしたらそれを手伝った加害者でもあるかもしれない＞＜
(MatzはWindowsから閉め出されたように感じたっぽいけど＞＜)
*nix 依存が Ruby の API デザイン (perl か C 辺りを真似たんだっけ？) 由来なのか、そうでない何か由来なのかにもよりそう (詳しくわからないので何も言えない)
https://mastodon.cardina1.red/@lo48576/101589237254532054
たった今、うっかりしてインターネットお絵描きマンを「単純型付きラムダ計算完全理解マン」(公開リスト) に入れてしまった……やはりリスト煽り芸は危険
エラー型の設計が難しすぎるので内部表現を完全に隠蔽して誤魔化すことにしたが、結局内部表現をどうするかで悩んでいる……救いなんてなかった
マジで Box<(dyn std::error::Error + 'static)> にしてやろうか
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
https://pawoo.net/@akazawared/59543654
大昔の投稿にツッコんでもしょうがないけど、「全てのインスタンスにいる人の〜」は嘘でしょ
エッジケース考えれば自明じゃんと思ったんだけど、そもそもまともにモデル化ができてない人がエッジケースなんか思い付くわけないんだよな
「難しいことはいいから」みたいなこと言っちゃう人に正しく概念を伝える方法 (そんなものはない)
このアカウントは、notestockで公開設定になっていません。
KAZU氏用の文脈で読んでしまったので「半起き」でまたいつものかと思ってしまった
普段使いの Mastodon 鯖を ConoHa の 1GB で動かしてるマンです
twitter.activitypub.actor、みんなやろうとして、やばいと思って手を出さなかった禁断のやつか
このアカウントは、notestockで公開設定になっていません。
ドメインに商標使ってるのでヤバイと思ってる。自分が考えていたときはtwgateとかの名前にしようと思っていたし。
