https://qnmd.info/@qnighy/112148716025333843
宇宙開発競争と同じ流れを想定するなら、むしろムーンショットなメモリ安全なプログラミング言語の開発競争が進みそう(?) [参照]
Mastodonが引用機能を実装すれば他の実装の表現もその方式に収束するのではないかと期待していたけど(<https://github.com/kitsune-soc/kitsune/issues/29#issuecomment-1766449402>)、本当にFEP-e232ベースで実現するつもりなのか。しかもlink relation typeとして`misskey:_misskey_quote`を流用するつもりはないと。良いね
@silverpill It defines Object Links, which might be useful to represent Quote Posts, but are not Quote posts. Our proposal will probably be based on it (and suggest some changes to it due to possible issues).
We know Threads implemented support this way, we are in touch with Christopher. It is a temporary implementation on their side using what is currently done by some implementations.
I said it several times, but with Ivory's latest announcement, let me repeat it: we (the Mastodon team) are working on implementing Quote Posts. This is a much more complex feature than showing a preview for a link to a post, which is done at the moment by multiple clients.
It is a complex task and we have been working on defining the feature and the protocol-level details for some time. We are moving forward, and there are fewer hard questions to answers, but progress is there.
Threads has entered the fediverse - Engineering at Meta
https://engineering.fb.com/2024/03/21/networking-traffic/threads-has-entered-the-fediverse/
> Misskey created its own solution with its `_misskey_quote` property, which builds on FEP-e232.
これは逆で、確かFEP-e232の方がMisskeyの引用機能の一般化なのであって、その枠組みで引用機能を実現している各種実装が慣習的にlink relation typeとして先行実装であるMisskeyの`misskey:_misskey_quote`のURIを流用しているという経緯のはずだよね
仮に文脈を掴めない投稿が流れてきた場合にそれがローカル限定投稿絡みなのか否かを考えるのが面倒そうだから、寄り合い所帯のMisskeyインスタンスとその他の実装の両方にアカウントを持っている人たちについては後者を優先してフォローしているところがある
MastodonからMisskeyアカウントをフォローしていない、避けている理由としてどんなものがありますか?(複数回答)
候補に理由がある場合はその他を選んで返信で追加してください。
Stabilize associated type bounds (RFC 2289) by compiler-errors · Pull Request #122055 · rust-lang/rust
https://github.com/rust-lang/rust/pull/122055
おお、mergeされている
`misskey:_misskey_quote`とFEP-e232(Object Links)の関係とかもそうだけど、Activity Vocabularyってやつはよく作り込まれているのでアドホックな拡張プロパティを使わずとも既存の仕組みの上で上手く定式化できる範囲は存外に広いのだけど、何やかんやで現実の実装はそうならないことが多いというアレ
FEP-fffd(Proxy Objects; <https://codeberg.org/fediverse/fep/src/branch/main/fep/fffd/fep-fffd.md>)は紆余曲折を経て`url`プロパティの本来想定されていたであろう使い方の再定式化のような形に落ち着いたけど、こうして見ると`url`プロパティの命名の微妙さが際立つな。Activity Vocabularyにおける用例を見ても`Link`オブジェクトの置き場としての用法が想定されていたことは読み取れるわけだし
この方はただの例です