Closed Johann150 closed 1 year ago
This could be implemented as a not really breaking change by checking the nodeinfo of an instance: nodeinfo.metadata.features.includes('chat') || nodeinfo.metadata.features.includes('pleroma_chat_messages')
. I'm not yet sure what the difference between chat
and pleroma_chat_messages
is, or if there even is one.
It would probably require additional complexity, but would also allow us to tell a user if an instance does not accept chat messages so that they know for sure that the message will not arrive. If it is detected that chat messages do not work, misskey UI could recommend using direct notes instead.
edit: nodeinfo.metadata is not the right place to check. The ActivityPub Actor information contains capabilities.acceptsChatMessages
set to true
if chat messages are possible to send to an actor.
I don't think is a breaking feature. You just need to add a check on the federating server by reading softwareName
.
If it's misskey, pleroma and calckey it can work with full featured chat.
If federating serverName
is mastodon or other, the feature should fallback using actual note _misskey_talk
Pleroma's chat APIs https://api.pleroma.social/#tag/Chats
obsoleted by #9919
π‘ Summary
Currently, Misskey chat messages are delivered the same as direct/
specified
notes. To differentiate chat messages, Misskey only adds a non-standard_misskey_talk
key to the messages which signifies to other Misskey instances, that a message is supposed to be a chat message (see implementation). This means they can be easily federated to other activitypub software, even if they do not have a chat feature (e.g. Mastodon) or implement it differently (e.g. Pleroma).However, this could be problematic, because if the message shows up as a direct note on the other side, the user could interact with it as with a normal note. This includes for example adding another person to the message with an @ mention. Misskey can not handle this correctly. Even without breaking Misskey, due to e.g. Mastodon not understanding the Activity fully, the user experience is poor. For example:
π₯° Expected Behavior
Replies are delivered correctly, even if the other user does something unexpected. Replies are rendered as appropriate for a chat.
π€¬ Actual Behavior
Replies may not be delivered at all. Replies may be rendered weirdly.
π Steps to Reproduce
π Environment
Misskey version: 12.108.1
π§ Proposed solution
I think these problems could be resolved by adopting the same federation behaviour as Pleroma, which is described in their documentation. In summary: Instead of adding non-standard
_misskey_talk
to an ordinaryNote
object, use a non-standardChatMessage
object that is separate fromNote
, and will be handled appropriately by servers that understand it.π disadvantages
ChatMessage
π advantages