improve messaging federation

[Johann150]

💡 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

1. Send Misskey chat message to a Mastodon account.
2. Mention a 3rd user (tested with a Pleroma user) in the reply.
3. Message does not show in chat or on the users profile on the Misskey instance when viewing the remote users replies.

📌 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 ordinary Note object, use a non-standard ChatMessage object that is separate from Note, and will be handled appropriately by servers that understand it.

📉 disadvantages

• ☢️ This is a breaking change: Chat will no longer federate between Misskey instances before or after this change because they will not recognize ChatMessage
  • ℹ️ it is still possible to write direct messages instead of chat messages
• interoperability with Mastodon and probably other Activitypub servers is also decreased
  • ℹ️ it is still possible to write direct messages instead of chat messages
  • ℹ️ Mastodon does not implement chats properly, so this particular interoperability may not be a good idea anyway

📈 advantages

• Misskey already handles chat messages and notes in separate tables and separate APIs (similar to the documentation for Pleroma linked above)
  • the API does not have to be changed
• interoperability with Pleroma Chat
• no errors or weird behaviour when the remote user does something unexpected
• messages are always rendered appropriately

[Johann150]

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.

[tassoman]

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

[Johann150]

obsoleted by #9919