Federating servers

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

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

@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

@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 DID-based AP IDs are globally unique and resolvable. But the resolution algorithm is more complicated than that of HTTP URLs.

@heluecht @julian