ForgeFed
New ForgeFed #Blog post:
Stabilizing the Object Capability System
https://forgefed.org/blog/stabilizing-ocaps/
Where to comment: Right here on the Fediverse :)
--pere
#forge #ocaps #activitypub #forgefed #federation #haskell #fediverse #decentralization #development
silverpill
>It seemed that Fediverse apps are mostly in the field of personal content publishing and sharing, and ForgeFed is almost alone trying to use ActivityPub for collaborative resource access and complex distributed authorization.
I think content sharing services can also benefit from ocaps, in areas such as reply control or spam protection. I touched this topic here: https://socialhub.activitypub.rocks/t/fep-5624-per-object-reply-control-policies/2723/33 (although something simpler, like a verifiable credential, might be more appropriate for reply control use case).
>ZCAP, while evolving over the years, is still a draft, still changing, and still relies on Linked Data signatures, which are a big burden, requiring an implementation of complicated JSON-LD algorithms
ZCAP spec seems to be aligned with Data Integrity spec, so it should be possible to use other signature suites like jcs-eddsa-2022 (as in FEP-8b32).
>OCAPs have a start time and an expiration time
If your representations have Data Integrity proofs, you may use created and expires properties (related issue: https://github.com/w3c/vc-data-integrity/issues/78)
cc @h
silverpill
cc @pere I hope you'll see this post ^
silverpill
@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.
infinite love ⴳ
@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.
infinite love ⴳ
@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
pere פרא
@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?
silverpill
@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
infinite love ⴳ
- 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?
infinite love ⴳ
@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
pere פרא
@aka_dude @forgefed The transaction stuff is inspired by Spritely Goblins, check out their docs:
https://spritely.institute/files/docs/guile-goblins/0.11.0/Transactions-make-errors-survivable.html
In my case it means using DB to persist all actor state, including message queues. I've though of wrapping it in STM, Idk yet if it's necessary, will see :)
I assume you mean run the LMDB transaction in a separate thread that sets a TVar/TMVar after the transaction, and/or get the input data via a TVar, and other threads can then use LMBD via STM?
aka_dude
@forgefed@floss.social hey, can you elaborate on transactions a bit? It sounds to me (I've probably misunderstood) that transactionality can be achieved by having local transactions on actors (via STM for in-memory computations or database transactions for stateful changes) and providing methods that expose transactionality to callers.
I am interested in transactions, currently implementing binding to LMDB that can be used in STM. Wonder if my findings can be helpful for Vervis
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.