🫧 socialcoding.. @smallcircles@social.coop
Public

@thisismissemEmelia 👸🏻 @deadsuperheroSean Tilley

I was looking at which is a very sizable extension (constituting the "Code forge" app domain in app-centric view, but arguably "Software development" top-level business domain in a service-oriented fedi).

The way that things are modeled here adheres more to the actor model where there's a Factory actor, which in turn creates resource actors that expose various sub-domains. For instance for the management of Issues and PR's there's a TicketTracker actor to obtain via a Factory actor on a forge instance. Though I'm not sure whether I'd modeled that in similar fashion, it is a fascinating direction where we focus much more on good protocol extension design.

All in all AS/AP offers a very granular foundation that allows for very interesting architectures, if only we dare explore them and do not dogmatically stick to some engrained notion how "social media" ought to be. I see as but a small subset of .

0
1
1

If you have a fediverse account, you can quote this note from your own instance. Search https://social.coop/users/smallcircles/statuses/116096769625606025 on your instance and quote it. (Note that quoting is not supported in Mastodon.)

🫧 socialcoding.. @smallcircles@social.coop
Public

@thisismissemEmelia 👸🏻 @eyeintheskyThe Eye

I just responded in the other thread about way of dealing with Issues and PR's, emphasizing the actor model in the specs.

Guess it depends on the nature of your extension and its desired functionality how you model things, but ForgeFed chose to have a dedicated actor, a TicketTracker, to manage the collection. Big advantage is that it become a truly encapsulated service with its own business logic, fronted by an AP actor for interoperable network communication.

social.coop/@smallcircles/1160

0
0
0