><https://twitter.com/orange_in_spacehttps://pawoo.net/@orange_in_space
機能拡張の面で言うと、将来その鯖のマストドンの鯖のバージョンを上げた時にその鯖のユーザーは名前衝突されたら困るのでという面の一方で、予約文字列による特殊なユーザー名のユーザーも、ActivityPubなりOStatusは喋れなければならないんだから、マストドン以外から見て特殊に見えなくても問題ないというか、問題ないように実装しなければプロトコル無視ってことになって大問題かも><
規格上の予約アドレス、RFC2142みたいな。一般的なサービス、役割、機能に対するメールボックス名http://rfc-jp.nic.ad.jp/rfc-jp/RFC2142-JP.txt
両方にある方がいいと思うけど、今の話題的にはマストドンの将来の機能拡張の話なのでマストドンの方><
それは丼にあった方がいいのかAPとかにあった方がいいのかどっちだろう
例えば(あくまで問題の例示として)さっきの公開LTLトランスポンダをマストドンの新しいバージョンに公式につけるとして、アカウント名を例えばltlって名前にしたら、そのアカウント名を使ってたltlさんが困る><例えば例えば規格上"_sys"で終わるアカウント名は予約文字列なのでユーザー用には用いてはいけないと規格上定義しておけば、ltl_sysであれば安全に使える><
デフォルトでどうとか設定で追加できるって話じゃなく規格上の予約アカウント名を用意すべきだったかもって言いたい・・・>< example.comみたいに、その目的で使用しても将来的にも過去の互換性的にも問題無いと規格上保証される予約文字列><
めげてきた・・・><
通報どうすんだ問題の時もそうだけど、マストドンでシステム用の予約アカウント文字列を用意しなかったの、ものすごく先見の明が無くてすごくアレ><
例えば @ publtl @ [ここに主催インスタンスのURLが入ります] にリプライ送ると、その publtlってアカウントが自動でブーストする>< それだけ><
ていうか、ざぼすてっく?とかで、「公開LTL(?)ブースト トランスポンダ アカウント」って作ればいいのでは感><(ホワイトリスト式にしないとムトーの騒動みたいなのがアレだろうけど><)
専用インスタンスよりもタグTLによる住み分けのほうが流行ってほしいにゃーん
がんばりすぎるとウェブブラウザのUAみたいになりそう><;
投稿内に書かれた投稿URLであれこれするやつを書いたりもしたんだけど、取得してみないと投稿URLかどうかわからなかったりしたので、区別つくのはいいわねという感じはする(ただその場合mastodonよりOS/APってことを伝えたい気もする…。
でもそれだと以下略
web+mastodonプロトコルを登録すると、そのアドレスを開いたときにいきなりマストドンで開くことができるのだ!
例えば mstdn://nere9.以下略とか書けても、そこが普通にウェブブラウザでアクセスできるhttpsなサイトであるかなんて解釈のしようが無いじゃん?><
それっぽさ?><(オレンジの趣旨的には、継承構造にすれば、専用クライアントがある環境であればそれで開くけど、無ければより抽象的な、さっきの例で言うとウェブブラウザで普通のhttpsなhtmlで表現されているウェブサイトとのやり取りの為のURLと見なすみたいに、専用クライアント有り環境と無い環境で同じURLを使えるのが・・・・><)
web+mastodon://の話?(なおカスタムプロトコルハンドラはmasterで没られた
例えば v2-mstdnapi-https みたいなスキーム名(?)を書けたらいいのにって言いたかった・・・・><
oh...
思考の /dev/null