I think the #ActivityPub client-to-server API is extremely important and underrated.
-
@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
> 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 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)
-
@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.
@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...)
-
@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 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.
-
@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.
@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...)
-
@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.
@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 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 @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.
-
@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.
@trwnh The GTS implementation comes with a vocabulary extension, so adding another activity type would be an option.
I guess the reason they didn't do that for this case (I wasn't around for the decision) is that the Accept(Note) thing is itself a backward compatibility hack that they hoped to be able to drop eventually, when more servers would send ReplyRequests (which can be Accept-ed directly), and adding a new type would have felt too much like “enshrining” it.
-
@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@activitypub.space I'm doing my best to realistically prioritize traffic load as well, yeah. The case of accepting an incoming reply will be frequent, whereas the one where you first accept a reply, then change your mind and revoke the acceptance, would be expected to be relatively rare.
The easy way out for me would be to just not touch that part of the spec, leave it as Accept(Note), and see what implementers do with it.
-
@trwnh The GTS implementation comes with a vocabulary extension, so adding another activity type would be an option.
I guess the reason they didn't do that for this case (I wasn't around for the decision) is that the Accept(Note) thing is itself a backward compatibility hack that they hoped to be able to drop eventually, when more servers would send ReplyRequests (which can be Accept-ed directly), and adding a new type would have felt too much like “enshrining” it.
@julian i think mastodon handles multityping in certain code paths but most other projects don't. it could have been a compatibility thing?
-
@julian i think mastodon handles multityping in certain code paths but most other projects don't. it could have been a compatibility thing?
@trwnh Maybe. I have no idea if GTS itself can handle activities with multiple types.
-
Except when they are called other names instead
A timeline is a different thing than a collection imho. And an AS collection has some very particular functionality, which if I model a timeline in my app may not supported (e.g. reverse ordering).
Collection / 'timeline' is one of those words where sometimes they indicate an app domain, and sometimes a core protocol mechanism. Same is true with 'follow' which is sometimes a user action, sometimes indicates low-level publish/subscribe.
For core capabilities that must be part of the specs, in 'protocol space' it may be better to use terminology that is more common in messaging architectures and all the various architecture patterns that are involved. Perhaps idk we deal with a time-ordered event log or something like that.
@smallcircles @evan An AS2 Collection cannot be a timeline (in general). It’s not even ordered. An AS2 OrderedCollection (a subtype of Collection) might be ordered by time or not, so it’s also not a timeline (in general). When they are ordered by some time value (unspecified in AP) they are often called “streams” in the spec. The Mastodon content timelines are not the same as AP activity streams although a filtered AP stream can be transformed to a content timeline.
-
@smallcircles @evan An AS2 Collection cannot be a timeline (in general). It’s not even ordered. An AS2 OrderedCollection (a subtype of Collection) might be ordered by time or not, so it’s also not a timeline (in general). When they are ordered by some time value (unspecified in AP) they are often called “streams” in the spec. The Mastodon content timelines are not the same as AP activity streams although a filtered AP stream can be transformed to a content timeline.
@steve I think
we need to emphasize that timelines can be built from regular collections, even unordered ones, by using some intermediate representations specific to the type of timeline that a client wants to render.The fact that the specification does not directly support a mapping between a collection and a responsive timeline, *DOES NOT MEAN* one can't be built from it, only that it requires a little more effort on the client side.
My goto example is how rich mail clients allow responsive mailbox representations on top of a much less expressive collection method that IMAP provides compared to ActivityPub.
-
@smallcircles @evan An AS2 Collection cannot be a timeline (in general). It’s not even ordered. An AS2 OrderedCollection (a subtype of Collection) might be ordered by time or not, so it’s also not a timeline (in general). When they are ordered by some time value (unspecified in AP) they are often called “streams” in the spec. The Mastodon content timelines are not the same as AP activity streams although a filtered AP stream can be transformed to a content timeline.
@steve @smallcircles The `inbox` and `outbox` are both sequences ordered by time. I think that should meet your requirements for a 'timeline'?
I think it's fair to call the outbox the actor's 'feed'? It is a feed of all their activities.
-
@steve @smallcircles The `inbox` and `outbox` are both sequences ordered by time. I think that should meet your requirements for a 'timeline'?
I think it's fair to call the outbox the actor's 'feed'? It is a feed of all their activities.
@steve @smallcircles I also agree that activities are more primary than content objects like notes and images in ActivityPub. That is by design and reflected in the name of the data format, API and federation protocol.
-
@steve @smallcircles I also agree that activities are more primary than content objects like notes and images in ActivityPub. That is by design and reflected in the name of the data format, API and federation protocol.
> I think it's fair to call the outbox the actor's 'feed'?
The actor's event bus in a pure event based approach.
Does that break AP? Current fediverse?
Can AP be considered an event-driven architecture of sorts (or restrained as such in a solution design)?I really like the Motivating use cases section of the AS specs, and the primer that sits on the W3C wiki to that. Those might be further formalized so they are applied consistently.
-
@steve @smallcircles I also agree that activities are more primary than content objects like notes and images in ActivityPub. That is by design and reflected in the name of the data format, API and federation protocol.
That said, I think it would be great to have reverse chronological ordered collections of objects created by the actor.
It would be nice to use `streams` like `endpoints`, as an object, and define properties like `notes`, `images`, `places` and so on off of it.
Unfortunately the loose definition and lack of examples for `streams` makes it hard to use. It's probably better just to define them as top-level properties of the actor.
-
That said, I think it would be great to have reverse chronological ordered collections of objects created by the actor.
It would be nice to use `streams` like `endpoints`, as an object, and define properties like `notes`, `images`, `places` and so on off of it.
Unfortunately the loose definition and lack of examples for `streams` makes it hard to use. It's probably better just to define them as top-level properties of the actor.
@steve @smallcircles I also agree that having a separate "home timeline" and "notifications timeline" makes sense. There's an open user story for that:
Separate notifications and home feed · Issue #21 · swicg/activitypub-api
"As an ActivityPub API client developer, I want a 'home feed' collection for content-oriented incoming activities like Create, Question and Announce, so that I can show my users the most important content from their networks." "As an Act...
GitHub (github.com)
-
@steve @smallcircles I also agree that having a separate "home timeline" and "notifications timeline" makes sense. There's an open user story for that:
Separate notifications and home feed · Issue #21 · swicg/activitypub-api
"As an ActivityPub API client developer, I want a 'home feed' collection for content-oriented incoming activities like Create, Question and Announce, so that I can show my users the most important content from their networks." "As an Act...
GitHub (github.com)
The way I see it, this has the wrong stakeholder name of "ActivityPub API client developer" i.e. spec implementer, and a Home Feed is something I may want as a "Solution developer" stakeholder. In other words that library or SDK that offers me the Social API should allow me to model that.
The user story was also brought up by Mastodon, a Microblogging solution built on top of AP (ideally).
