Peopleverse. Spritely. And technology adoption

[aschrijver]

(This is a copy of a topic I just posted to the Spritely community in the Social Framing category)

TL;DR Summary

Contributing to Social Framing this topic consists of two parts:

1. Envisioning a Peopleverse as a socio-technical outlook.
2. Clarity on strategy (mission?) of realizing vision. Technology adoption.

Peopleverse is not a name for a technology direction, but an abstract concept of human-scale social technology that fits people’s daily lives and ties the online and offline worlds seamlessly together.

Spritely is a perfect technology that allows spanning up a Peopleverse, but that requires widespread adoption and strategies to tackle the risks that this doesn’t happen. Questions are:

• What is the technology adoption model of Spritely technology?
• Where is the sweet spot between formal spec work and community engagement?
• Given a competitive technology landscape how soon should Spritely broaden their audience?

Vision: Peopleverse

With Fediverse mainstreaming there’s discussions that “Fediverse” is badly named, too technical sounding. On one hand I agree, on the other hand it is a passed station. The name stuck, and maybe organically another name will be adopted in time. Who knows.

But fact is that there’s a lot of technical focus when talking anything Fediverse. Servers, instances, timelines, federation, decentralization, boosting, etc. Not at all relevant for non-technical people that use fedi apps. What they get is a social experience. Federation is a technical concept, and should ideally be abstracted away from average people. Same as apps. What are apps but siloes of features? In an interoperable “social fabric” there might no be any apps. App-free Computing as coined by Chris Gebhardt of infocentral.org.

What I notice on the Fediverse is almost a complete absence of talk about where Fediverse might be in 5 or 10 years. And a general lack of imagination of what the possiblities are, which opportunities are within grasp. The technical focus and the pragmatism of FOSS devs may be the reason. The naming doesn’t help.

So how do FOSS devs generally envision their app? Well, we have ActivityStreams and Mastodon. How can we model our app features on top of that? There’s a dogmatic focus on what corporate Social Media have already done before. Completely foregoing the fact that we just have a core vocabulary here (AS) and an app in a Microblogging domain. That AS/AP is linked data where any semantic vocabulary extension can be modeled for new domains. And in a way to create interoperable building blocks where task-oriented services become available for people.

The Fediverse at large would benefit from having a shared (technology) vision.

Spritely luckily has an exciting techology vision that can be gleaned by outsiders. Though frankly it leans towards a more technical vision. But there’s the “Growing of a Networked Garden” and “Networked Communities” that lead to “Social Media Done Right”. And in the Spritely project Fantasary shows a technical vision of how far that can go.

I wouldn’t use the term “Social Media”. I use “social networking” instead, which is what humans already do for 1,000’s of years, and now also do online. Social Media are the Twitters and Facebooks where you broadcast yourself and get fed ‘engagement’ by the platform algorithms.

What should humane technology offer? An enrichment to our lives. The technology can only ever be supportive to our social interactions.

For the Fediverse (technical perspective) I defined a vision this social fabric to enable the emergence of a Peopleverse (social perspective). The peopleverse is an abstract, ethereal concept, indicating all those places where the technology seamlessly serves our daily lives and human activities. In this idea the Fediverse ‘spans up’ the Peopleverse, if done right.

The Spritely Institute landing page mentions “social media done right”. No. I think that is not enough. This is not about “media”, but broader. The title of an article I wrote is how I would phrase the urgent need we have:

Let's Reimagine Social

Technology adoption

I would like to mention a risk you may be well aware of, but mentioning nonetheless. If these risks are strategized internally in the institute, it may be an idea to discuss them more openly.

The Spritely community (or movement?) is a research community. Discussions are on deeply technical, academic levels to the extent that average devs are like “Very interesting, and all I can do is wait and see where this goes”. Spritely isn’t accessible to the average technologist yet.

It is understandable, as there’s so much of that deep technical work to be done, and Spritely Institute just started can’t handle a full-blown diverse community yet. AFAIU a gradual broadening of scope to encompass more diversity in skills and backgrounds is the strategy. Keep things sustainable, a prudent approach.

Spritely started as a kind of decentralized web successor to the AS/AP-based social web, a “Fedi vNext done Right”, yet with much more universal and fundamental technology base. A complete rethinking of the technology stack with exciting possibilities for decentralized computing. And… opportunities.

But the crux imho on that last bit is massive technology adoption. With Spritely technology comes a paradigm shift. A new and different approach to writing distributed apps. For real success in terms of adoption people it is not enough for people to “sprinkle a whiff of Ocaps” in their solution.

There is some real competition with other emerging technology / tech stacks. In that light the speed of evolution of Spritely should be weighed against the speed of adoption of the ‘competition’.

Fediverse mainstreaming

If we take the Fediverse as example. It looks like critical mass has been achieved (thanks Elon!) and adoption is moving beyond FOSS movement into corporate space. Things are going very fast now. Probably the first thing that companies with plans for the Fediverse will figure out is that after AS/AP became W3C Recommendations the “technology substrate” stalled, and there was only ad-hoc interoperability with apps coding their own AS/AP flavour and introducing Protocol Decay, i.e. tech debt at protocol level. I took notes on the stalled technology substrate.

