🫧 socialcoding.. @smallcircles@social.coop
Public

@julian @evanEvan Prodromou

No need to, I didn't call you out :)

I think the fediverse-we-have has become a very different one than the fediverse-promised based on the initial specs when there weren't implementations and an installed base making numerous design decisions in a very ad-hoc pragmatic fashion. Which is in itself fine, and a very good approach to get an ecosystem off the ground. But having the app-centric, app-first evolution be the primary evolution process, brought us to a different space than the ubiquitous, heterogeneous social networking environment we might all be working in, focused on exciting solution designs and less in all the plumbing and impl details.

No one is really to blame I guess. This is where laissez-faire in grassroots environments leads us, following the social dynamics that exist.

We can do better, but it is very hard in our individualist, FOSS-project-oriented herding of cats chaotic environment. The challenges are social in nature..

discuss.coding.social/t/major-

Major challenges for the Fediverse

Various forum topics highlights big challenges for the Fediverse to overcome. Below there is a list of those, and all of them are within scope of Social Coding #foundations to contribute to solutions. Challenge Description Lack of a shared (technology) vision People just use the Fediverse in its current state without asking what it could be in the future. The potential and opportunities are insufficiently explored. Stuck Fediverse Adoption Lifecycle A combination of factors make onboa...

discuss.coding.social · Discuss Social Coding

🫧 socialcoding.. @smallcircles@social.coop
Public

@julian @evanEvan Prodromou

Btw, some time ago in a matrix discussion I sketched how I'd like to conceptually 'see' the social network. Not Mastodon-compliant per se (though it might be via a Profile or Bridge) but back to "promised land". Where the protocol is expressed in familiar architecture patterns and borrows concepts from message queuing, actor model, event-driven architecture, etc.

Then as a "Solution designer" I am a stakeholder that wants to be completely shielded from all that jazz. That should all be encapsulated by the protocol libraries and SDK's that are offered in language variants across the ecosystem. et al is a black box. I can directly start modeling what should be exchanged on the bus, and I can apply domain driven design here. And if I have a semantic web part of my app I'd use linked data modeling best-practices.

I would have power tools like and methods like .

eventcatalog.dev/features/visu

eventmodeling.org/

Diagram showing the concept of an actor communicating to a remote actor, where there is a schema-based closed-world communication bus, and an open-world semantic web interface.
0
0
2

If you have a fediverse account, you can quote this note from your own instance. Search https://social.coop/users/smallcircles/statuses/116099511464629495 on your instance and quote it. (Note that quoting is not supported in Mastodon.)

0
0
0
🫧 socialcoding.. @smallcircles@social.coop
Public

@cwebberChristine Lemmer-Webber @evanEvan Prodromou @kopperkopper :colon_three: @hongminhee洪 民憙 (Hong Minhee) :nonbinary:

See the diagram sketch in my other toot posted today:

social.coop/@smallcircles/1160

Protosocial would further prescribe how an AsyncAPI definition can be obtained from an actor, which defines the service it provides i.e. msg formats and msg exchanges. AsyncAPI might need to be extended to adequately model things.

0
0
0