I think the #ActivityPub client-to-server API is extremely important and underrated.

@evan @julian@fietkau.social @julian@activitypub.space @smallcircles personally i think three things happen generally, which could each be described by their own activity in succession:

1) the original Activity is posted.
2) you can Accept or Reject the Activity.
3) as a result, you can Add or Remove the Activity to the corresponding AP collection.

this holds for Like and Announce 1:1. Follow we currently Add the Follow.object instead, but i think we ought to store the actual Follow activity in a follows collection.

@evan @julian@fietkau.social @julian@activitypub.space @smallcircles of course follows are a bit more stateful and complex, so it can be argued that we should actually allow for richer subscription management, similar to when you open a dashboard and manage which email notifications you want to receive. the subscription could be reified as a Follow activity, but the side effects and semantics are not exactly the same with what's in AP right now. (AP doesn't have a way to remove a follower; masto uses Reject without Undo Accept)

@evan @julian@fietkau.social @julian@activitypub.space @smallcircles and then there are replies, which in fedi currently require deep introspection of a Create.object.inReplyTo, which is information that may not be immediately available to you. so it leads to the unfortunately complicated situation where you don't actually know when you received a reply, because there is no Reply activity to be used as a notification -- you have the side effect without the activity.

@evan @julian@fietkau.social @julian@activitypub.space @smallcircles re: the Undo Accept thing vs Reject thing, using a Reject is prone to issues with out-of-order deliveries. if you send a Follow and get back an Accept and a Reject with the same published datetime, then are you currently a follower? what if the Reject came first but then you receive a later Accept? it makes it incredibly hard to reason about the distributed state machine, and leads to terrible desyncs when one side thinks you follow them and the other doesn't.

@evan @julian@fietkau.social @julian@activitypub.space @smallcircles i think there needs to be a way to get a consistent event log in-order from the canonical/authoritative source. failing that, though, the least you could do is have your activities refer to each other in an obvious way. Undo(Accept(Follow)) lets you reverse-reconstruct what happened because all 3 activities are right there (hopefully fetchable!). so maybe Undo(Add) makes more sense than Remove; perhaps we say that the Remove is the result of the Undo?

@evan @julian@fietkau.social @julian@activitypub.space @smallcircles i guess you could hack it with inReplyTo on the Activity, if you assume responses always come after the thing they are responding to (although i could make a famous joke here about answering a question before it is asked).

@evan @julian@fietkau.social @julian@activitypub.space @smallcircles anyway, to address julian (not lam)'s question: what does Accept(Note) even mean? what does it entail? can you always assume it has to do something with a replies collection that may or may not be there?

@smallcircles @evan @julian if only the application domain of activitystreams was activities and streams...

i do think it causes a lot of confusion to stray away from activities as content, instead using them as vehicles for state changes (which will never be consistent, not even eventually consistent).

back when atompub and atom+as1 were a thing, the "feed entry" was atom semantics and the "activity stream" was as1 semantics. they coexisted in the same xml file. it worked well enough.

@trwnh @evan @julian

Yes, for the ideation on Protosocial as an #ActivityPub compliant extension (going back to the roots with blank slate W3C specs) I imagined mapping the AS primitives to consistent protocol capabilities and thereby define a set of normative architecture patterns, like "this is how we do CRUD, this is Publish/Subscribe, this is an Event stream and this a Collection", etc.

Then Protosocial library and SDK implementers would need to deal with #ActivityStreams at a low-level plumbing impl detail, while solution developers would have a higher-level API to invoke these patterns. And other than that would not need to touch #ActivityStreams which is now entirely reserved to making AP work on the wire.

A combination of linked data practices and schema-based design would be used for both open-world and closed-world extension modeling. But here too the solution developer should be shield from the nitty gritty internal mechanics.

@trwnh That's kinda what I'm getting at, yeah. The goal is to express that the owner of the replied-to object has accepted a reply, i.e. that the reply is added to the post's replies collection and shown under it in the web view. Followers and other observers are made aware this reply is accepted and can be shown similarly in other places that want to honor the poster's reply filters, so observers don't need to iterate over the replies collection all the time.

