@virtualpierogi @sri @jsalvador @ben @michiel @nlnet

Yes, I've noticed that in #FOSS realms there's a rapid change to the development processes that are followed. Where projects no longer allow people to just contribute PR's.

In many github projects for instance you should first start a Discussion and get dev team's consent to create an Issue, which you may then create a PR for. Any other direct contributions are either disallowed or immediately closed.

There was also this Vouch reputation system that got popularity real quick. And there'll be more changes like that I think.

https://github.com/mitchellh/vouch

https://news.ycombinator.com/item?id=46930961

I've been looking at #ForgeFed and how it is set up. Currently it models very much the application model of what constitutes a typical "Code forge", but this is restrictive and going from lowest common denominator between forges. There's opportunity here to focus on the domain of "Software development" and the (social) coding processes between all stakeholders.

@virtualpierogi @sri @jsalvador @ben @nlnet

When it comes to #interoperability there is no way around having consensus on what you interoperate on, and there must be alignment on some kind of Video related domain model that is robust and consistent.

If there were a robust #ActivityPub extension mechanism as well as good development practices and processes for the creation of extension into new business and application domains, then this mechanism can still facilitate app-specific extension on top of such a Video domain specification. It is very common for protocol design to have all kinds of extension points, look e.g. at #ATProto or #CloudEvents.

And more specialized domain extensions can also facilitate further extension in their design. Look e.g. at #ForgeFed AP extension, which allows custom forge-specific metadata collections to be sent with a federated Issue or PR.

@thisismissem @eyeinthesky

I just responded in the other thread about #ForgeFed way of dealing with Issues and PR's, emphasizing the actor model in the #ActivityPub 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.

https://social.coop/@smallcircles/116096769625606025

@thisismissem @deadsuperhero

I was looking at #ForgeFed which is a very sizable #ActivityPub 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 #SocialMedia as but a small subset of #SocialNetworking.