“Any decentralized [ecosystem] requires a centralized substrate, and the more decentralized the approach is the more important it is that you can count on the underlying system.”

— Byrne Hobart. The Promise and Paradox of Decentralization

It is highly likely that corporations will take over the reigns from the FOSS movement in organizing the standards track. Which is a pity as that would be a missed opportunity for FOSS community to stay in control of the technology landscape they helped bring to success from scratch.

For Spritely the risk is that the Fediverse evolution moves onto a competing standards track, with maybe a DID and Verifiable Credentials, Self-Sovereign Identity direction, which are all picking up steam in various corporate and e-government circles.

Solid ivory tower

Another example I’d like to give is Solid Project. The idea is very interesting, but from the start the objectives and scope weren’t really clear. I have argued about that in their community forum. On one hand a “control your own data” identity vault was a comprehensive scope, but the undertone was also “rebooting the semantic web”. In other words introducing a completely new paradigm, competing with Spritely.

My biggest gripe with Solid Project was their entire focus on writing specs and meanwhile neglecting community-building. I see the team or core members as aloof, largely unreachable by the community. Again, this is understandable, as there’s so much fundamental stuff to figure out.

But imho the inward, technical focus is hampering widespread technology adoption. Community members come, excited, and then they leave again. Possibly forever. Solid Project is also strategizing for a commercial application-first technology adoption. Which may be a sound approach, idk, but in my experience it is often enthusiastic developers that drive adoption from a bottom-up direction.

Grassroots vs Formal ecosystem evolution

Solid Project and Fediverse are two extreme opposite in the way that technology evolution takes place. Both have problems. On one hand the (very) formal steering body of Solid creates ever more intricate specs, and on the other hand the Fediverse slides into ever more protocol decay by ad-hoc app development. I depicted this in a diagram some time ago:

For the Fediverse I questioned “Why can’t we seem to evolve the technology substrate?”. I came up with a set of major challenges for the Fediverse to overcome, none of which are really technical in nature. They are social problems, that may have socio-technical support to help overcome them.

The biggest insight was that in a grassroots movement (of fedizens in this case) the dynamics and culture as such that alternative technology adoption models should be applied. Models where the motivations to start and sustain FOSS projects are taken into account, and the proper incentives to contribute beyond direct project scope must be provided. And the expectation of the win-win to do so, must be clear.

Also, related, that the FOSS movement is strong in its technical abilities, at the project level, but extremely weak in all the non-technical areas and in collaboration on ecosystem levels where the technology landscape matures. Why can Big Industry have global supply lines and profitably exploit ultra-complex factories, and a small-scale FOSS project cannot even sustain itself?

For this reason I started Social Coding Movement. The movement will consider the entire Free Software Development Lifecycle (FSDL) and find best-practices and tools to support it. Social coding practitioners (projects, communities, software guilds) will crowdsource these to the Knowledge Garden, a pattern library.

Tackling tech adoption risk

In summary, what is Spritely’s strategy to tackling risks to come to widespread technology adoption? What is your adoption model, and what does that mean for approach in building the Spritely movement? Where is the sweet spot between formal approach and grassroots development (see diagram above)?

[onepict]

@aschrijver

My biggest gripe with Solid Project was their entire focus on writing specs and meanwhile neglecting community-building. I see the team or core members as aloof, largely unreachable by the community. Again, this is understandable, as there’s so much fundamental stuff to figure out.

This is also my problem with solid. I think designing and building the tech has to go hand in hand with building the community.

[aschrijver]

Alan H. Karp responded to my message on Spritely forum:

A fascinating read. Your “Let’s Reimagine Social” triggered a thought that may be relevant, but I’m not sure. (This reply got a lot longer than I intended, but you can skip to the last 2 paragraphs.)

In 1996 I had the opportunity to work on something I called The Global Computer. The idea was that you didn’t have to be aware of the boundaries between machines. Your stuff was on your desktop, whether the item was local, on the machine of someone who shared it with you, or on a machine you never heard of because of transitive sharing.

The unifying principle we came up with is Everything is a Service. An application is a service, a piece of static data looks to you like a service, even you are a service. That vision was implemented by giving everything an API, which allowed our customers to create complex applications by assembling preexisting services. Including people as services was important to the idea. Our Alpha release was December 1999, so there are lots of concepts, e.g., the cloud, that we weren’t aware of or we might have done some things differently.

One example is a travel portal one of our customers built. Say you’re taking a trip consisting of a flight, a hotel room, and a rental car. You would like the airline to notify the hotel and rental car company if your flight is delayed, but making direct connections could be a privacy problem and is unscalable for more complex examples. Instead, we suggested that our customer make the trip a service. The airline could then inform the trip service of the delay, and the trip service knew what to do. Since the traveler was also a service, the traveler could be included in the notifications. We used ocaps so that only the airline could invoke the “delayed flight” API. There were many problems we never solved, such as competing APIs for similar services, but the customer said making the trip a service saved them some 10,000 lines of code. (I have no idea why so much code, but that’s what they told us.)