@evan @julian@activitypub.space @smallcircles

@trwnh The GTS interaction controls docs mention the replies collection, but only tangentially. For the purpose of conversation backfilling (which GTS doesn't do yet) I'm wanting to emphasize that the replies collection is the source of truth for replies curated by the object owner.

The Accept(Note) is essentially a hack to allow interactions from servers that don't implement GTS's ReplyRequest activity. I'll discuss with them how best to signal reply acceptance.

@evan @julian@activitypub.space @smallcircles

@julian@fietkau.social @evan @julian@activitypub.space @smallcircles

> express that the owner of the replied-to object has accepted a reply, i.e. that the reply is added to the post's replies collection and shown under it in the web view

i get that, but the question is whether you can claim this understanding universally for all peers. as it stands, Accept is very vague wrt this. Accept(Note) meaning "Add to replies collection" might be a thing gts does, but that's their interpretation of Accept, not the definition.

@julian@fietkau.social @evan @julian@activitypub.space @smallcircles

> replies collection is the source of truth for replies curated by the object owner.

this is fine i think, but the way to do this usually is HTTP GET. you could notify of changes to the replies collection, or you could reify the Reply and then Accept that?

the Reply has an instrument which is the Note. it has clear side effects to Add the instrument to the object.replies. the side effects can be gated behind Accept/Reject like following currently works.

@julian@fietkau.social @evan @julian@activitypub.space @smallcircles alternatively add the Reply itself, parallel to likes/shares collections. it depends on whether you think the replies collection should always contain a specific type of object, which i don't think is something you can guarantee because publishers can do anything with it. similar to how some publishers include activities in threads and some include notes.

@julian@fietkau.social @evan @julian@activitypub.space @smallcircles i think the issue here is that projects are doing things that may or may not get widely adopted, then if the proposals ever change, they have to deal with older software only understanding the old thing they tried. (this is where i would say something about protocol capability negotiation)

@trwnh This is in the context of a FEP draft which prescribes a meaning (including desired side effects) for compliant implementations.

Hence my fidgeting with the vocabulary. The effects are the goal, the question is how they should be expressed and broadcasted. (Principle of least surprise, potential compatibility with existing implementations that look at the replies collection, concerns around server traffic...)

@evan @julian@activitypub.space @smallcircles

@trwnh There's also this, yeah. GTS interaction controls have already gone through one breaking schema revision from version 0.19 to 0.21 (with 0.20 trying to manage both), and a core goal of the FEP I'm working on is to not break compatibility again.

Sending out an Add in addition to the Accept(Note) that's already happening should be non-breaking for existing implementations, I'm pretty sure. What's left to decide is whether it's a good idea.

@evan @julian@activitypub.space @smallcircles

@julian@fietkau.social @evan @julian@activitypub.space @smallcircles this makes me really wish people didn't overload the AS2 vocab so much, and were less afraid of defining their own extensions. you could swing it so that the same activity is an Add, Accept, and ReplyAck. it sucks that we have to pick one instead of using whatever makes sense. (developers: please support multityping and/or duck typing! composability is the only true path to extensibility, and one size never fits all...)

@julian@fietkau.social in a parallel conversation not about interaction controls, @rimu@piefed.social made the case for batching events, which I'm going to repurpose as an argument against sending additional activities for backward compatibility (unless absolutely necessary.)

> As a user can do a great number of notable things (posting content, liking content, following others) each minute and there can be thousands of instances to send to, a great many POST requests can be sent in a short amount of time.
>
> For example if 5 people cast 20 votes and there are 500 instances, the instance hosting the community containing the posts being voted on must send 5 * 20 * 500 = 50,000 HTTP POSTs.

@julian@fietkau.social @evan @julian@activitypub.space @smallcircles

actor: alice
type: as:Accept, as:Add, _:ReplyAck
object: <the reply>
target: <the replies collection>
_:postRepliedTo: <op>

for the Accept, you need to understand it as "accepting the object into the target", which is apparently a thing in AS2-Vocab.

for the Add, you need to understand it as Add is defined -- no surprises there, i think?

for the ReplyAck, it can be whatever you define. here i've used an extension postRepliedTo property.