Future for list and conversation addressing? #812

New issue

Open

opened 2024-06-20 17:34:13 +00:00 by Oneric · 0 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

No milestone

No project

No assignees

1 participant

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.