New ForgeFed #Blog post:
Stabilizing the Object Capability System
https://forgefed.org/blog/stabilizing-ocaps/
Where to comment: Right here on the Fediverse :)
--pere
@forgefed reading this, i have to wonder: if you think activitypub is for publishing, then why are you trying to use it for invocation? why not use something more rpc-like instead? conceptually it seems like y'all are trying to turn email into a programming language
@trwnh I'm trying to keep it in line with ActivityPub and the current Fediverse. I do intend to use something RPC-like, in a different project and a different name.
Does that answer your question? / Do you have a proposal?
@pere mostly i'm just wondering why bother using ActivityPub for anything other than notifications and bridging into issue trackers. the closest analogue is email, and it makes sense to treat AP like that. trying to turn AP into a programming language or using it to do method invocation is *possible* but doesn't seem like a particularly good idea.
@pere like, there is a difference between "doing the thing" and "describing what happened". activitypub is better at doing the second thing, and is very limited at doing the first thing. there's no schema or contract or anything signaling that the side effects will be handled as you intend. so why make it try to do that?
@trwnh @pere Why not? We have a large distributed network where nodes are sending data packets to each other. These data packets may represent social interactions, but they may also represent anything else.
The success of Fediverse provides an unique opportunity for ActivityPub to evolve into general purpose protocol.
It was also (over) engineered to accommodate this sort of thing in the first place. It’d be a shame to accept the complexity without the flexibility.
- The representation is based on describing resources, a Resource Description Framework (RDF)
- When you produce an ActivityStreams document, there is the expectation that it should be possible to show it in a stream of activities
- ActivityPub lets you send Linked Data Notifications and prescribes some limited side effects for managing objects and collections
Again: You could define your own activities and side effects, but why do that when you could do proper RPC?
@silverpill @pere This is something that I have also toyed with -- the concept of programmable actors that use ActivityPub as a message-passing framework. It's part of why I want to see a truly generic Server. You could build a distributed computer over ActivityPub if you really wanted. But part of me stops to question if we "should" even though we "could".
cc @ademan
@trwnh I think this is inevitable. People can't resist the temptation to use the same tool for different tasks, and in case of ActivityPub/ActivityStreams, I think this is actually not a bad outcome, because of how extensible the data model is (especially if one is willing to break some rules). Even newcomers who have just learned that Lemmy and Mastodon are part of the same network are wondering now, "can we make federated X?". Many such cases
I've no problem with the use of AP for the project management side of code forges -- issue trackers and discussions can be modeled fairly naturally, although how precisely is a matter of debate -- I'd consider the use of Question and/or a subtype extension, so that `closed` can be used. I'd also consider an extension for "disposition", i.e. the reason it was closed. And of course `context` for keeping track of the issue/topic being discussed. But beyond that? IDK...
Which is to say: the more custom vocab you define as necessary, the less understandable you become. There's only so much you can do with name/summary/content. And the other side of things is that the more you start to use it for side-effects and performing actions, the more you probably want to use some kind of RPC instead. In the case of git forges, you could Offer a .patch file maybe, just like in email attachments. You could verify ACL/Ocap authorization. And so on
But you eventually reach a point where the thing you are doing doesn't need a representation in activity form. It just needs to be done. And at that point, all this becomes overhead, trying to express stuff in more-or-less natural language SVO when you could just instead say "do this" and it gets done.
I agree with you about the need for RPC, and AP not being a suitable RPC tool.
Right now I'm still working on the AP-based ForgeFed, but I'm already in transition to actor-programming, and the next iteration - for which I hope to publish a minimal demo in late 2023 - will become my focus in 2024.
Am I wasting my time, doing the AP-based stuff using AP-based custom OCAPs instead of real RPC? Maybe. I'm at peace with it either way.