@toneji 🎉
@osapon Halcyonェ
@mayaeh 同時に話すと、相手が二つの文脈を受け取ることになるので、一つずつの方が効果があるかも。
@mayaeh PC向けのアプリケーションでは、インストーラーってのがありますが、基本的にアレと一緒だと思うんですよね。同意しなければいけない文書を設定すると、それに同意しないといけない。(設定してなければ同意求める画面なし)。
InstallshieldとかInnoSetupとか懐かしい……。
既存のインスタンスの説明や規約のページ(about, more, term)はこの用途に適してないので、「インスタンス登録前の確認メッセージ」を設定する項目をつくって、それを表示するようにするのが現実的なのではないかと思います。WebViewへ遷移するアンカータグぐらいはいいけど、他のHTMLは無しね。前述の通り、空なら確認なしでOK。
アプリ開発者からみても、この確認メッセージを表示するのがベストだと思えば、使ってくれると思います。少なくとも既存のあれら(前述)をどうこうする面倒くささからしたら、提供されてれば使うでしょう。
APIレベルで何か細工するとしたら、確認メッセージはinstancesから取得して、そのハッシュ値を登録APIに渡す、とかすればいいんじゃないかな。
1周年を迎えたiMastのこれまでとこれから - rinsuki's blog
https://blog.rinsuki.net/articles/imast-3-1/ #dtp
@mayaeh 利用規約ですが、ソフトウェアのライセンスと同様に、公式で、広く共有されて、公知のモノであることで実効性を担保する、いわば「Mastodonインスタンス利用ライセンス」が存在していることに対する価値というのはあるかと思います。Discourseのプライバシーポリシーを下敷きにしてるんでしたよね。
それを置き換えるものとしての「カスタム」なので、実はあれ、割と重いのではないかと思っています。
デフォルト空っぽだし、特定言語でしか書けないし、カスタムすると劣化する面がある。
代案としては「独自の利用規約」「利用規約の独自定義」を挙げておきます。
スジの悪いところとしては
「インスタンスの説明」「カスタム詳細説明」「カスタム利用規約」にHTMLが使えて、WebUIの特定の場所に表示されることを前提に利用されている、というところ。
「短いインスタンス説明」は1段落という制限があるものの、実はHTMLは書ける。
もっと広い視野で、サイトのカスタマイズ用という見方ではなく、意味に基づいた、再利用性の高い設定項目になっていないと、利用しづらい。
@mayaeh WebUIからの登録と等価とみなせるので、特にコメントすることはない、ということかなー。
アカウント作成APIの件、思ったことなど。
身勝手なアカウント作成bot(スパム)に対抗するためには、APIのレート制限とメール承認フローがあり、ここに規約の確認フローを追加しても(この観点からは)利益がない。
APIベースの規約確認フローにreCAPTCHA相当の強度(botにとっての突破の面倒くささ)を持たせる有効な技術的解決手段が提案されていない。
アカウント作成前に、ユーザーから規約への同意の明示的確認をとること。これはWebUIでもやっていないので、WebUIにも実装して一貫性を持たせる方向でプルリクした方が筋が良いかと。
行儀の良いアプリ実装と、適切なサイト設定を促す、開発者と運営者向けのドキュメントを整備する。
必要であれば、設定項目や項目の表記、補足説明、追加や削除を検討し、「この項目に何を記載すべきか」「いつ、どの項目をアプリから利用すべきか」を整理する。
一貫性という観点から、オイゲンさんからみて、WebUIとAPIは同等であるとみなされている。APIをオフにする代わりに、登録を閉じる(招待に限定する)ことができるので、それで足りると考えられる。
@Yashima そうすると、1/3が本当のアクティブ、1/3が見てるだけ、1/3がアプリ等でログインしてるけど実際はみてない、ぐらいの見立てですかね、大雑把過ぎるけど。
統計する仕組みは単純なので、あとでウチでもう少し詳しく、このへんの数字が見えてくるような仕掛けを仕込んでみようかな……
@estpls 対応しとらんので、WebUIで見るしかないのでは……
DTP鯖管
さんがブースト
DTP・デザイン・印刷のテーマサーバ DTP-Mstdn.jpやってます。
#Illustrator #スクリーン印刷 #インクジェット #カラーマネジメント #運営
#searchable_by_all_users