[Idea] muting subthreads on BE, how it may be done #452

New issue

Open

opened 2023-01-26 17:09:56 +00:00 by ilja · 0 comments

ilja commented

2023-01-26 17:09:56 +00:00

Contributor

The idea is the following:

Currently we have a context. Every post of the same thread gets assigned the same context. That way you can easily fetch the thread by simply fetching the context. Awesome!

The problem now is that we want to somehow mute only a part of the thread. One way I can think of is to introduce a new field who holds an array of identifiers. In this example, I call it subcontext, feel free to propose a better name ;) In this example I use id's in the form "001", but in practice, these should maybe be iri's or something[1]

OP {context: "A", subcontext: ["001"]}
| reply to OP {context: "A", subcontext: ["001", "002"]}
|| reply to the reply to OP  {context: "A", subcontext: ["001", "002", "003"]}
| another reply to OP {context: "A", subcontext: ["001", "004"]}

So then we could fetch a thread by saying "Give me everything with context A", but filter out subthreads with "Give me everything with context A, which doesn't have subcontext 003".

Or if a notification is generated, we could say "don't generate for activities with subcontext 003". Or it could be done client side by saying "filter out notifications for activities with subcontext 003".

And if the array is ordered, we could even ask subthreads with something like "Give me everything from subcontext ["001", "002", "003"]", which would translate in "everything with 003 in it's subcontext array, and also post with subcontext ["001"] or subcontext ["001", "002"]".

The reason why it's a new field is so that we can keep using context the way we already do, while instances that don't understand this subcontext can safely ignore it. (It's their loss that they can't easily filter subthreads 😏).

[1]
I'm unsure what these subcontext id's should be. First I was thinking a new id pointing to a collection, with "001" being the same id as the original context. But maybe the id of the Objects inReplyTo makes more sense? That would make this subcontext an ordered list of inReplyTo recursively. (Maybe inReplyToArray would be a more proper name, but again, feel free to make better proposals 😬).

That would make it something like

OP {id: "001", inReplyToArray: []}
| reply to OP {id: "002", inReplyTo: "001", inReplyToArray: ["001"]}
|| reply to the reply to OP  {id: "003",  inReplyTo: "002",inReplyToArray: ["001", "002"]}
| another reply to OP {id: "004",  inReplyTo: "001",inReplyToArray: ["001"]}

I'm pretty sure I've seen people ask for this in the past, but I don't find issues here nor on the pleroma issue tracker. I think the general answer was always that muting subthreads isn't something which can be easily done, but I think I have a way. I want to share it somewhere so that we can more easily find it if someday demand for it comes. See also <https://ilja.space/notice/AS1tvCFT399HbdT05Y> The idea is the following: Currently we have a `context`. Every post of the same thread gets assigned the same context. That way you can easily fetch the thread by simply fetching the context. Awesome! The problem now is that we want to somehow mute only a part of the thread. One way I can think of is to introduce a new field who holds an array of identifiers. In this example, I call it `subcontext`, feel free to propose a better name ;) In this example I use id's in the form "001", but in practice, these should maybe be iri's or something[1] ``` OP {context: "A", subcontext: ["001"]} | reply to OP {context: "A", subcontext: ["001", "002"]} || reply to the reply to OP {context: "A", subcontext: ["001", "002", "003"]} | another reply to OP {context: "A", subcontext: ["001", "004"]} ``` So then we could fetch a thread by saying "Give me everything with context A", but filter out subthreads with "Give me everything with context A, which doesn't have subcontext 003". Or if a notification is generated, we could say "don't generate for activities with subcontext 003". Or it could be done client side by saying "filter out notifications for activities with subcontext 003". And if the array is ordered, we could even ask subthreads with something like "Give me everything from subcontext ["001", "002", "003"]", which would translate in "everything with 003 in it's subcontext array, and also post with subcontext ["001"] or subcontext ["001", "002"]". The reason why it's a new field is so that we can keep using context the way we already do, while instances that don't understand this subcontext can safely ignore it. (It's their loss that they can't easily filter subthreads 😏). [1] I'm unsure what these subcontext id's should be. First I was thinking a new id pointing to a collection, with "001" being the same id as the original context. But maybe the id of the Objects inReplyTo makes more sense? That would make this `subcontext` an ordered list of `inReplyTo` recursively. (Maybe `inReplyToArray` would be a more proper name, but again, feel free to make better proposals 😬). That would make it something like ``` OP {id: "001", inReplyToArray: []} | reply to OP {id: "002", inReplyTo: "001", inReplyToArray: ["001"]} || reply to the reply to OP {id: "003", inReplyTo: "002",inReplyToArray: ["001", "002"]} | another reply to OP {id: "004", inReplyTo: "001",inReplyToArray: ["001"]} ```

ilja changed title from ~~[Idea] muting subthreads on BE, how it could maybe be done~~ to [Idea] muting subthreads on BE, how it may be done

2023-01-26 17:12:13 +00:00

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#452

No description provided.