@heluecht @julian

> Caveat, this requires that all replies to a post, include in their inReplyTo property at least their parent and the top post - ideally they should include the whole chain of parents to the top post.

(Also, when I said "overcomplicated" I really meant, "possible in the framework of what current vanilla ActivityPub provides, _without_ needing extra operations or concepts", the idea is simple enough, and sound at its core: a container where all replies can be found.)

@technical-discussion @heluecht @julian

Regarding the FEP: it describes existing implementations. If yours keeps entire convos in top-level replies collections, I can add a section about that.

@heluecht @julian

Over-engineered how? Most people read 7888 and decide it's too complicated. I get that, it's a tough read.

But the tl;dr of f228 is: context is a property on Note-like objects, it resolves to an OrderedCollection, put ids of those Note-like objects in that collection. Done.

I'm okay with shoving all parents into inReplyTo too, as long as you put the most direct parent first. Then I can just .shift() and ignore the rest.

@technical-discussion @heluecht @julian

"A" could periodically re-fetch the thread.

Well, information like that should always be pushed, not pulled, because otherwise you create a lot of unneccessary load on the systems.

This would had solved a lot of problems, especially when it comes to non public posts.

the canonical representation of a reply thread is: the replies collection of the top post

The most popular representation is context collection containing posts. I know 10 implementers, including some big ones: https://codeberg.org/fediverse/fep/src/branch/main/fep/f228/fep-f228.md

[1] Caveat, this requires that all replies to a post, include in their inReplyTo property at least their parent and the top post - ideally they should include the whole chain of parents to the top post.

@heluecht @technical-discussion @julian

So C's server have send an activity - that would reach B but not A.

With conversation containers:

- B receives Delete<Person> for C
- C participated in the conversation, so B generates Add<Delete<Person>> activity and sends it to A
- A receives Add activity and deletes C

A doesn't follow B, but simply fetched that thread

"A" could periodically re-fetch the thread.

I have also heard that some of Friendica descendants have "subscribe on fetch" feature.

@silverpill

Btw, I noticed that this @-mention in your post contains a wrong URL: https://tinyap.izkluxcvy.foo/@silverpill@mitra.social (it points to some other server instead of mine)

And the problem still exists anyway, when A doesn't follow B, but simply fetched that thread. Then neither B nor C will perform any updates in the direction of A.

- A follows B
- C comments on B's post (Create activity)
- B generates Add<Create> activity and sends it to A
- A receives Add and adds C's comment to their copy of the conversation

If C is banned for spam (and their comment removed):

- B removes C's comment (Delete activity)
- B generates Add<Delete> activity and sends it to A
- A receives activity and removes C's comment from the conversation

And it gets worse, when you simply fetch messages, that hadn't been pushed to you. Then you won't get any updates, except when you would pull it from time to time.

And of course some "give me all posts with that specific hashtag but only in these languages" will not work quite well, when you are on a stand alone server.

This can be done with inbox forwarding or special activities (FEP-171b or FEP-1b12).

Selective relays may be used for other things though. There is https://github.com/dtp-mstdn-jp/selective-relay that apparently can filter activities by hashtags, domains and number of attachments

And concerning the second point, I imagine some relay service that does not simply forward everything, but that knows which content you you are interested in. So when you subscribed to user A and user B posted something in a thread that user A started, then the relay would forward it to you, although you never subscribed to B. And when then the account B got deleted or blocked, then of course you would be notified as well.