What if...
-
@mariusor @steve @evan @raphael An extension is a protocol extension. Specifically, I talked about activity types that are not mentioned in ActivityPub.
Here is a side effect of a
Likeactivity:The side effect of receiving this in an outbox is that the server SHOULD add the object to the actor's liked Collection.
Now imagine that you have an
EmojiReactactivity which server should add to object'semojiReactionscollection as a side-effect.A generic server should be able to do that.
I'm really not following this logic: you are saying "a generic HTTP server should be able to serve WebDAV requests".
Yes, HTTP servers should be able to serve WebDAV requests, *provided* they implement the extension.
It doesn't mean that they *have* to implement the extension. And an HTTP server that does not support the extension does not make non-HTTP compliant.
-
I'm really not following this logic: you are saying "a generic HTTP server should be able to serve WebDAV requests".
Yes, HTTP servers should be able to serve WebDAV requests, *provided* they implement the extension.
It doesn't mean that they *have* to implement the extension. And an HTTP server that does not support the extension does not make non-HTTP compliant.
@raphael @mariusor @steve @evan Your example is incorrect because activity types are not like HTTP verbs.
LikeandEmojiReactare part of the same protocol, both are widely used in Fediverse. Not sure what is the point of twisting the meaning of words to make limitations of certain software appear as non-limitations. -
@raphael @mariusor @steve @evan Your example is incorrect because activity types are not like HTTP verbs.
LikeandEmojiReactare part of the same protocol, both are widely used in Fediverse. Not sure what is the point of twisting the meaning of words to make limitations of certain software appear as non-limitations.The analogy to HTTP is adequate. "GET/POST/DELETE" are verbs, PROPFIND is a verb. It just happens that some verbs had expectations around their behavior defined on spec, others are defined on an extension.
The same thing for AP: it says what to do about as:Like and as:Announce. If you want to attribute any special behavior for as:EmojiReact or for mitra:Subscribe, then it's up to the extension to define the behavior and get people to agree.
-
@silverpill @mariusor @steve @raphael
I think it's a fair critique and one that we should deal with.
However, I think it's possible to provide value where the server implements side effects of AP core, and not for any other Activity Vocabulary activities or extensions.
With the core AP activities, we can probably give clients most of what they need to implement "side effects" for extensions.
-
@silverpill @mariusor @steve @raphael
I think it's a fair critique and one that we should deal with.
However, I think it's possible to provide value where the server implements side effects of AP core, and not for any other Activity Vocabulary activities or extensions.
With the core AP activities, we can probably give clients most of what they need to implement "side effects" for extensions.
@silverpill @mariusor @steve @raphael
For example, let's say we decide that an `Arrive` activity should update the `location` property of the actor.
`Arrive` isn't a core activity in AP. So, instead of expecting the server to change the `location`, the client can send an additional `Update` activity to change the actor's `location` itself.
With CRUD activities and collection activities in core we can get a lot of this done from the client side.
-
@silverpill @mariusor @steve @raphael
For example, let's say we decide that an `Arrive` activity should update the `location` property of the actor.
`Arrive` isn't a core activity in AP. So, instead of expecting the server to change the `location`, the client can send an additional `Update` activity to change the actor's `location` itself.
With CRUD activities and collection activities in core we can get a lot of this done from the client side.
@silverpill @mariusor @steve @raphael
I think there's value in having a negotiation between the client and the server so the server can declare its support for side effects for extensions. A way for the server to say, "I'll handle side effects for geosocial applications". Then the client can skip implementing those side effects itself.
-
@mariusor @steve @evan @raphael An extension is a protocol extension. Specifically, I talked about activity types that are not mentioned in ActivityPub.
Here is a side effect of a
Likeactivity:The side effect of receiving this in an outbox is that the server SHOULD add the object to the actor's liked Collection.
Now imagine that you have an
EmojiReactactivity which server should add to object'semojiReactionscollection as a side-effect.A generic server should be able to do that.
@silverpill @mariusor @evan @raphael "you have an EmojiReact activity which server should add to object's emojiReactions collection as a side-effect."
It's a direct rather than side effect, but how is that different from Add(object=EmojiReact, target=object_emojiReactions)? A generic server could support that.
-
@silverpill @mariusor @steve @raphael
I think there's value in having a negotiation between the client and the server so the server can declare its support for side effects for extensions. A way for the server to say, "I'll handle side effects for geosocial applications". Then the client can skip implementing those side effects itself.
@silverpill @mariusor @steve @raphael
More powerful would be a way for clients or actors to define side effect rules for servers dynamically. "If you get an Arrive activity, set the actor's location."
-
@silverpill @mariusor @steve @raphael
More powerful would be a way for clients or actors to define side effect rules for servers dynamically. "If you get an Arrive activity, set the actor's location."
@silverpill @mariusor @steve @raphael
All that said, I think we can get pretty far with the core AP activities with defined side effects, and extension activities with "side effects" implemented by the client.
-
@silverpill @mariusor @evan @raphael "you have an EmojiReact activity which server should add to object's emojiReactions collection as a side-effect."
It's a direct rather than side effect, but how is that different from Add(object=EmojiReact, target=object_emojiReactions)? A generic server could support that.
@steve By side effect I mean anything that is not directly expressed in the activity, and
EmojiReactusually doesn't specify thatemojiReactionscollection should be updated.Add(object=EmojiReact, target=object_emojiReactions)? A generic server could support that.
Yes, this is what I said in the beginning of this sub-thread. All side-effects should be made explicit (at least for non-standard activities).
-
@silverpill @raphael @steve I think that comes down to what you mean by "support".
I think a server that delivers extension activities, or activities with extension properties or extension types as `object` etc , locally or remotely, is "supporting" those types.
Implementing server-side side effects of some extensions may be a bonus, but we can build a lot of great stuff without it.
-
@raphael @silverpill @steve I also think that Steve's vision is realisable with ActivityPub API, although I think adding optional features like search, server push and so on makes it easier.
@steve Hi Steve,were do i find you Vision? Fredy
-
@steve I believe in this vision.
-
@fasnix @evan AFAIK, @HolosSocial is a quite different architecture. The AP identity is bound to a phone and can't be shared with other client applications. However, I haven't used it. Let me know if this isn't correct.
-
@steve Hi Steve,were do i find you Vision? Fredy
@naturzukunft2026
I'm not exactly sure what you're asking, but there's a W3C ActivityPub API (C2S) Task Force meeting on March 19. That's where C2S extensions will be discussed. It's listed on the SocialCG events calendar. 
Social Web Incubator Community Group - Calendar
The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.
W3C (www.w3.org)
-
What if... you had one Fedi account on a generic headless #ActivityPub server that simply hosts and federates your data... and had C2S UIs for microblogging, long form writing, media editing and sharing, link aggregation, games, fitness tracking, and so on, that all used that same Fedi account. Technically, it's a similar concept as ATProto (but no relay and app view) and Solid Pods (but no RDF).
It seems possible... if we can improve the AP C2S API/protocol sufficiently.
@steve@social.technoetic.com looks similar to https://activitypods.org/ approach ?
-
What if... you had one Fedi account on a generic headless #ActivityPub server that simply hosts and federates your data... and had C2S UIs for microblogging, long form writing, media editing and sharing, link aggregation, games, fitness tracking, and so on, that all used that same Fedi account. Technically, it's a similar concept as ATProto (but no relay and app view) and Solid Pods (but no RDF).
It seems possible... if we can improve the AP C2S API/protocol sufficiently.
@steve@social.technoetic.com I wonder if we want 1 single fediverse account for everything or if it still makes sense to split our identities for different needs
1 server centralizing all my fediverse accounts (via C2S for standardisation) and 1 or multiple client apps to read from this server would be another option. Any thoughts? -
@steve@social.technoetic.com looks similar to https://activitypods.org/ approach ?
@nathan Yes, ActivityPods (Mastopod) is similar, but based on Solid and RDF. The last time I checked, their C2S client was specific to Mastopod. However, that may have changed.
-
@steve@social.technoetic.com I wonder if we want 1 single fediverse account for everything or if it still makes sense to split our identities for different needs
1 server centralizing all my fediverse accounts (via C2S for standardisation) and 1 or multiple client apps to read from this server would be another option. Any thoughts?@nathan Nothing I'm describing would force you to have one account. With multiple accounts, if they are hosted in one server or across multiple servers doesn't change the approach. For now, I'm discussing single actor clients, but theoretically multi-actor clients could be written too (I haven't thought much about that).
-
@nathan Nothing I'm describing would force you to have one account. With multiple accounts, if they are hosted in one server or across multiple servers doesn't change the approach. For now, I'm discussing single actor clients, but theoretically multi-actor clients could be written too (I haven't thought much about that).
@steve@social.technoetic.com yes indeed it would still be possible to have multiple identities with your proposal
I'm also thinking about the migration path. As many people already have accounts on mastodon or others, should they migrate to this new one ?
