AkkomaGang/akkoma

Fork 91

Future for list and conversation addressing? #812

New issue

Open

opened 2024-06-20 17:34:13 +00:00 by Oneric · 3 comments

Oneric commented

2024-06-20 17:34:13 +00:00

Member

Should we try and fix those up (implement support in some frontend), or just yeet them?

List addressing and visibility

Already alluded to in #778.
Originall introduced in https://git.pleroma.social/pleroma/pleroma/-/merge_requests/1113

This is both an addressing mode and a visibility setting. Yet almost all code dealing with visibilities doesn’t acknowledge the existence of visibility="list", which i’m sure leads to some funny interactions and bugs.
It appears to be a shortcut to address a(n effectively private) message to all users previously added to a private list, but recipients don't know who else is on the list so replies to that message probably end up as individual DM threads. Tbh this doesn’t seem very useful to me.

Testing this on current Akkoma in practice shows that:

trying to reply to a list message leads to an internal server error because of no matching function cluase for Pleroma.Web.CommonAPI.Utils.get_to_and_cc
newly added local list memebers get access to older list posts
a list-scope message gets the "Public" symbol in akkoma-fe but with an untranslated "general.scope_in_timeline.list" title string

imho this is better off just being purged entirely

Conversation Addressing

Fortunately, no visibility mode was added for this.

Pleroma implemented Mastodon’s conversation API in https://git.pleroma.social/pleroma/pleroma/-/merge_requests/1119.
A few months later Pleroma decided to add some extensions to this API; quoting https://git.pleroma.social/pleroma/pleroma/-/merge_requests/1535:

The addressed recipients will never change unless explicitly requested

Mentioning people in the text is not necessary to address them

You can get statuses by conversation id

It's possible to reply to a conversation without replying to a specific post.

However again there are no known users of those extensions; akkoma-fe still exclusively uses the deprecated direct messages timeline anyway.

For unfathomable reasons this also entailed duplicating existing MastoAPI endpoints into the /pleroma// API namespace and also duplicating controller and API spec code for those.

The third extension imho makes quite a lot of sense and probably still works as intended. I’d like to keep this as it should improve things for the eventual switch away in akkoma-fe from the deprecated dm timeline.

I haven't tested anything for this yet, but given how this conflicts with normal DM usage and MastoAPI requirements i strongly suspect point 1 and 2 are also broken by now (and again there aren't any users of the extended interface who might notice the extensions breaking).

Point 4 was implemented by way of a in_reply_to_conversation_id parameter when creating a post, which maybe still works given there are at least tests for it. Imho this isn’t a great way to implement it though since it interacts with the visibility and addressing settings of a post in non-obvious ways. Maybe can be kept, maybe not worth the hassle, i’m not sure

There are two funny addressing (and in one case visibility) mode inherited from Pleroma which afaict are not and never were supported in any frontend. At least one of them is actually broken in practice *(yet nobody complained further supporting the lack of users)* the other one i just haven't tested yet. Should we try and fix those up (implement support in some frontend), or just yeet them? ### List addressing and visibility Already alluded to in #778. Originall introduced in https://git.pleroma.social/pleroma/pleroma/-/merge_requests/1113 This is both an addressing mode and a visibility setting. Yet almost all code dealing with visibilities doesn’t acknowledge the existence of `visibility="list"`, which i’m sure leads to some funny interactions and bugs. It appears to be a shortcut to address a(n effectively private) message to all users previously added to a private list, but recipients don't know who else is on the list so replies to that message probably end up as individual DM threads. Tbh this doesn’t seem very useful to me. Testing this on current Akkoma in practice shows that: - **trying to reply to a list message leads to an internal server error** because of no matching function cluase for Pleroma.Web.CommonAPI.Utils.get_to_and_cc - newly added local list memebers get access to older list posts - a list-scope message gets the "Public" symbol in akkoma-fe but with an untranslated "general.scope_in_timeline.list" title string imho this is better off just being purged entirely ### Conversation Addressing Fortunately, no visibility mode was added for this. Pleroma implemented Mastodon’s conversation API in https://git.pleroma.social/pleroma/pleroma/-/merge_requests/1119. A few months later Pleroma decided to add some extensions to this API; quoting https://git.pleroma.social/pleroma/pleroma/-/merge_requests/1535: > 1. The addressed recipients will never change unless explicitly requested > 2. Mentioning people in the text is not necessary to address them > 3. You can get statuses by conversation id > 4. It's possible to reply to a conversation without replying to a specific post. However again there are no known users of those extensions; akkoma-fe still exclusively uses the deprecated direct messages timeline anyway. For unfathomable reasons this also entailed duplicating existing MastoAPI endpoints into the `/pleroma//` API namespace **and also duplicating controller and API spec code for those**. The third extension imho makes quite a lot of sense and probably still works as intended. I’d like to keep this as it should improve things for the eventual switch away in akkoma-fe from the deprecated dm timeline. I haven't tested anything for this yet, but given how this conflicts with normal DM usage and MastoAPI requirements i strongly suspect point 1 and 2 are also broken by now *(and again there aren't any users of the extended interface who might notice the extensions breaking)*. Point 4 was implemented by way of a `in_reply_to_conversation_id` parameter when creating a post, which _maybe_ still works given there are at least tests for it. Imho this isn’t a great way to implement it though since it interacts with the visibility and addressing settings of a post in non-obvious ways. Maybe can be kept, maybe not worth the hassle, i’m not sure

