|
Top-level
 Not only are the implications of the BS shared heap architecture easily overlooked and consequences come later, this has been the de-facto approach for any decentralized web technology thus far, including AP. Where hard-tech mindset and focus dominates. And yes, the complexity warrants all that attention. Yet there's less thought and attention payed to how DX, UX system / application / solution design should cope in the higher levels of the stack, and esp. in FOSS circles. 2/.. 9 comments
But thinking about exploring technical possibilities is way out of lock-step again, speeding ahead of how one would use this shiny technology to build useful things on top of in the best possible way. I have difficulty wrapping my head around picturing a local-first social network at scale where CRDT's p2p synchronise application state and data of all actors - people, apps, services - in the social graph between 1,000's of peers. So many options, what approach is even feasible? 4/.. Meanwhile there are already hundred or more local-first projects and vendors who are independently building "the right way", in other words fragmenting into indvidual explorations with little cross-pollination and co-creation. Why isn't there already an IETF local-first working group, or something similar? Well.. someone should step up to the plate to do that, that's the wait now. Lotta work for volunteers and no funding beyond hard-tech. So this is up to vendors then, I guess. 5/.. Unrelated to this thread it occurred to me how much time and energy we waste by endlessly sifting through untangled mess of complexity with different viewpoints and perspectives leading to Babylonian confusion and overlap all the time in discussions. Bluesky had a big advantage, in that they could forge ahead, highly focused as a close-knit team exploring greenfield technology. They set sail, just tapping the chaotic information stream for collecting stakeholder feedback. 6/.. Now if we look at AS/AP ecosystem, there is a problem as the storm of discussion on vNext of the protocol or choosing alternative directions, goes on unabated, and no one seems to be coming to any kind of real consensus. It almost looks like we once again must leave that to the vendors to sort out, when they enter the 'fedi market' en masse. Ideally we want to have multiple commons-controlled focused and productive working groups that elaborate various themes of the social web. 7/.. Tangential, but to add some more spice to this.. We need more fellowships like this, who explore yet other areas together. Like for object capability social web at scale. A couple of years ago, when you were still on Spritely Project, you sent out a toot out in which you sighed that once spritely technology would be mature enough for widespread use, it would probably be already too late. The institute to the rescue, I guess. Valid and prudent choice. 1/.. It is still hard to hook on to spritely unless you have deep technical expertise. That means most others (large group) are in wait-and-see necessarily. Choice is perfectly valid, because its the foundation team's own initiative. Is it the best tech introduction strategy? Best technology adoption model to use? Your community and ecosystem have to catch up, once you say "it's time for fun". Randy's community pattern language might serve to unlock upper-stack stakeholders now. Because that is highly tangential from spritely core technology, fanning out into vast scope, you might offload that to a fellowship that can facilitate multiple independent initiatives at the same time, not just spritely but also see an ecosystem of convergance and increasing alignment, rather than fragmentation as per the norm. |
Gregory's Server
@cwebber
Making it extra hard to bridge the technology adoption chasm beyond early adopters, while the decentralized ecosystem suffers protocol decay.
Re:new computing paradigms.
> "local-first p2p social networking at scale"
.. someone said.
That buzzwordy sentence might see us enter a new exciting social web of adventure, if we don't squander the opportunity.
Technical all is once again possible. Martin Kleppmann inspires with generic local-sync protocols, universal back-ends, etc.
3/..