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.
I can't wait to see what you build! Good luck.
Maybe I am way over my head, but this seems like *exactly* what I am building right now and I'm not really building anything outside of ActivityPub C2S?
I mean... Yes, my current client assumes some specific profile for OAuth and the client will need a proxy to get some data remote servers (to bypass authorized fetch, or to resolve documents from transient activities), but doesn't seem to me that anything I am doing is outside of AP's scope?
Silverpill does not agree with us. I am wishing Silverpill well in their plan to rebuild with a completely different ground-up API. Silverpill is skilled and smart and very familiar with ActivityPub in great detail, so I'm sure they will come up with some interesting API architecture.
@raphael @silverpill @steve I don't intend to stop working on the ActivityPub API.
There are a lot of us collaborating through the SocialCG ActivityPub API Task Force, and I expect that collaboration to continue:
@evan @raphael @steve I think a generic ActivityPub server can't be built without major changes to ActivityPub. For example, it might be necessary to make all side-effects of activities explicit.
And there is a bigger problem. A generic server without FEP-ef61 is like ATProto PDS or Nostr relay but all data is tied to a single server. This means that it is obsolete before the work has even begun.
@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 server
Wow, 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.
@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
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
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.
Steve Bate
silverpill
Evan Prodromou
Raphael Lullis
marius