@heluecht @julian

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

@heluecht @julian I concur, but what capabilities you're interested in?
Almost everything in ActivityPub could be done peer to peer, without a relay in the middle.

@silverpill @julian When A follows B and C comments in a thread from A, but on the server from B no one follows C, how will then A be notified by comments or edits from C? And what happens when C got banned for spam. How does this information reach A? On C's server you can see where the now banned contact wrote comments. But you don't see, that comments from C where distributed (or fetched) from A.

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.

@heluecht @julian I am not sure if I understood your example correctly, but here is how it all works with FEP-171b / Conversation Containers:

- 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

@silverpill @julian Well, in my example B haven't removed C's comment. The banning had been done by C's server. So C's server have send an activity - that would reach B but not A.

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.

@heluecht @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)

@silverpill @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.

@silverpill sorry to butt in, but all of this would be solved by respecting what the canonical representation of a reply thread is: the replies collection of the top post[1]. I think it makes much more sense to built that correctly and rely on it instead of trying to keep all the nodes of the network in sync with countless activities.

[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

@mariusor @heluecht @julian I think both solutions have advantages and disadvantages. Activities are more efficient

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

@mariusor @silverpill @julian I'd loved it, if AP had followed more the way that the Diaspora protocol pursuits. There every comment, every "like", whatsover is always only transmitted to the thread starter. And the thread starter then redistributes it. And you also can send a command to be included in this distrivution, although you never participated.

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

@silverpill I think you're saying this from a position where identifiers in ActivityPub are no longer unique URLs and therefore "canonical representations" are harder to reason about, but in my opinion that's not where the protocol is now, and hopefully, not also in the future. And yes, I am aware of context, I am pretty sure I have one the first implementations that made use of it as a thread container, but that whole fep is over engineered and IMHO missed what I consider the obvious and simpler solution: put all parents in the inReplyTo and include all parents' authors as recipients. 🤷

@technical-discussion @heluecht @julian

@mariusor@metalhead.club said:

that whole fep is over engineered and IMHO missed what I consider the obvious and simpler solution: put all parents in the inReplyTo and include all parents' authors as recipients.

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.

@julian my perspective is that the fep is addressing _only_ server to server logic. From a client to server perspective, you're building the context ordered collection out of thin air (ie, no Create for it), which is not conducive to good consistency between nodes. Additionally that collection is not needed because it already exists in the form of the /replies collection of the top post. If you would use that a context, I'd feel better about it. (I use(d) a similar method in brutalinks - but I had the top level comment itself as a context, not the /replies directly.)

@mariusor@metalhead.club replies collection of the top post only contains direct replies AIUI

@julian sorry, but what are "indirect replies". My imagination fails me, or I haven't read the fep with enough attention.

@mariusor@metalhead.club a reply of a reply, for example

@julian see my caveat in one of the replies above:

> 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.)

@mariusor Which AP identifiers are no longer unique URLs? I certainly do not support this idea - identifiers must be unique.

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

@silverpill sorry if I misunderstood :( I was under the impression that you're working towards embracing DIDs as identifiers as far as I remember. To my mind that moves away from "you get the canonical representation of an object by fetching the URL of its ID" to any representation of the object that passes identity proofs. (perhaps I'm wrong in thinking this anyway, my investigation on how DIDs relate to canonical object representation was cursory and incidental) That's what I meant.

@technical-discussion @heluecht @julian

@mariusor DID-based AP IDs are globally unique and resolvable. But the resolution algorithm is more complicated than that of HTTP URLs.

@heluecht @julian

@mariusor correct