Implement message federation and redesign message view #830
Conversation
- add a migration to add an uuid and an ap_id to the message table - add a message controller to retrieve messages by their uuid - remove the access denied exception when sending a message to a remote user - add `Message` to the `ActivityFactory` so `CreateMessage`s can be dispatched for messages - fix context endpoint so it is only one array with values - make `ChainActivityHandler` handle messages as well
- give the message view a chat like style
- instead of using the `inReplyTo` field we just match the participants now, because lemmy doesn't support that - fix wrong array building in `isActivityPublic` method - remove `ChainActivityHandler` code for chat messages, since we do not have the `inReplyTo` field, the message will never bounce to it
BentiGorlich
added
enhancement
|
Mastodon private mentions will be implemented separately and will probably not use our message system, but will be represented as a normal post (regardless of which type) with a visibility of |
|
@nobodyatroot @e-five256 @melroy89 should I implement messages with more than 2 participants or is that too much for this PR? I don't think that lemmy supports it, but implementing it shouldn't be that hard. The rest of the code should already handle infinite number of participants |
that sounds like a cool Mbin specific thing as long as it doesn't break 2 participant message compatibility with lemmy. i'll leave it up to you if it's too much work for the PR since you're doing all the work ;-) |
|
I'll check if lemmy support breaks when there is more than one user in the |
- when a lemmy user edits a message it now gets applied - improve messages front - save the ap_id of incoming messages - hide the sidebar when in mobile view (it previously got put at the end of the side, now it just gets hidden)
This comment was marked as outdated.
This comment was marked as outdated.
- consolidate the 2 migrations into one - use `ChatMessage` type for handling messages, like it should be
|
|
||
| private function handlePrivateMentions(): void | ||
| { | ||
| // TODO implement private mentions |
There was a problem hiding this comment.
Not for this PR, but for later, yes
There was a problem hiding this comment.
Sure OK. I understand. I just wanted to point it out, you never know. right?
This PR implement federation for messages. They use the AP type
ChatMessagewhich is not part of the AP standard, but is used by Lemmy and Pleroma. The main goal is interoperability with Lemmy.Lemmy does not support it and we do not have a way of distinguishing between the lemmy and mbin servers. The backend works for multiple participants, but I did not add an option in the UI to start a thread with multiple participants. I want it to show a warning when a lemmy user is part of a multi thread
Redesigned message view:
Overview:
Chat:
Only the middle part scrolls and the view will scroll to the bottom when loaded