＞＜
もちろん、(雑に言うと)Windows(というかNT)がそのままではUNIXでは無いのは、カトラーがそんなPDP-7にあわせて作られた一貫性の無いものなぞ参考にせずに古巣のDECの正しい製品群の延長で作ったからだけど＞＜
(APIの由来はあれだけど、少なくともRubyの話に関連するはずのプロセス/スレッドがらみの話はそう＞＜)
この話で思いだしたけど、RubyとWindowsの関係のMatzのぼやきもあれかも＞＜
WindowsはUNIXでは無いのでWindows版のRubyが(昔)作れなかったって話＞＜
(当時)RubyはUNIX依存の環境であり、UNIXの囲いこみの被害者かもしれないと同時に、もしかしたらそれを手伝った加害者でもあるかもしれない＞＜
(MatzはWindowsから閉め出されたように感じたっぽいけど＞＜)
仮にそうだとした場合、ロックイン状態を発生させるのは Windows そのものではなく「Windows 専用アプリケーション」ですよね。
Windows がそれらのアプリケーションに対して他プラットフォーム対応をさせない働きかけをしているなら、それは Windows によるロックインといえるでしょうけど。
https://mstdn.nere9.help/@orange_in_space/101637425225408503
Windows 上のデータを全て抜き出せる (あるいは必要な仕様がすべて公開されている/隠蔽されていない/意図して利用を困難化されていない) のであれば、実際に Windows はロックインしていないといえるのでは。
極端に言えば、データをエクスポートする事がとても困難なApple製品であっても、仮に情報を画面に表示する機能が存在するのであれば、紙と鉛筆で書き写す事はできる＞＜
「乗り越える事に支障はあっても完全に不可能ではない」事が自由に反しないと言ってしまったら、世の中の自由に関する問題とされるものの大部分がそうではなくなってしまう＞＜
でも、あわせて書いたコードはごみにされるよね？＞＜
オレンジが言う文脈上のロックインってつまり、乗り換える時になにかを捨てさせる事で乗り換えを阻もうとする事であって、それはデータに限らず、例えば特異なデザインにユーザーを慣らせて(場合によってはそれを知財として独占し)それを達成することもあるし、用語もそうであるし、プログラミング関連だとライバルが互換APIを作る事を阻むために色々する事も同様かも＞＜
その要素が乗り換えの自由を阻むものであることにはかわりない＞＜
実際に iPhone 上のデータを完全に抽出したり移動できるならその通りで、 Mastodon では実際にそれができます。
何故なら OSS だしデータベースは管理者(理想的には個々のユーザ) の手元にあるので。
WindowsはPCごと投げ捨てて自由なOSがインストールされたPCに買い換える事ができる自由なOSであるでもいいかも＞＜
それを自由って言うの実用上の意味無いかも＞＜
『iPhoneは、窓から投げ捨てて他社の電話器に買い換える事ができる自由なハードウェア』みたいな話かもそれ＞＜
まあロックインの第一歩としてそういったユーザの怠惰を利用することがあるというのは間違いないですが、だからといってユーザの怠惰の責任をなんでも実装に求めるというのは違うのではと
単にユーザが概念の更新や切り替えが嫌だからといって扉の開いた檻から出ようとしないのは、ロックインとはまた別の話 (たとえば「ユーザが不自由さに無自覚なのでまともな方に行かない問題」とでも形容すればいいのか？) だと考えます
https://mstdn.nere9.help/@orange_in_space/101637373525885069
ユーザが用語セットを切り替えることは妨げられないわけで、私はこれをロックインであると捉えていません。
たとえば最悪な話ではありますが、クライアントが独自用語で統一性を出すことも可能ですよね
自由ではないシステムに対する妥協かも＞＜
オレンジがこういう話とか、デザインを変更する時は土下座するつもりでみたいなのも同様にロックインの問題でもあるんだけど、
各個別の問題その物よりも、IT界隈の多数派の考え方が「新しい物はより正しい」「規格がコロコロ変わる一貫性が無い物を追う事が正しい」みたいな事になって結果的に自由に反している現状を変えたいと考えていて、だからこそあれかも＞＜
何らかの不都合があって、人々が自分の判断で妥協を選択したのであれば、その結果についての責任は不都合だけでなく妥協そのものについても追求されるべきという感じです (一般論)
まあ Mastodon がいくつかの面で理想的とは言い難いというのはそうなんでしょうけど。
だからといって Mastodon にまつわる問題の全てで Mastodon に責任があるわけではないという話なので、私はどちらかというと問題の元凶を追いたい感じですね
それ、目の前の分かりやすい問題で言うとサードパーティークライアントが「インスタンス」なり「toot」なりをどう表現すればいい？＞＜
マストドンの用語をそのまま使えばマストドンにロックインされてるのと同じ、
各サードパーティークライアントがバラバラに用語を使うと、今度はそのサードパーティークライアントにロックインされてしまう＞＜
iPhoneユーザーが他所の電話器に乗り換えるのに障碍があるのと同じように＞＜
むしろ、独自実装を当然そうあるものとして標準のように扱おうとしている人々が (そんなのがいるとすれば)、「自ら進んで、抜け難い檻を作ろうとしている」みたいな光景に見えます。であれば、ロックイン的現象を発生させようとしているのは、他ならぬサードパーティクライアント開発者ということになる。
であれば、その責任を Mastodon に問うのはちょっとおかしい。
Mastodon は標準が存在しない領域を独自実装で埋めていますが、これが標準になることを妨げるものは (規格化に携わる人々の知的労働コスト以外には) ほとんどないはずだし、標準が策定されればきっと Mastodon はそれに追従するでしょう (OStatus のみならず ActivityPub に対応したように)。
これは本当にロックインと同等であるといえるでしょうか？ 私はそうは思いません
オレンジ的には、現実にどう向き合うか？とか仕様に従う開発者としてみたいなことよりも、自由や分散の思想の面で見るとどうだろうって事の方が大事かも＞＜
じゃなきゃ結局自由に反し、分散せずに独占される考え方の陣営(？)の発想の方がどんどん広まっちゃう＞＜
具体的には、非標準や不安定に対しての認識が甘い/そういった機能を自覚的に使えない人々に対して、追加のコストを支払ってでも安定を提供すべきか、あるいはそういった人々の認識が正される/正しくない認識の報いを受けるべきか、という別の話です
ウンコ食わされうるような勇気ある行動をしている人々、当然ウンコ食う覚悟あるんだと思ってたけど、もし実はそうでもないのだとすれば、それは人々の標準や安定という概念に対する認識の不足の問題なので、また別の話ですね……
オレンジ的には、それが自由に反するソフトウェアやハードウェアが囲いこみするための行動と同等であり、自由を謳うソフトウェアであっても同様にそのソフトウェアが独占的に囲いこみしてしまうのであれば、トートロジーだけど、自由に関する重大な問題だと考えるかも＞＜
特にそれが自由を謳うソフトウェアであるならば、行動に一貫性が無いと言えるかも＞＜
分散を不可能にしようと振る舞ってる囲いこみ主義のソフトウェア、マストドンって事になるかも＞＜
私だってどうしても待ち遠しい機能が必要なときはウンコ食う覚悟をして unstable な機能を使うんですよ。それで実際にウンコ食わされたことだってある。
だからこそ標準から外れることに慎重になるし、標準として用意されていないものを標準と並べないようにするんです
ここで「待つべき場面が多い」という現状も含めての、 ActivityPub を取り巻く環境が early stage であるという話でもあります
https://mstdn.nere9.help/@orange_in_space/101637258937233748
なので、「待てない」というのを暗黙の前提にするのはフェアではないと思いますね
それを言ったら、そもそも ActivityPub が recommendation になる前に AP を実装しようとしていた人々もウンコ食う覚悟をしていたことになるわけですが、そこで待つ選択肢だってあったんですよ。
現状だってこれから先だって、規格が整うのを待つという選択肢は常にある。
待てない人がウンコを食う覚悟を決める。
そういう話。
・・・と言うことは、オレンジが最初に書いた通り、現状(つまり、待った先では無い)、マストドンその物に周辺機能も組み込む方向で考えるしかないってことだよね？＞＜
待てない人は汚物を被る覚悟をしてくださいということです (マジで)
つまり、本質的ではないサービスを外部サービスに切り分けるのも待つ？＞＜
それともTwitterAPIのごとく現状の仕様にあわせて作って、後にオイゲン氏が仕様変えてツイッタークライアントみたいに大量のコードがまとめてゴミにされるのを待つ？＞＜
これについては再三述べているとおり、「(ある程度安定したデファクトスタンダードに) 収束するまで待て」というお気持ちなので、現段階でそこまで大きく問題視していないです
その"我慢"こそ、発端の話である『周辺機能は外部サービスに・・・ができずに諦めてマストドンに実装するしかない状況』かも＞＜
標準が使い物にならないのであれば、標準をどうにかすべきなのであって、まあそれは理想主義と言われるかもしれませんが、私はウンコ食いたくないので料理ができるまで我慢します。あるいは私にできることがあるなら協力したいとも思いますが。
標準でないものを標準であるかのように扱うならば、その悪い性質について実装者が責任を持つのは当然に思われます
用語等に規格が無いから(こそ)、代表かもしれないマストドンが規格のような立場になってしまっているかも＞＜ しかも、オイゲン氏は一貫性の事なんて考えていない(インスタンス/サーバー)という不幸な状況であるのに＞＜
https://mstdn.nere9.help/@orange_in_space/101637197235703387
これについては私は「Mastodon と互換性がある」ように作ろうというモチベーション自体が既によろしくないでしょうという意見で一貫しているので、それだけの話ですね……
ていうか、そういう実例のとてもわかりやすい代表あったね！＞＜；
TwitterのAPIがそうだね！＞＜；
(マジで忘れてた)
超ショートカットして最初の話に戻すと、外部のサービスとしてマストドンと互換性がある各実装向けのものを作っても、オイゲン氏の気まぐれで、それが使い物にならなくなるよって言いたい＞＜
独占主義的なIT屋の製品サービス向けのソフトウェアと同様に＞＜
べつに規格にしたからといってロックインから免れるわけではない (むしろ規格の在り方によってはロックインを推進しうる) し、自然言語によるラベリングはむしろ「人々」マターであって、どうしてもというのであれば「UI の規格」を作るべきではという感じ。
まあその UI の規格策定を押し通した twitter が我々の目にどう見えているかというのは御察しの通りなんだけど
でも、どこかで規格に(標準化)するか、デファクトスタンダードを作り出してしまった者が一貫性を持つことにより、機能する(ある程度信頼して使用できると言い換えてもいい)デファクトスタンダードにするかしないと、結局独占になってしまう＞＜
結局のところ ActivityPub はプロトコルの規格なのであって、たとえばマイクロブログ以外の自然な用法がありうる (たとえばブログ記事や動画サイトの動画へのコメントなどを投稿として表現しうる) 以上は、 UI で使われるべき用語はプロトコルの規格で規定すべきでないという立場です、私は。
たとえば「業界団体」的なものが発足したり、メジャーな実装の実装者たちがどこかで議論をして、ひとまずこういう言葉を使いましょうと合意を取るというのが理想的なプロセスであって、だからこそ “デファクト” スタンダードとなりうるわけで。
UI や UX について規格が事細かに規定すべきでないという考えのもとでは、 user-facing な事項の用語ができるだけデジュレスタンダードであるべきだとは思いません
これ、皮肉なことにプログラマでも(もしかしたらプログラマ以外の人々よりも多い比率で)この文脈上のおろかな信者的ユーザーと同じ振る舞いをしてる人が大半だよね＞＜
でも、規格にしないで「単に実装の仕様なんです」って逃げて、それをコロコロと「改良しました！」と変えておろかな信者的ユーザーに「こっちの方が新しいし、古いのにこだわるのは老害」って言わせるの、自由に反するIT界隈の独占的な色々がやるロックインの手法の代表例でしょ？＞＜
それを『分散』のマストドンがやらかしてるのはどうなの？＞＜
合意というのは人々によって行われるべき事項であって、いち実装が責任を持てというのはおかしいかもしれないが、かといって規格がそれを明示すべきかというと、それは明らかにユースケースを制限することになりうるので危険そう
UX上の各情報が何を指してるのかわからなければ、ユーザーは操作不可能という実用的な問題があるよ？＞＜
例えばマストドンで言うところの「インスタンス」を「クルトン」と呼んでる外部サービスがあったとして「クルトンを入力してね！」とか書いてあっても意味不明で「コーンスープは関係ないだろ！？」ってなるじゃん？＞＜(今食べたい)
たとえば ActivityPub におけるイベントの単位は "Object" だし、投稿は "Note" 型のデータだったりするわけだけど、これをクライアントの UI において露呈しない、他の用語を用意するというのは十分に合理的に行われうるかと思います。
まあ "toot" が合理的かはまた全く別の話なんですが。
https://mstdn.nere9.help/@orange_in_space/101637061533052071
「○○を△△と呼ぶべき」という規定が明文化されて発行されたならばそれは規格だけど、そうでない UX 上の事項は単なる人々の合意、デファクトスタンダードに過ぎないわけであって、これは倫理観と合理的判断により当然多様性が発生しうるという考えです
「インスタンス」言うのやめて「サーバー」にする話でも、外部サービスがそれを「インスタンス」と呼んだままだったら、ユーザーはなんの事だかわからなくて混乱するよね？＞＜
そういう事も含めて、長期的に一貫性を持って約束して公言して規格にする事で、ユーザーはロックインされずに、自由に、分散されて、・・・・かも＞＜(語彙力)
オイゲン氏は約束せずに逃げてるとも言える＞＜
書いてて行き違いになったけど、各機能をなんと呼ぶか？も規格でありUXなんだよ？＞＜
これはクライアントアプリケーションが責任を負うべきものであって、そんで現状の Mastodon や Preloma 等は単にサーバとクライアントが一体で提供されているから境界が曖昧になっているだけですよね
https://mstdn.nere9.help/@orange_in_space/101637023117701712
そもそも UX への責任は AP サーバが持つべきものではないと考えているので、ちょっとこれはよくわからないです
投稿や引用等の名称でさえ統一された規格通りになってないんだよ？＞＜ マストドンが最初に出会ったSNSだったユーザが「短文投稿の事はtootというのか」と学んで外部サービスを使ったら例えば全部「レス」と書かれてたら「レスってなに？」ってなるでしょ？＞＜
みたいな状況なのに「インスタンス」って言うのやめて「サーバー」にするんでしょ？＞＜(それ自体は賛成だけど)
オイゲン氏、規格というものがなぜあるかなんてなにも考えてないかも＞＜
でも、じゃあ本当に規格化されていた部分だけを見て作ろう、マストドンの(長期的一貫性が無い)各振るまい各機能、それにどうにか互換性持った振る舞いを苦労して実装してるPleroma等々の各機能全部無視して、UXに一貫性があるもの作れる？＞＜
これはどちらかというと、いち実装を規格であるかのように神聖視しがちなアプリケーション実装者に責任があるように思われる (まあ “実用上” はそのように振る舞うことにも一理あるんだけど……)
この前もPleromaとか方面と、マストドンという『規格』で もめてたよね？＞＜
一方で、マストドンの問題として、マストドンがActivityPubとかから大幅に拡張した『規格』になってしまっていて、かつ オイゲン氏はそれを規格のように考えていない(仕様に長期的一貫性が無い)ので、マストドンその物に組み込まないと、横断的に一貫性があるUXを持つような(外部の)仕組みを作れないかも＞＜
これ基本的にはそうだと思うけど(オレンジがソフトウェアのアップデートに関して現状がおかしいって言ってるのもそれに近い話だし＞＜)
https://mastodon.cardina1.red/@lo48576/101636921831378331
まあこれは「本質的機能とそうでもない機能を混ぜると、後者を前者であると勘違いする輩がテキトーなことを言い出す」みたいな人間のアカン面の表出を未然に阻止したいというような気持ちも若干あっての考えでもあるけど……
もっと別の言葉で表現するなら、機能への責任はもっと明確に分解されるべきだという話になるかも。
fediverse やそれに参加するための人間用サーバは、 ActivityPub により交換される情報や交換機能を提供することを第一とするのであって、他の機能をプライマリであるかのように喧伝するのは危険な気がするし、そういった「プライマリでない機能」を、ある程度特化してその機能提供に責任を持てるような別実装に委託するのが自然に見える (ﾎﾟﾖｸﾞﾔﾏ並感) #distsns
結局人間的にはハブは欲しくなるんでしょうけど、ハブは fediverse やそれに参加するための実装から直接に提供されるべきでなく、交換可能かつオプショナルな形で外部的に提供されることができるはずだ、という考えです #distsns