Conversations Improvements

shpuld commented

2019-12-23 10:08:01 +00:00

Owner

We've had a first taste of utilizing the conversations api in applications now. Pleroma FE has a MR for it and Kenoma is almost in the same boat. There's some UX worries that have to be sorted out that aren't just frontend or backend problems I think.

Conversations timeline: It gets very confusing when there's more than 1 'conversations' with the same person, most chat applications don't allow this sort of behavior and instead all messages with a single person are in one continuous timeline. Should we just deal with it or figure out a solution?
Participants being dropped or added during conversation: tagging users makes no sense in chat context, addressing should be done purely by members list in the current conversation. There might be some other solutions for this as well but we can't do the conversations list in a sensible way if the addressing can change per message.
Public threads turning into dms: this is the big one, you can end up with completely nonsensical "conversations" where most of the messages were never addressed to you, but it's still your conversations because someone sent a dm reply to you in that thread. I think in these cases the conversation should only return the dms that have been addressed to you and nothing else. Some context could be added on top saying that "this conversation started as a reply to some public post" or something.

Without addressing these problems I think the conversations is a worse experience in pretty much every single way compared to current DMs. I do want to see this feature done well so that pleroma and fediverse in general can closer to competing as a good free chat platform.

We've had a first taste of utilizing the conversations api in applications now. Pleroma FE has a MR for it and Kenoma is almost in the same boat. There's some UX worries that have to be sorted out that aren't just frontend or backend problems I think. - Conversations timeline: It gets very confusing when there's more than 1 'conversations' with the same person, most chat applications don't allow this sort of behavior and instead all messages with a single person are in one continuous timeline. Should we just deal with it or figure out a solution? - Participants being dropped or added during conversation: tagging users makes no sense in chat context, addressing should be done purely by members list in the current conversation. There might be some other solutions for this as well but we can't do the conversations list in a sensible way if the addressing can change per message. - Public threads turning into dms: this is the big one, you can end up with completely nonsensical "conversations" where most of the messages were never addressed to you, but it's still your conversations because someone sent a dm reply to you in that thread. I think in these cases the conversation should only return the dms that have been addressed to you and nothing else. Some context could be added on top saying that "this conversation started as a reply to some public post" or something. Without addressing these problems I think the conversations is a worse experience in pretty much every single way compared to current DMs. I do want to see this feature done well so that pleroma and fediverse in general can closer to competing as a good free chat platform.

lambadalambda commented

2019-12-23 16:27:25 +00:00

Owner

Very good observations.

I'm ambivalent about this.
If you use in_reply_to_conversation_id, this is exactly what happens, you can mention people but it won't change the recipients of the message. See https://git.pleroma.social/pleroma/pleroma/blob/develop/docs/API/differences_in_mastoapi_responses.md#post-apiv1statuses
I agree, it's very confusing. The solution you describe seems good.

Very good observations. 1. I'm ambivalent about this. 2. If you use `in_reply_to_conversation_id`, this is exactly what happens, you can mention people but it won't change the recipients of the message. See https://git.pleroma.social/pleroma/pleroma/blob/develop/docs/API/differences_in_mastoapi_responses.md#post-apiv1statuses 3. I agree, it's very confusing. The solution you describe seems good.

hj commented

2019-12-23 18:19:08 +00:00

Owner

We have other problems. ~~curling iron?~~

