I think this is what I’d call “client-to-client protocol”, and I definitely agree that it should be signalled somehow. We might end up in a situation where you have to signal clients attached to your actor anyway, because E2EE requires client-to-client anyway.
This is possible with fep/fep/7458/fep-7458.md at main - fediverse/fep - Codeberg.org but I’d also caution against giving replies such preferential treatment. It makes more sense to logically and purposefully group things by their context as described in fep/fep/7888/fep-7888.md at main - fediverse/fep - Codeberg.org – which MAY be a flat list OrderedCollection as a progressive enhancement, owned by some moderator or manager who explicitly maintains the context. (This is in the case that it does resolve, does resolve to a collection, and does have an owner.) But replies can definitely exist in parallel to that, so you have the option of maintaining a list of responses to your object, as well as declaring that your object is part of some larger context.
This is one of the things I disagree with, and rather I think that inbox forwarding should actually be further specified.
We don’t need the concept of a “server”, do we? We just need an endpoint that allows for batch delivery, which may or may not be server-wide. That’s an implementation detail that gets abstracted away once you start dealing with things in terms of “inboxes” and the corresponding inbox endpoint. It still exists in a C2S perspective because the “server” is the HTTP server that is processing your activities. This could also tie in with a point above about having the concept of a “client” at the protocol level.
For one potential way to do batch delivery, there was some discussion around FEP-0499 and multibox noting that it could be used for batch delivery:
More discussion here: FEP-0499: Delivering to multiple inboxes with a multibox endpoint - #3 by silverpill
Definitely! There’s a lot of pain points around how implementations have dealt with types up to this point, which is to say, poorly or not at all. (Every time I see an explicit type check that doesn’t have a reason, I die a little on the inside.)
I think types should signal information that can’t be otherwise signaled by a property. For example, the difference between a Note and an Article is mostly semantic and depends on whether the text is “formally published” or not. They can otherwise have the same properties. Distinguishing between a Note and an Article is a good use of type. But other things can be generally duck-typed or you can just use a property if it’s present without even bothering to check the explicit type. For example, do you really care that something is an as:Collection if you can just check for as:items? What’s really necessary here to provide the functionality you’re trying to provide? The type check does nothing except make your code more fragile. I think part of the problem is implementers assuming type is necessary when it really isn’t. But this is also the kind of thing that can be addressed with more thorough guidance. Speaking of guidance,
This is a really good thing to have and it’s sad that we don’t have it currently.