神楽坂しえる @Clworld@md.ggtea.org

masterにしよう(決意) "Allow mounting arbitrary columns" / https://github.com/tootsuite/mastodon/pull/3207

む？

PushUpdateWorkerのPRがmergeされたのでやっぱりMastodonは1.5の方向へ向かっているっぽい。

思えばPaperclipがデータを保存する瞬間にリモートの画像取って来たりImageMagickとffmpeg動く時点でいろいろ厳しいですね…

ところでSidekiqでトランザクション切るのはいいとしても、BoostのStatusを作る -> 元のステータスを取りに行く(https) -> 失敗したのでrollbackする ってどうなの…(無駄にトランザクションが長い)

「StreamingAPIのendpoint取得APIがないぞー！」
A. 「誰もPullRequestを投げてないのである！」

Mastodon 1.4.2へ向かってるのか1.5へ向かってるのか謎

つよい

ついったさんはNSFWがアカウント単位なこともおかしいんだけど、NSFW自動表示設定が1ボタンで出来ることもなかなか気が狂っている

@qiitadon ちなみにですが全てのクライアントが301に対応しているという保証はないです(mstdn.jpに対してだけハードコーディングで対応している可能性はけっこう高いです)

SubwayTooterの通知リスナは301が返ってきたらそのredirect先にアクセスしに行く挙動になっています(汎用化ばんざい)

traffic的にwebとstreaming分けたいというのは分からなくもないのでつらい

@qiitadon Qiitadonなのですが https://qiitadon.com/api/v1/streaming/ にアクセスした場合に404が返ってくるためStreamingAPIを使用するクライアントで問題が発生します。
同じようにstreamingサーバが分かれているmstdn.jpはhttps://mstdn.jp/api/v1/streaming/以下にアクセスした場合にhttps://streaming.mstdn.jp/api/v1/streaming/へ301リダイレクトするように設定されています。
同じように301リダイレクトするように設定して頂けませんでしょうか？
ちなみにMastodon開発者のGargronさん的にはSTREAMING_API_BASE_URLは開発目的用で本番環境での使用は想定していないようです。 https://github.com/tootsuite/mastodon/issues/2068#issuecomment-295350433

実際のところmstdn.jpは
https://mstdn.jp/api/v1/streaming/
にアクセスされた時に 301リダイレクトで
https://mstdn.jp/api/v1/streaming/
に飛ばすのでStreamingAPI使うクライアントは301リダイレクトをハンドルする必要があるみたいな状況になっている(streaming_api_base_urlを取得するAPIは無い)