ilja commented

2024-08-13 07:27:17 +00:00

Contributor

List addressing and visibility

This sounds like what people sometimes refer to as Diaspora Aspects, or Google+ Circles? I've seen people talk about it, but I don't remember Akkoma people strongly wanting it. If the code were in a working state, maybe it would be worth the hasle to change Akkoma-fe to support it, but from what I understand, this is not the case.

It sounds like a lot of work to get it fixed as it currently is, so yes, removing is probably the better choice.

If someone does want it back, it may very well be easier to reimplement, rather than to try fixing something which was never properly working in the first place.

Conversation Addressing

This sounds a lot like how Streams and Friendica work by default? Honestly, I think this makes more sense than the current reply-to-own-followers, bc this makes the OP the owner of the conversation, which I think gives a lot of advantages. Personally I like this way more, but that doesn't mean the current code is really fit for it.

When done right, this could mean;

No more broken threads if the OP can forward the messages (but do we have a mechanism for that in Akkoma?)
Better control on who you see in the replies (and if other instances support this, also control on who is visible in the replies on other instances)
If OP can forward replies, then we don't have the "I need to open the thread in another instance to see the whole conversation" any more (at least for threads who were started as these type of conversations)
Technically speaking, this should even allow people to "add" themselves to the conversation, allowing to follow it without needing to participate (assuming it's posted as:public). Or, if it's public, someone who replies could add their follower collection to it so that the instances of their followers also know the whole conversation.
No more annoying replies of people you don't know (or would prefer not to know) on follower-only posts.

I think that would be very powerfull, but I don't know if the current code is even close to that? Or if other people even think this would even be an improvement on how conversations currently go?

> List addressing and visibility This sounds like what people sometimes refer to as Diaspora Aspects, or Google+ Circles? I've seen people talk about it, but I don't remember Akkoma people strongly wanting it. If the code were in a working state, maybe it would be worth the hasle to change Akkoma-fe to support it, but from what I understand, this is not the case. It sounds like a lot of work to get it fixed as it currently is, so yes, removing is probably the better choice. If someone does want it back, it may very well be easier to reimplement, rather than to try fixing something which was never properly working in the first place. > Conversation Addressing This sounds a lot like how Streams and Friendica work by default? Honestly, I think this makes more sense than the current reply-to-own-followers, bc this makes the OP the owner of the conversation, which I think gives a lot of advantages. Personally I like this way more, but that doesn't mean the current code is really fit for it. When done right, this could mean; 1. No more broken threads if the OP can forward the messages (but do we have a mechanism for that in Akkoma?) 2. Better control on who you see in the replies (and if other instances support this, also control on who is visible in the replies on other instances) 3. If OP can forward replies, then we don't have the "I need to open the thread in another instance to see the whole conversation" any more (at least for threads who were started as these type of conversations) 4. Technically speaking, this should even allow people to "add" themselves to the conversation, allowing to follow it without needing to participate (assuming it's posted `as:public`). Or, if it's public, someone who replies could add their follower collection to it so that the instances of their followers also know the whole conversation. 5. No more annoying replies of people you don't know (or would prefer not to know) on follower-only posts. I think that would be very powerfull, but I don't know if the current code is even close to that? Or if other people even think this would even be an improvement on how conversations currently go?

Oneric commented

2024-08-20 18:15:58 +00:00

Author

Member

Honestly, I think this makes more sense than the current reply-to-own-followers, bc this makes the OP the owner of the conversation, which I think gives a lot of advantages.

Conversations are always direct messages iiuc meaning followers won’t be implicitly addressed either way.

No more broken threads if the OP can forward the messages (but do we have a mechanism for that in Akkoma?)

In theory threads won’t break since all participants are explicitly addresses — but remote servers aren’t aware of the conversation properties treat this as regular DMs and might accidentally or intentionally drop some participants.

What you seem to describe might better relate to acting on the already existing context AcitivtyPub property? This will work regardless of DM or not.
E.g. creating a new message in the context without replying to a particular post; subscribing to a context (requesting from the context host to forward all messages to the subscriber).

As for authorising replies i think there was a FEP for that.

> Honestly, I think this makes more sense than the current reply-to-own-followers, bc this makes the OP the owner of the conversation, which I think gives a lot of advantages. Conversations are always direct messages iiuc meaning followers won’t be implicitly addressed either way. > No more broken threads if the OP can forward the messages (but do we have a mechanism for that in Akkoma?) In theory threads won’t break since all participants are explicitly addresses — but remote servers aren’t aware of the conversation properties treat this as regular DMs and might accidentally or intentionally drop some participants. What you seem to describe might better relate to acting on the already existing `context` AcitivtyPub property? This will work regardless of DM or not. E.g. creating a new message in the context without replying to a particular post; subscribing to a context (requesting from the context host to forward all messages to the subscriber). As for authorising replies i think there was a FEP for that.

ilja commented

2024-10-03 10:42:20 +00:00

Contributor

Conversations are always direct messages

Wow, I think I was assuming too quick due to the name. This is indeed very different than what I was assuming 🤐 (What I was thinking is "Conversation Containers" in the Streams repo. But that's very different indeed, and indeed uses context). This vaguely rings a bell, though. These were not really used because it was deemed too complex and ChatMessage was eventually introduced, see https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2429 I remembered ChatMessage being an alternative to something else, but I didn't really know what or that there was actually implementation of the thing it was an alternative to. Now I know.

Reading the commits, the only thing these "Conversations" do is showing DM's in a slightly different timeline. It seems Pleroma wanted to make something more of this and that's why they got too complex and ChatMessage was introduced. Removing the complexity seems like a good idea then. It was deemed not suitable, so we will probably get into the same problem if we try to keep and support it as-is.

You can get statuses by conversation id

The third extension imho makes quite a lot of sense and probably still works as intended. I’d like to keep this as it should improve things for the eventual switch away in akkoma-fe from the deprecated dm timeline.

When I check current Masto-fe on Akkoma, it first fetches the conversations with /api/v1/conversations. When you click one of the conversations, it opens a thread. A thread is generally fetched starting from a specific status. When openening a thread, this status is marked as being the one selected. This is the same here, so the id of the status is used, not the id of the conversation, using /api/v1/statuses/<status_id>/context.

Afaict, Mastodon doesn't have a separate endpoint to query a "conversation" on conversation id (see https://docs.joinmastodon.org/methods/conversations/ ). So I'm not sure how useful it really is then to keep even that one. Do we want to remove the dm tl for something else? Will using conversation id really make more sense than using status id?

At any rate, it seems a good idea to clean (ie "yeet") these things up (both "List addressing and visibility" and "Conversation Addressing") if someone can spend the time for it. As far as I'm concerned, I wouldn't mind even the "3. You can get statuses by conversation id" extention be removed, but if someone thinks it's useful, I don't mind it being still there. The rest gone will already be a nice clean up.

> Conversations are always direct messages Wow, I think I was assuming too quick due to the name. This is indeed very different than what I was assuming 🤐 (What I was thinking is "Conversation Containers" in [the Streams repo](https://codeberg.org/streams/streams/src/branch/release/FEDERATION.md#fediverse-feps). But that's very different indeed, and indeed uses `context`). This vaguely rings a bell, though. These were not really used because it was deemed too complex and `ChatMessage` was eventually introduced, see https://git.pleroma.social/pleroma/pleroma/-/merge_requests/2429 I remembered `ChatMessage` being an alternative to something else, but I didn't really know what or that there was actually implementation of the thing it was an alternative to. Now I know. Reading the commits, the only thing these "Conversations" do is showing DM's in a slightly different timeline. It seems Pleroma wanted to make something more of this and that's why they got too complex and `ChatMessage` was introduced. Removing the complexity seems like a good idea then. It was deemed not suitable, so we will probably get into the same problem if we try to keep and support it as-is. > 3. You can get statuses by conversation id > > The third extension imho makes quite a lot of sense and probably still works as intended. I’d like to keep this as it should improve things for the eventual switch away in akkoma-fe from the deprecated dm timeline. When I check current Masto-fe on Akkoma, it first fetches the conversations with `/api/v1/conversations`. When you click one of the conversations, it opens a thread. A thread is generally fetched starting from a specific status. When openening a thread, this status is marked as being the one selected. This is the same here, so the id of the status is used, not the id of the conversation, using `/api/v1/statuses/<status_id>/context`. Afaict, Mastodon doesn't have a separate endpoint to query a "conversation" on conversation id (see <https://docs.joinmastodon.org/methods/conversations/> ). So I'm not sure how useful it really is then to keep even that one. Do we want to remove the dm tl for something else? Will using conversation id really make more sense than using status id? At any rate, it seems a good idea to clean (ie "yeet") these things up (both "List addressing and visibility" and "Conversation Addressing") if someone can spend the time for it. As far as I'm concerned, I wouldn't mind even the "3. You can get statuses by conversation id" extention be removed, but if someone thinks it's useful, I don't mind it being still there. The rest gone will already be a nice clean up.

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#812

No description provided.