神楽坂しえる(テスト用) @Clworld@mdx.ggtea.org

@unarist ぉー😅

@unarist このatomUri Boostした先にも投げでもしないとBoost先はだめなやつですねもしかして…🤔

@unarist なるほど…

複数プロトコルで来た時でIDが相互変換不可の場合 Boostのdedupは解決不能問題ぽい

1. Statusにプロトコルを持つ
2. dedupはしない(出力側で重複は消す)
3. Salmonのような通知する処理はStatusが持つプロトコルで行う
4. Boostは来た回数だけ表示する<- 🤔 🤔 🤔

たぶんSalmonを送る側は向こうがAPだと思っている結果、OStatusのURLに対する反応をAPで向こうに送ろうとしてIDがだめですって弾かれる訳ですかね

OStatus側をAPに寄せるのは合理的だけどたぶんしぬ(実装する人が)

Salmonが通らないというのは想定している経路とURIの組み合わせがまちがってて失敗するという話で良いのです？(ソースノールックです)

@unarist ぶれいきんぐ…

@unarist なんとかどうにかして同じとみなすしか🙀

@unarist 一意のIDかURLを何とかしないと…。

いやこれ今問題になってるのはAP/OStatus間のdedupが出来てないだけでdedupが出来れば通信量がで無駄が出るだけの影響で済むのか

master者なら適宜なんとかしてで済むけどこれリリースまでにどうマイグレーションするのかって問題な気がする

ForceUnsubscribeServiceが出来た😄

@unarist 「向こうが」APに切り替わった時点でUnsubscribeされるべきなような気がする(難しそうなタイミング問題)

@unarist あー判定で除外してあるのかー。

おー 二重受信きた

ぬー？

ふー