Now imagine an environment in which we interact with people rather than applications. Each person has an API, which can be constructed by assembling applications. For example, you could create a book club by standing up an instance of a “group” service and giving an ocap to people you’d like to include so they can invoke the book club method of your API. Members can invite others by delegating access, but ocap mechanisms allow you to do responsibility tracking so you can revoke the access of someone who keeps inviting jerks.

I can envision an environment where a non-technical person can plug together services to manage their personal APIs. (I didn’t use to think that until I saw what some people have done just with the if-this-then-that model for their IoT devices.) Is this along the lines you’re thinking?

And I answered:

( I made some off-topic wanderings in this post as well, I’m afraid )

I started work in the Print industry in 1997 and going from SGML passing through the entire XML hype cycle up to Service Oriented Architectures. We were doing a lot with workflow engines, automating business process for involved print automation flows involving many different parties.

alanhkarp:
The unifying principle we came up with is Everything is a Service. An application is a service, a piece of static data looks to you like a service, even you are a service. That vision was implemented by giving everything an API, which allowed our customers to create complex applications by assembling preexisting services. Including people as services was important to the idea.

Yess. It leads to a more natural way of offering people automation in support of their day-to-day activities. And one where regular folks can wrap their heads around what a service does. Like a coffee grinder “grinds coffee beans” as a service, has the “Start” button as the API and takes coffee beans as input data. If it were a building block I would connect it to my Espresso machine that takes “ground coffee beans” and water as inputs and outputs espresso. I might tie it to my water dispenser building block as well.

The tricky bit I think is in “giving everything an API” where all these API’s are created independently of each other by different people who are unaware of what other are creating. How do they tie together? And how do they keep working while all these API’s are in flux?

I don’t know about all the ways ocaps can be modeled, but am really intrigued about how they may offer “intention revealing interfaces” where what you can do at any one time depends on your prior interactions and the state that has built up in the service you are invoking.

That said in Solidground project I am looking how Strategic domain driven design can keep non-technical stakeholders in the loop, and Bounded Contexts in the domain design are the consistency boundaries that are input to event driven architecture. These contexts exclusively trigger Domain Events that are consumed elsewhere, local or remote, by actors feeding them into other bounded contexts.

I looked briefly at Cap’n Proto Schema Language (which ForgeFed is experimenting with for intermediary adoption in a transition to Spritely) and have difficulty in picturing how that would fit in above design. Instead of domain events raised from an internally consistent bounded context I’d have to take into account remote API contracts instead. That seems to limit the flexibility and resilience to change of the overall network?

But I digress wrt this topic (though my architecture may not fit ocaps?). The decomposition in sub-domains that DDD offers would be a basis for offering concrete services and on the wire they’d be namespaced objects, activities and properties in ActivityPub messages. AP vocab extensions may be fully standardized, domain-specific, or custom / app-specific. These extensions are building blocks for meaningful msgs between services. For a “Sociocracy” bounded context I may model “Community” based on as:Group and as:Relationship and use Governance and Sociocracy vocab extentions to specialize the message formats.

alanhkarp:
Now imagine an environment in which we interact with people rather than applications. Each person has an API, which can be constructed by assembling applications. For example, you could create a book club by standing up an instance of a “group” service and giving an ocap to people you’d like to include so they can invoke the book club method of your API. Members can invite others by delegating access, but ocap mechanisms allow you to do responsibility tracking so you can revoke the access of someone who keeps inviting jerks.

In ActivityPub we have Person actors joining the Group book club. We might express as standard ActivityStreams. All the activities in AS are already events (“something happened”). The only capability for a non-member would be to join, so sending a Join{Group} might represent the request to join (BookClubJoined), followed by an Accept{Join{Person}} response back to the person (MembershipAccepted). Expressing in a domain-specific vocab extension might make the semantics clearer. (In general I feel that fedi devs overuse AS and foregoing the linked data aspects that would allow more meaningful formats).

I guess in an Ocaps version the Accept would either include the capabilities or a place where capabilities can be retrieved from, that are now available through the person’s membership.

But again this is off-topic, though areas where I have questions…

alanhkarp:
I can envision an environment where a non-technical person can plug together services to manage their personal APIs. (I didn’t use to think that until I saw what some people have done just with the if-this-then-that model for their IoT devices.) Is this along the lines you’re thinking?

Exactly. I envision a decentralized technology base that enables anyone to spin up services with relative ease and reusing building blocks that others have created. An environment where the Commons has a much bigger chance to stand up to forces of hypercapitalism where only big corporations are able to provide useful platforms. I believe that will mean there’s a mix’n match of expert development needs, low-code development where the so-called “99% developers” can participate, and no-code composition of building blocks into solutions. This will also create a sustainable environment where small-time FOSS developers can eek out a living.

I am thinking of the emergence of so-called “residential social networks” that target specific geographic regions, like a town, city or rural area, where the network supports the local economy and social cohesion. These networks do the opposite of what Social Media do: they bring people together.