docs/API/chats.md for a description and API docs. Description is also given here.
Deletion of own messages
Removal of remote messages
Mark as read
Streaming endpoint for chats
Basic formatting: linkify
Make newlines work again
Fix unread counts
readendpoint for single chat messages
Check out enum type for notification types
Move notification migration code to migration and out of the Notification module
Move all after-transaction code to after the transaction
Chats: change id to flake id
ChatController: Mark-as-read rethought.
Chats are a way to represent an IM-style conversation between two actors. They are not the same as direct messages and they are not
Statuses, even though they have a lot in common.
There are no 'visibility levels' in ActivityPub, their definition is purely a Mastodon convention. Direct Messaging between users on the fediverse has mostly been modeled by using ActivityPub addressing following Mastodon conventions on normal
Note objects. In this case, a 'direct message' would be a message that has no followers addressed and also does not address the special public actor, but just the recipients in the
to field. It would still be a
Note and is presented with other
Notes as a
Status in the API.
This is an awkward setup for a few reasons:
- As DMs generally still follow the usual
Statusconventions, it is easy to accidentally pull somebody into a DM thread by mentioning them. (e.g. "I hate @badguy so much")
- It is possible to go from a publicly addressed
Statusto a DM reply, back to public, then to a 'followers only' reply, and so on. This can be become very confusing, as it is unclear which user can see which part of the conversation.
- The standard
Statusformat of implicit addressing also leads to rather ugly results if you try to display the messages as a chat, because all the recipients are always mentioned by name in the message.
- As direct messages are posted with the same api call (and usually same frontend component) as public messages, accidentally making a public message private or vice versa can happen easily. Client bugs can also lead to this, accidentally making private messages public.
As a measure to improve this situation, the
Conversation concept and related Pleroma extensions were introduced. While it made it possible to work around a few of the issues, many of the problems remained and it didn't see much adoption because it was too complicated to use correctly.
For this reasons, Chats are a new and different entity, both in the API as well as in ActivityPub. A quick overview:
- Chats are meant to represent an instant message conversation between two actors. For now these are only 1-on-1 conversations, but the other actor can be a group in the future.
- Chat messages have the ActivityPub type
ChatMessage. They are not
Notes. Servers that don't understand them will just drop them.
- The only addressing allowed in
ChatMessages is one single ActivityPub actor in the
- There's always only one Chat between two actors. If you start chatting with someone and later start a 'new' Chat, the old Chat will be continued.
ChatMessages are posted with a different api, making it very hard to accidentally send a message to the wrong person.
ChatMessages don't show up in the existing timelines.