The description of the Spritely Architecture category reads:
Design a world safe for decentralized OCAPS, persona and communities.
âWorldâ here implies mass adoption of OCapN technologies.
âpersona and communitiesâ imply every day common people.
âDesign a worldâ implies many different use cases and domains.
âsafeâ implies delivery of solution that satisfy stakeholder needs.
Those are all visions, but also promises conveyed or implied, that have led people to have particular expectations on what and when Spritely will deliver. Expectations that may or may not be justified.
But there is no way too tell.
Because the main focus has until now been primarily on the âdecentralized OCAPSâ part of that sentence. The deeply technical layers where only experts can follow.
That is perfect valid choice, as it is Spritelyâs internal decision.
But is it the best technology introduction strategy?
And is it the appropriate technology adoption model?
When Spritely is ready for the world, thereâs no one there to start running immediatelyâŚ
Because they didnât warm up, trained and prepared, to put on Spritely design shoes straight from the lab.
@frandallfarmerCommunity Pattern Language addressed an entirely different side of Spritely. One where from higher levels of the stack can be drilled down to meet and align with the core foundation work done. I wouldâve loved to see that get given more attention and energy. Now, it looks stalled or far-off intent to start this ideation process.
I cannot fathom what is best approach, and I expect no response. I respect your decision-making and this is just feedback of a desire to be more closely involved, even if still only as a technology watcher.
This morning sitting down with to read the monster thread at ease, I found a partial answer to how Spritely intends to move forward. @cwebbermentions:
The ocap stuff, I tried getting fediverse implementers excited about this and tbh, itâs pretty hard to design into a Ruby on Rails or Django style framework and mindset. Backporting the right designs to existing systems is a real challenge.
Especially ocaps need to go bottom-up.
For this reason, @spritelyâs tech looks like itâs very focused on computer scienceây low-level BS, but thatâs actually because itâs too hard to build the systems I want right now on top of current technology, we need stronger foundations
But people have to build for today too
You also mention, paraphrasing:
Spritely aims for a for a socially collaborative revolution, is first focuses on a technical revolution.
Which looks like a good approach. But how can other parties walk alongside of you and address other aspects of the âsocial stackâ that you will be relying on later when the time is right? How can there be most efficient mutualistic relationships in the intervening time period?
Itâs too hard to build massively, securely collaborative tools right now. With Spritelyâs tools, p2p ocap secure tech is the default output.
Esp. in what⌠how many people are in the Spritely team now? It will take decades. While masses of helping hands sit idle awaiting the technology.
I can offer help.
Just like Spritely Institute is developing a crucial missing technical component in the network communication stack, I am raising the Social coding movement to address big hurdles the fediverse grassroots ecosystem faces to evolve the social web standards and installed base.
Where Spritely has a virtual game world, the Fantasary as its ultimate PoC of a working ocaps technology foundation, the social coding movement has a similar intricate framework to develop. Here it involves entering a new field of Social experience design (SX) with many people in different skillsets, where social networking solutions are âsocial experiencesâ (choreographed apps & services) and the exploration involves finding design methods and tools to help support the social stack across all layers.
Weâll also have our own Fantasary. I tooted about it the other day to provoke thought (the toot was misunderstood by commenters). It is the notion that âParticipatory software developmentâ is just another social experience on the social network, that coding is social, and coding tools are provided by countless apps & services delivered from the fabric of a vibrant interoperable ecosystem, where sustainable FOSS SMBâs can easily thrive.
If that is hard to picture, think if forges + forge federation were able to really compete with the likes of github and other full-service delivery providers that hopped onto the one-stop-shop trend of platforming (becoming everything-apps for devs).
Without social coding fantasary FOSS has no chance to catch up and rival with Big Tech to offer more inclusive services to every day common people. Just like Spritely OCaps the opportunity exists, and the potential is there for something ârevolutionaryâ (though I rather use the word âevolutionaryâ).
Just started at Social Coding movement, 2 initiatives:
If you are interested to explore how there might be a collaboration with social coding movement, please respond below. I think there are many opportunities and benefits to collaborating, and also to do that so gradually that it hardly incurs additional workload on spritely team members.
Further in the thread still, there is a section on Blueskyâs intent to take into account that âthe organization is a future adversaryâ. Yep. That is how the corporate hypercapitalist approach necessarily must be, in order to instill enough trust to execute.
Fun stuff. But not applicable to a grassroots commons in control of technology foundation.
Here we should learn to âleverage the ecosystemâ, to pick & choose who best to collaborate with and maximize each others productive output in mutual beneficial relationship. We must ensure that the grassroots ecosystem starts to contribute their energy to a flywheel so it gains increasing speed. We should organize how autonomous cells form a living breathing organism that grows up in good health and happiness.
âadversaryâ is hypercapitalism speak, the system of winning vices. âcompanionâ is fedi speak, the path to alternatives.
Hence my plea that there should be parallel tracks to spritelyâs core tech research. Including by different groups other than spritely thatâll be part of the ecosystem later. Maybe in 2 years spritely team says âTada, here it isâ and UX experts say, âThank you, we will study how to best incorporate thisâ while everybody else builds incompatible worst-practices and mastodon-like derivations. Oops. We know where that gets us, dear fedizens.
In the related Bluesky discussion @cwebber talks about tough times at SocialCG where despite best intent, best effort given, things devolved into infighting and ultimately splits in the road and divergence in different technological directions again, with different approaches and processes.
Regarding both protocols converging and interoperability being an incentive towards it, âI Want To Believeâ ⢠but my experience in standards, especially the hell I/we went through with the W3C Social Web Working Group makes me pessimistic.
From years of community and technology evangelism experience, my take is âIt Wonât Happenâ â˘. At least not the way we want. Not with a commons in control of evolution and safeguarding humane technology direction. This may become a corporate affair, cleaning shop, if they gain enough business interest to be so involved. Maybe the commons might agree, gain consensus, and manage to introduce more rigour and robustness to the specs that make bridge-building of all kinds easier.
Next questionâŚ
Suppose there was (and likely there is) this full-blown technology adoption strategy sketching a clear picture of all the technology fields and areas impacted directly and indirectly impacted by the introduction of Spritely and OCapN technology deliverables. Can you survey all moving parts in this overview assign your own hunch between " wont-happen", " want-to-believe", " likely-to-happen", and " will-succeed" or something like that?
For example:
Goblins popular for broad uses. System integration via wasm polyglot development.
Spritely OCaps adopted reasonably well in FOSS circles, 100âs of ecosystem projects.
Spritely technologies gets traction with a furtile base of businesses in various areas.
Specific OCapN artifacts find âarea adoptionâ, become de-facto industry standard there .
OCapN takes flight, and lives up to its full expectationsâŚ
Important to note that the statement âwonât happenâ judges against current approach and direction as it is perceived by the insider or looker-on. So it really means âunless things changeâ, so focus on that if it includes your ambition level.
I believe that every free software project, also ones creating specs and open standards, always go through the stages of a certain Free Software Development Lifecycle (FSDL). This goes from first inception to ultimate dispersion of the value that was created (we need not call it âend-of-lifeâ in our case, as the work lives on in the commons). It encompasses all people affected directly and indirectly (i.e. takes externalities into account) and the different skillsets and perspectives they bring to the table. And also this includes the ecosystem(s) where the technology is delivered.
Where is spritely in all the various parallel tracks and workflows of the FSDL? You have addressed way more already than most average FOSS projects do. So that is fabulous. A non-profit entity, fundraising track, research track, development track. Which aspects arenât yet addressed that really should be? How might community or 3rd-parties help there.
Where I want to explore, and hope to get more people with me, is depicted below âŚ
).
to read the monster thread at ease, I found a partial answer to how Spritely intends to move forward. 
wont-happen", " 
want-to-believe", " 
likely-to-happen", and " 
will-succeed" or something like that?