12:31:04
icon

Switch Bluesky to opt out? · Issue #1471 · snarfed/bridgy-fed
github.com/snarfed/bridgy-fed/

Web site image
Switch Bluesky to opt out? ?? Issue #1471 ?? snarfed/bridgy-fed
12:36:26
icon

AT Protocol(というか`app.bsky.*` lexicon?)の性質を考えればオプトアウトの方が馴染むというのは総論として同意だけど、`!no-unauthenticated`セルフラベルやリプライ制御と、(特にアカウントの所有者本人によってセルフホストされた)他のブリッジとの重複への対応をどうするのか気になるな
QT: fedibird.com/@tesaguri/1132656
[参照]

Web site image
tesaguri 🦀🦝 (@tesaguri@fedibird.com)
Web site image
投稿の参照(1件) by tesaguri 🦀🦝 (@tesaguri@fedibird.com)
21:42:33
2024-11-15 16:27:06 Posting のえる noellabo@fedibird.com
icon

Misskeyは返信わかりづらいよね。

だいたいMastodonと同じことができるよって言えるんだけど、リプライツリー・スレッドについては厳しい。

21:42:36
icon

他人からのリプライについてはともかく、なぜ自己リプライ・スレッドまでワンクッションの操作を挟む仕様なのか気になっている表示も何か小さいし

21:43:07
icon

あと返信が1件もないときにも"Show replies"が表示される仕様も混乱しがち。いや、`GET notes/show`を呼んだときに`repliesCount`が`0`だったとしても後から`GET notes/children`を呼んでみればリプライが生えていることもそりゃありうるだろうけどさ……

21:52:27
icon

あと、どう取り繕っても悪口みたいになってしまうけど、Misskey APIの命名は全体的に英語として理解しづらいがち。
例えば今言及した`MiNote`エンティティも、他のプラットフォームでは`inReplyTo`とでも呼ぶであろう概念を単に`reply`という名前で指していたりするし……(単に"reply"というと、素朴にはそのノートに対して返信している他のノートのことのように思えてしまう)

21:55:51
icon

FirefoxとThunderbiredくらいしか開いていないのにメモリ不足になって何事かと思ったけど、Misskey Hubや<misskey.io/api-doc>を閉じたら2 GiBくらい空いた(?)

21:58:19
icon

どちらかというと後者のRedoclyの方が食っていたっぽいかな