Protosocial ActivityPub protocol is an extension of W3C ActivityPub that focuses on ease of use for the development of fediverse solutions and services. Together with comprehensive guidance and design tools it provides solution developers simple ways to model rich and interactive social web experiences.
Come to our Common social groundwork chatroom if you are interested to learn more.
Protosocial ActivityPub is an opinionated protocol extension of the W3C ActivityPub social web protocol, that is particularly suited for the design and composition of intricate social networking solutions, with a good developer experience. Designed for ease of use, Protosocial ActivityPub exposes a service-oriented social graph of addressible actors to exchange semantic information with.
| Conceptual layer | ||
|---|---|---|
| 3. | Information layer | Knowledge graph, linked data, open world |
| 2. | Service layer | Event-driven, actor model, schema-based, closed world |
| 1. | Access layer | Social graph, actor discovery, service introspection |
In the access layer a Protosocial provider spins up an actor system, and starts one or more application actors. When the actor system is ready, the social graph is accessible to discover actors on the network and communicate with them. Each actor may expose services that can be introspected and invoked to initiate in message exchange between actors.
In Protosocial ActivityPub…
Application actors.ActorSystem, one or more Application actors.Application actors facilitate discovery, introspection, invocation of services.Service actors.Inbox for messages, can create child actors, can call other actors.ActorSystem.Unlike W3C ActivityPub the Protosocial extension…
sharedInbox.Protosocial extension is service-oriented by means of Service actors. There are 3 service types:
ActorSystem, relating to the host.
System application actor offers e.g. HostInfo, HostAdmin, AppServices services.Application actors offer to solution services.
(Background to this post was prior discussion in the Common social groundwork matrix chatroom with @stevebate @indieterminacy and @trwnh.)
I think this is a bad first sentence.
You are right. These are just the notes I took on the basis of earlier chat.
Though to kick this off, I think the start will be quite technical, just to lay out the overall direction, high-level architecture and protocol design decisions, and such. Align on foundational technologies very low in the tech stack, where a solid and robust basis, are like the concrete engineered pylons of a bridge. The elegance of its well-designed road deck become highlights of its glossy ‘sale pitch’, but it must be able to uphold itself first.
I guess the unapologetic holistic approach is a fair description of this effort, and that also includes what it means to be an extension of W3C ActivityPub. In other words make the extension mechanism an integral part of the protocol guidance and support, and not something that is handwaved to ‘linked data got you covered’.
Wrt this holistic scope:
Right now the assumption, but also my observation, is that ideas for new fedi apps are flying around like crazy all of the time, by people unable to realize them unless they manage to hook up with a fediverse expert, or become one themself. Which means crunching through all the cruft. The onboarding of new devs is way too steep, and this is holding back innovation.
At a holistic level SX uses the notion of Service development, Service delivery, and Service exchange, which are functional domains to be elaborated against the paradigm shifts that SX brings. Which involve - in the technnical layers of the Commons based social stack - an actor-based service-oriented and event-driven architecture design.
When looking at the sticky note that started the SX design of ProtoSocial AP, the “Ease of use” involves the deliberate focus on particular stakeholder groups. Where now there’s just “Developer” stakeholders (the foolhardy ones, that bite the AP bullet), for starters, there’ll be a split in:
I wonder if @ivanminutillo and @mayel are willing to chime in here, wrt Needs. A number of years ago now I was talking to Ivan who asked feedback, when there was important decision-making for the Bonfire project direction ahead: Either focus first on Bonfire Social to get onto the Microbloggoverse, or focus on becoming a versatile App development framework first.
I argued that imho the strongest USP of Bonfire was its potential to become a Solution development SDK to quickly design and launch interoperable fediverse services with. In other words “Solution development” is a core business domain. And that focusing on Bonfire Social was a distraction to implement a “Microblogging” subdomain, which every other fedi app already delivered. That focus on Bonfire Social would cost years to make it sufficiently polished and production-ready. And leaving the whole Solution development domain, the biggest USP, underdeveloped. This while a good federated services SDK would enable a FOSS ecosystem, where most likely someone would build a Microblogging service with Mastodon compatibility built-in.
Ivan and Mayel chose to first put Bonfire Social in production. There’s no good or bad to this decision. It boils down to what Bonfire wants to be as a project. But I wonder how in hindsight is looked back on this decision, and what the thoughts are with regards to the future of Bonfire wrt to positioning as an easy app development environment that gives meaning to “joining the fediverse”.
What happened if you zoom out, generally speaking, that fedi developers not focusing to improve the foundational technologies they rely upon, means these technologies continue to be a liability. Bonfire will have to participate in whack-a-mole driven development, will have to swallow protocol decay on each interoperability feature with some other app, and their stakeholder group of Solution developers will have to be shielded from that to make the software an attractive fedi devtool.
The post describes both a protocol and toolkit, so I’m commenting on both here.
The three layers seem to address only half of the problems that AP implementors face:
I understand you see these as implementation details, but I think Protosocial needs a more opinionated stance on how these parts fit in, if developer experience is important.
User interface and identity make up huge parts of any AP implementation. Without these “batteries”, Protosocial only adds more barriers to enter into the Fediverse, since all solutions must be reformulated as Actors, and those actors now have to conform to Service and Access layers.
The only benefit that I see with Protosocial is a runtime, which IMO isn’t sufficient to attract AP devs.
Since Protosocial doesn’t seem to do the user-side of things, I can see how Nodeinfo and WebFinger are irrelevant to it. But when user-actors require discovery, etc., WebFinger and Nodeinfo are needed. Why doing away with them?
To extend, we must add more to an object that already exists. Protosocial takes a subset of AP (removing shared inbox), and bypasses the effects of the FEP process (Nodeinfo is an FEP). I would argue that this is an AP-flavored protocol, but isn’t an extension of AP. Without clear agreement on the bounds of modification (extension, subset, flavored, etc.), we might end up breaking interoperability.
Thank you, @realaravinth! Currently you are just viewing my first notes, to help give direction to the discussion. Adding your feedback onto that, much appreciated!
Copied from chat in response to @helge …
What I am thinking about around ProtoSocial ActivityPub is “back to the drawing table”. Spec recommendation is the basis, the starting point. Now suddenly all the flexibility that is in this document and its related ActivityStreams (AS) companion specs, becomes the clay to work with. My thought is - in the same way that AS types are now used as universal social building blocks, but haphazardly and randomly - ActivityStreams primitives can be reserved to assign rigorous protocol behavior. The kind of stuff you need as a basis to then subsequently define your vocabularies for all the intricate domain-specific components, services and solutions to deliver to the heterogeneous social networking environment.
I mean drawing table in the definition that AP by its flexibility is de facto a protocol framework. I can ‘project’ ProtoSocial onto that, and it becomes like an overlay providing higher order functionality. Specifically around hammering a robust set of architecture patterns together in place to form a foundation for solution developers. Like service-orientation, EDA, and actor model in a particular arrangement. Where the extensibility model of AP leaves things unspecified (i.e. almost everywhere) the model is open to design something that will support a good solution development processes.
(In this discussion there may come some confusions on terminology, so another aim of ProtoSocial is to be written entirely in a consistent ubiquitous language, and use that everywhere in that context from the very start and then evolve it)
I think of specific uses for AP primitives, including actors. For a long time, as you know, I advocated the “community has no boundary” idea, around the Group actor. I view “Community” as a composed concept, made from simpler primitives or building on them. In any case in a ProtoSocial AP solution you’d be able to introspect an actor endpoint for the services it provides and ‘learn’ enough about its “Community” definition to start to interface with it. (The extent to which this is automated is up for experimentation and elaboration. If you go all the way you get into high-complexity zones where Solid Project hangs for years now).
After I bumped onto Rich Hickey’s fabulous presentation on Hammock Driven Development - which I recommend as a MUST SEE for anyone active in the FOSS movement - I thought to check out more of Rich’s presentations.
And I found another 
delightful gem, that is excellent to serve as a starting point for Protosocial elaboration. Especially where it comes to crossing over from the social layers of the Commons based social stack into the technical system layers below, that are tasked with hosting the various solutions and social experiences.
Both of Rich’s presentations were given at a Clojure conference, yet there isn’t a single line of clojure code. The entire talks are about essential mindset shifts to make as a programmer to know what to code, for whom, and why. To work from problems and needs towards validated and well-design solution space.
I am delighted to find in how many ways my findings around SX methodology start to naturally align and fit with existing systems-thinking practices. Both videos also highlight where so much of ongoing fediverse developer discussions are not following these mental models and get stuck in all kinds of complex technical confusions.