What if...
-
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 FEP-ef61 makes it possible to build a server that only talks to other servers or to a client that pulls inbox (i.e. received activities) and pushes to outbox (outgoing activities). tootik is very close to this, I'm working on a 'local mode' where the server and the UI run locally but synchronize with a server in the internet, a 'dumb pipe' that can send and receive activities.
-
@lori I don't know what semaphore social is, and I don't know if goto social is server only (probably not in the way that I meant - where "the server" is an ActivityPub C2S server)
-
@lori so, Semaphore social seems to be is the project from which Pinafore started. And they are both Mastodon clients, not ActivityPub client to server clients. So no, my server does not support the Mastodon client API.
-
@silverpill @evan @raphael Several generic AP server implementations have been built, so I don't know what you mean by the side-effect comment. Note that my mental model of a generic server doesn't implement any domain-specific behaviors in the server, but only side-effects specified by AP (and extended generic C2S support). There are also simpler ways to design servers so that content isn't tied to a specific server (with different tradeoffs than FEP-ef61). That's a long discussion...
@steve @evan @raphael A server can't properly process an arbitrary activity without knowing its side effects. A server that only supports a small number of activities mentioned in the ActivityPub spec is obviously not generic.
I can point to other challenges because I've been working on this problem for years, but...
Several generic AP server implementations have been built
There are also simpler ways to design servers so that content isn't tied to a specific serverWow, for real? I suppose it's time for me to retire then.
-
@steve @evan @raphael A server can't properly process an arbitrary activity without knowing its side effects. A server that only supports a small number of activities mentioned in the ActivityPub spec is obviously not generic.
I can point to other challenges because I've been working on this problem for years, but...
Several generic AP server implementations have been built
There are also simpler ways to design servers so that content isn't tied to a specific serverWow, for real? I suppose it's time for me to retire then.
I don't follow: how does that relate to the "ActivityPub API" if the activity is "arbitrary" and not defined by ActivityPub, not using AS2 vocabulary?
Isn't that like saying that we can't use HTTP as a protocol because an HTTP server doesn't know what to do with verbs defined on, e.g, WebDAV?
-
@steve @evan @raphael A server can't properly process an arbitrary activity without knowing its side effects. A server that only supports a small number of activities mentioned in the ActivityPub spec is obviously not generic.
I can point to other challenges because I've been working on this problem for years, but...
Several generic AP server implementations have been built
There are also simpler ways to design servers so that content isn't tied to a specific serverWow, for real? I suppose it's time for me to retire then.
@silverpill I think you're getting confused about ActivityPub side-effects and application logic side-effects.
I call my project FedBOX a "Generic ActivityPub server" because outside of storing ActivityPub objects and activities to a local storage and dispatching said activities to their recipients it doesn't do anything else.
However there's nothing preventing someone from forking the project and adding some other type of logic to it for specific combinations of Activities/Objects. That's the thing I'm trying to do with my GoActivityPub library: take care of the ActivityPub stuff, so you can then do your own stuff alongside it.
-
I don't follow: how does that relate to the "ActivityPub API" if the activity is "arbitrary" and not defined by ActivityPub, not using AS2 vocabulary?
Isn't that like saying that we can't use HTTP as a protocol because an HTTP server doesn't know what to do with verbs defined on, e.g, WebDAV?
-
@silverpill I think you're getting confused about ActivityPub side-effects and application logic side-effects.
I call my project FedBOX a "Generic ActivityPub server" because outside of storing ActivityPub objects and activities to a local storage and dispatching said activities to their recipients it doesn't do anything else.
However there's nothing preventing someone from forking the project and adding some other type of logic to it for specific combinations of Activities/Objects. That's the thing I'm trying to do with my GoActivityPub library: take care of the ActivityPub stuff, so you can then do your own stuff alongside it.
-
Then I'd echo what @mariusor said: it seems like you are conflating the server with the applications built on top of it.
-
@silverpill @mariusor @evan @raphael You're starting to get it!
You quoted "extensions" in the previous post and that was good since the way you think of "extensions" is likely very different than my view. The generic servers I'm discussing *are* highly "extensible" (more than most current Fedi implementations). -
@silverpill what are extensions exactly? Are you talking about FEPs that proscribe behaviour alongside structure, or ActivityPub extensions as allowed by JSON-LD.
The FEPs that proscribe behaviour can't ever be done in a "generic" way, and I'm betting you already know that and you're just being facetious.
However the JSON-LD dynamic structure can be reasoned about generically from an ActivityPub point of view using the points I made above: storage to disk, dispatch to recipients.
If you plug smart clients on top of that that have the specific logic you want, you're all the way there to what Steve was talking about.
-
It is a generic server *because* it is focused only on the ActivityPub API, unlike most of the existing services that interop only with specific APIs (Mastodon's , Lemmy's).
A "generic server", in my view, is one that can take any type of activity posted to a box, and dispatch to the proper targets. The ActivityPub API defines only what to with like/announce/follow. Anything else is up to the application. That's the extensible part.
-
@silverpill what are extensions exactly? Are you talking about FEPs that proscribe behaviour alongside structure, or ActivityPub extensions as allowed by JSON-LD.
The FEPs that proscribe behaviour can't ever be done in a "generic" way, and I'm betting you already know that and you're just being facetious.
However the JSON-LD dynamic structure can be reasoned about generically from an ActivityPub point of view using the points I made above: storage to disk, dispatch to recipients.
If you plug smart clients on top of that that have the specific logic you want, you're all the way there to what Steve was talking about.
@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.
-
@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.
