のえる DTP鯖管 @noellabo@dtp-mstdn.jp

タイムラインが遅いとは。
（平常運転）

pyOpenSSLの問題は、昨晩発生していたので対処したところですわ。面倒くさいね!!

オレならこういう実装にするぜ！ っていうのをプルリクぶん投げて納得させる……ぐらいの技術をまず身につけねば……

広告表示必須のTwitterで、WebUIや公式アプリを強制しなければならない事情はわかる。

Mastodonは果たしてどうか。WebUIに縛り付けるべきか。

アプリで一通りのことができるようにしたい、というのはあります。WebUIを完全に代替したい。

endorsementだってそうだし、exploreだってそうだけど、APIがないものは無くしたい。

設定項目で同期できないものが多数あって、デフォルト公開範囲とか色々面倒くさいことになっている。

reCAPTCHA導入できる（改造できる）人は、登録APIを無効にするのも簡単なので、面倒みなくてよくね？ ってのはある。

スジの悪いところとしては

「インスタンスの説明」「カスタム詳細説明」「カスタム利用規約」にHTMLが使えて、WebUIの特定の場所に表示されることを前提に利用されている、というところ。

「短いインスタンス説明」は1段落という制限があるものの、実はHTMLは書ける。

もっと広い視野で、サイトのカスタマイズ用という見方ではなく、意味に基づいた、再利用性の高い設定項目になっていないと、利用しづらい。

アカウント作成APIの件、思ったことなど。

身勝手なアカウント作成bot（スパム）に対抗するためには、APIのレート制限とメール承認フローがあり、ここに規約の確認フローを追加しても（この観点からは）利益がない。

APIベースの規約確認フローにreCAPTCHA相当の強度（botにとっての突破の面倒くささ）を持たせる有効な技術的解決手段が提案されていない。

アカウント作成前に、ユーザーから規約への同意の明示的確認をとること。これはWebUIでもやっていないので、WebUIにも実装して一貫性を持たせる方向でプルリクした方が筋が良いかと。

行儀の良いアプリ実装と、適切なサイト設定を促す、開発者と運営者向けのドキュメントを整備する。

必要であれば、設定項目や項目の表記、補足説明、追加や削除を検討し、「この項目に何を記載すべきか」「いつ、どの項目をアプリから利用すべきか」を整理する。

一貫性という観点から、オイゲンさんからみて、WebUIとAPIは同等であるとみなされている。APIをオフにする代わりに、登録を閉じる（招待に限定する）ことができるので、それで足りると考えられる。

@panorama_box 欲を申しますと、

httpsには対応しておるのですが、httpでも見えるのと、リソースのリンクがhttpなので、

httpsを強制するプラグインを使ったり、リダイレクトして、httpsオンリーの表示にすべきかと思います。コンテンツの方はwp-cliで一括置換しちゃったり。

そのへんは、たぶん詳しい人がいっぱい居て教えてくれるはず！w

ベラボーマンにしても、シュビビンマンにしても、様式美がある。生半可ではダメ。

ソニックブラストマンみたいなのも嫌いじゃない。

もちろん、ワンダーモモも好きですよ！？（実は割と熱い歌である）
へんしーん！！
https://youtu.be/KD5USEPQueg