Mastodon 要望トピック


#24

Adminの管理画面「ドメインブロック」に検索機能があると良いなと思うことがあります。
ドメイン単位でブロックやサイレンスを設定する理由は様々あると思いますが、その設定を解除したり、設定内容を見直したい時に便利かなと。
このような処理は使わないに越したことないんでしょうけど、アカウントの検索はできるので、ここもできると嬉しいです。


#25

以前 @userbame@twitter.com をプロフィールなどに書いたときにリンクとして機能してほしいという要望が github の方にあった覚えがあります。
追記: https://github.com/tootsuite/mastodon/issues/1849

ですがtwitterだけサポートするというのは駄目だと思うので管理画面から 特定のドメインの場合管理者が指定したフォーマットでリンクを貼るように展開する みたいな機能があると嬉しいです。
また管理者が許容したドメインのフォーマットを一つ一つ設定するのは大変なので http(s)://{domain}/{username}http(s)://{domain}/@{username} が標準で使用されると嬉しいです。


#26

Twitterみたいに、キーワードでミュートできる機能がほしいです。

とあるインスタンスのLTLを見ていると、あるユーザの名前が入ったトゥートが結構流れてくることがあるのですが、私はそのユーザが嫌いなので、その名前をミュート対象のキーワードにして、それらのトゥートをLTLから見えないようにしたいと思っています。

また、CW機能の見出しで「閲覧注意」や「コンプラ」などと書いてるトゥートもよく見かけますが、注意書きがあるにも関わらずつい開きがちで、内容を見て結局後悔することが多いので、そういう見出しもミュート対象のキーワードとして、トゥートを非表示にしたいです。


#27

プログラム開発に関わっていない人だととっつきにくさが有るかもしれませんが、正規表現フィルターで設定ができます。

書き方が難しいので、みたらしだんごさんが作られたツールとかを使うと便利かもしれません。
https://tools.matcha-soft.com/donfilter/


#28

ハッシュタグで記号を使いたい

現在Mastodonでは基本的に、「#」に続く文字列に記号があるとハッシュタグとして認識されずそこで途切れてしまいます。

例:&!☆・、。 ()

「#」以外の記号がハッシュタグとして認識されるようになると便利になり、Mastodonを使うメリットにもなると思うのですが如何でしょうか。


#29

スペース以外は(全角半角も関係なく)全部繋がって欲しい、みたいな気持ちはありますね。
URLに含まれるハッシュタグの扱いが難しくなってくるのでしょうけど・・・。


#30

私も個人的にはタグなどは空白だけで切れればいいと思っていますが、多くの一般ユーザは URL やハッシュタグなどを空白で分離する習慣がないらしいということが経験的にわかってきたので、そういう仕様にすると意図せぬタグが大量生産されてタグの有用性がしばらく低下する気がしています。
ちゃんとアナウンスできればそれで済む話かもしれませんが……(どれくらいの人が読むかな)


#31

ちょっと要望とは違うんですが混乱したのでご意見を伺いたいです。(考えがまとまらなすぎて本家issueに書けなかっただけとも言う)

https://github.com/tootsuite/mastodon/pull/7057 にて、API経由での投稿の場合で、sensitiveパラメータ(NSFW用の設定)が与えられていない場合に、設定の「メディアを常に閲覧注意としてマークする」を参照して設定する変更がpull-reqされ、mergeされたようです。

この変更は、WebUIの挙動と既存サードパーティクライアントの挙動で食い違う、設定画面での説明がおかしい、APIドキュメントとの不一致、というような問題を引き起こしてしまうと思うんですが、かといって単純に撤回を求めるのも変な気がしています。

この変更後は、API経由の投稿だとメディア添付もCWもないtootでも、そう設定されていればフラグが立ってしまうんですね。WebUIからの投稿ではフラグが立っていないので、恐らく明示的にsensitive=falseを与えているのだと思います。

APIドキュメント https://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#posting-a-new-status では、sensitiveパラメータは省略可能だとされていて、そうだとすればドキュメント通りに作ったクライアントがWebUIと整合が取れず、しかも設定画面の説明がおかしいことになってしまいます。

考えられることがいくつかあります。

  1. APIドキュメントが最新の状況にキャッチアップできていないのはいつものことであり、sensitiveパラメータを必須とする仕様変更だと解釈するべき?
  2. 設定画面の説明がおかしく、英語版でも"Always mark media as sensitive"となっているのを、メディアとは無関係な文に変更するべき。そもそもCWでフラグが立つ時点でおかしいのでは?
  3. (こういったpull-reqが来るくらい、サードパーティクライアントからはsensitiveを明示的に送ってこないことが多い、という仮定の下で)サードパーティクライアントでsensitiveフィールドを参照してフィルタリングすることが可能だが、こういった(結果的に)無差別なsensitive付与は本来見たかったtootまでフィルタで見えなくさせてしまう。
    WebUIではメディア添付もCWもないtootにsensitive指定することはできないが、mastodonで官能小説を連載しようとする人が、他のユーザがサードパーティクライアントでうまくフィルタできるようにする目的で、サードパーティクライアントを使って明示的にsensitiveフラグを与えることもできるはずで、「メディア添付もCWもないtootにsensitive指定する」こと自体がナンセンス、とまでは言えないのではないか?考え過ぎ?

取り留めのない文章で恐縮ですが、何か思う所があれば返信ください。


#32

NSFWは設定画面の説明と同じくメディアにつくものという解釈だったので、トゥートだけでもフラグが付いているのには違和感を覚えますね。
またAPIとWebUIで挙動が違うのは、混乱の元になりそうな気がします。
マージされたということで、機能としては問題なしという判断なのだとしたら、ドキュメントまわりで説明しておくのは必要かもしれないなと思いました。

ドキュメントが後手後手なのはなんとかしたいと思いつつ、英語の壁が・・・。


#33

最近アクセストークン無しのAPIリクエストを色々試しており、いくつか取れないデータがあったのですが、これらについてご存じの方はおられますでしょうか。
基本的に静的ページで閲覧できる情報については、トークン無しでもいいような気がしますが。。

  • /api/v1/accounts/:id
  • /api/v1/accounts/:id/followers
  • /api/v1/accounts/:id/following

取り敢えず見つけたのは上記3つです。


#34

以下は要望を満たしますでしょうか?

補足ですが、ActivityPub としては、拡張子 .json を削るかわりに HTTP のヘッダーに Accept: application/activity+json を付けると上品になります。


#35

API以外にも拾ってくる方法があったんですね。ありがとうございます!