Seeing post in legacy form and in conversation view would be very confusing and disorienting since replying to DM works differently depending on view.
Tons of old posts showing in conversation view, giving new users 100+ unread conversations
Some of those old posts also might have "DM"s that are actually misinterpreted FOs. This could also be some other AP implementation doing circles/groups etc. being interpreted as DM.
Public threads turning into dms: this doesn't help at all since you could have public-DM-public-public-DM, i.e. you make a post, Person A replies with a DM "bruh you made a typo", then Person B and C make public replies and then Person D makes similar "bruh you made a typo" DM response, all of it becomes a SINGLE conversation. I can't imagine what would happen if someone replied with a DM in a hellthread. the "This conversation started as a reply to some public post" doesn't help much in any of these cases, it's "we're sorry we're bad programmers".
the biggest issue relates to point 1 again - how it works. I'm trying to guide FE MR to have more transparency about how it actually works (i.e. showing To: to user) but the "if you use in_reply_to_conversation_id" brings more confusion to me - can you change recipients? does To even affect anything? It's even more confusing if you remember mastodon - all the stuff i mentioned back in march/april - mastodon user thinking adding a mention is ok because people they're talking to saying it's ok to do and badmouthing someone and notifying them, etc.
No "user joined conversation", no "user left the conversation", no ability to delete other people's posts from your inbox, no read/typing notifications, no presence, no chatrooms, no pure 1-on-1, and tons of other software to ruin our day.

I keep telling you that for DC to be useful and not messy they need to be completely separate from existing DMs - Make DirectMessage2 that's not compatible with DirectMessage, has stronger limitations and richer capabilities (ability to remove someone else's post for instance). Other implementations will just follow.

AP DMs are one giant hack done by gargron just because he could. He also did FOs and Unlisted. NONE of them are good nor well-designed. All of them are different hacks and you guys well aware of it. Trying to make this limited and neat UX and UI with that many moving parts is a recipe for disaster.

We have other problems. ~~curling iron?~~ * Seeing post in legacy form and in conversation view would be very confusing and disorienting since replying to DM works differently depending on view. * Tons of old posts showing in conversation view, giving new users 100+ unread conversations * Some of those old posts also might have "DM"s that are actually misinterpreted FOs. This could also be some other AP implementation doing circles/groups etc. being interpreted as DM. * Public threads turning into dms: this doesn't help at all since you could have public-DM-public-public-DM, i.e. you make a post, Person A replies with a DM "bruh you made a typo", then Person B and C make public replies and then Person D makes similar "bruh you made a typo" DM response, all of it becomes a SINGLE conversation. I can't imagine what would happen if someone replied with a DM in a hellthread. the "This conversation started as a reply to some public post" doesn't help much in any of these cases, it's "we're sorry we're bad programmers". * the biggest issue relates to point 1 again - how it works. I'm trying to guide FE MR to have more transparency about how it actually works (i.e. showing `To:` to user) but the "if you use in_reply_to_conversation_id" brings more confusion to me - can you change recipients? does `To` even affect anything? It's even more confusing if you remember mastodon - all the stuff i mentioned back in march/april - mastodon user thinking adding a mention is ok because people they're talking to saying it's ok to do and badmouthing someone and notifying them, etc. * No "user joined conversation", no "user left the conversation", no ability to delete other people's posts from your inbox, no read/typing notifications, no presence, no chatrooms, no pure 1-on-1, and tons of other software to ruin our day. I keep telling you that for DC to be useful and not messy they need to be completely separate from existing DMs - Make DirectMessage2 that's not compatible with DirectMessage, has stronger limitations and richer capabilities (ability to remove someone else's post for instance). Other implementations will just follow. AP DMs are one giant hack done by gargron just because he could. He also did FOs and Unlisted. NONE of them are good nor well-designed. All of them are different hacks and you guys well aware of it. Trying to make this limited and neat UX and UI with that many moving parts is a recipe for disaster.

shpuld commented

2019-12-23 18:26:30 +00:00

Author

Owner

More good points, yeah it might be best to get more differentiation between existing dms and messages made with conversations. I honestly don't even want to think of how bad and confusing things are if one person uses conversations and the other one uses regular dms on mastodon, especially if mentioning already works differently

shpuld commented

2019-12-27 13:03:25 +00:00

Author

Owner

I'd really want this to escalate to prevent wasting more hours on conversations systems that are fundamentally broken, @hj has been talking about it for a long time and I can see he's been right. I'm not a BE architect so I can't do much than help point out problems that face the users.

lambadalambda commented

2020-06-27 11:42:50 +00:00

Owner

This has pretty much been 'solved' by chats, which have non of the drawbacks of conversations/dms.

Rows
Columns

Conversations Improvements #21