仕事も趣味もなんか色々アレなので、精神衛生のためにマイクラでひたすら整地していよう

ちくわ大明神ですね(違う)＞過去のTLの印象操作
http://dic.nicovideo.jp/a/%E3%81%A1%E3%81%8F%E3%82%8F%E5%A4%A7%E6%98%8E%E7%A5%9E

このアカウントは、notestockで公開設定になっていません。

ところでSTは意識的に「TLをソートしない」つまりストリーミングAPI使用時も取得順にすることを意識してました。ストリーミングから来たトゥートがTLに挟まれると見た目上スクロールがずれた位置に飛んでしまうことが発生するからです。公式Webでもそんな挙動は起きてますが、私はコレが嫌で嫌で仕方ない。
snowflake IDの影響でこれがどう変わるかはまだよくわかっていません。since_idに影響しないならソートせずに今のまますませたいところです。

もういろいろ分からんので、わざと時刻をずらしたテストサーバつくるしかないな…

このアカウントは、notestockで公開設定になっていません。

時刻を取得してからDBに記録するまでがトランザクションになってるかどうかかな

まあこっちはまだクライアント側で対策できなくはない

差分取得だとリモートからのトゥートが漏れることがあるのはもうそういうものだって感じなのかな…

@unarist @Clworld @Gargron we should show toots in a few seconds, minutes, hours. but in case of refrehing with since_id and snowflake, it's difficult.
the users may post claim about "fetching leak".

@unarist @Clworld @Gargron if just add option to account/tag query to get order by publish date, then other TL maybe has no problem ? because home and public tl has not enough length to hold 3mo.

むしろアカウントTLだけ投稿時刻順にすれば全て問題なかったのでは…

ていうかストリーミングAPIは正しく動くのかコレ？

リモートからきたトゥートを時間順に表示したいだけならやっぱり「未来のトゥートは表示しない」が最適解かな。ストリーミングで受信したときは数秒以内ならバッファに貯めればよし。

TLに現在時刻より新しいトゥートがでなくなれば解決！

（錯乱している

そもそもどんな目的でsnowflake IDを導入したんでしたっけ…？ ああ、クライアントは常に現在時刻をmax_idに指定すればいいんですかね？

過去の方に数秒遅れましたとかならまだsince_idズラす設定を設ければユーザが調整できるけど、やっぱり取得漏れとクレームがでるのは避けられなさそう。

時間の偽装はサーバがトゥートをインポートする時にクリップしてもらわんとどうにもダメそう。クライアントがTLを取得したら最新40件の全部が未来の時刻でしたってなったら、差分取得でsince_idをどう指定するべきかクライアント側では決められなくなる

TLのpull to refreshするときにsince_idの指定も少し余裕を見てマージンつけるとかしないと、また取得漏れがどうとかいわれかねないかな。またタンスのバージョンみて挙動を変える部分が増えるかな。

さすがにこの問題はアプリ側では対応できないよ

このアカウントは、notestockで公開設定になっていません。

@Clworld 逆に未来からのトゥートは常に頭の方に出るの？since_id的に致命的じゃない？

rcがいくつ続くかもわからんし、rcで新機能ぶっ込んできた前例もある

2.0対応したって謳うのは2.0でてからにした方がよさそげ

EOS M100 を予約したー。レンズはEF-S35mmマクロ。LEDついてるのを使ってみたいだけ

このアカウントは、notestockで公開設定になっていません。

@masarakki ゼロ幅スペースをコピペで入力すればオッケー