I notice you chose not to reply, perhaps because you still bristle or parked for later. As developer / enterpreneur you may not agree with my take that there's a larger #social context to take into consideration. One which is now undervalued in favor of pure technical mindset wrt #fediverse evolution.

Everyone is free, within reasonable limits, to do as they wish. Such is the beauty of our grassroots environment. However, important technical stakeholders who follow a pure technical approach ARE a socio-cultural subject matter that deserves to be discussed when it comes to thinking about fediverse's future.

It's unfortunate there's no good space for such discussion other than the fleety and ephemeral fediverse microblog itself. I intended https://coding.social and its forum https://discuss.coding.social to be one such space, but unfortunately lack finances to continue that work atm.

Perhaps you'll read my blog post. I'm curious for your vision on the Future of Social networking.

The paradigm shift that I mention in my article involves thinking differently about what the fediverse is. Representing a unified space, more than something that's chunked into separate apps.

"My FOSS app with my Users", which is a common way developers consider the projects they work on and are passionate about, is a very poor fit to think about what you do on the fediverse. Stronger even, I think that projection does not fit fedi at all.

To many people fediverse is like a promised land. A vacant online space that holds the promise to do "Social, online" better this time. As fedizens and creators we are the pioneers exploring this vast landscape, intent to shape safe communities, build houses and tend gardens. Creating online society, shaping culture, places where we want to spend time with others.

In this analogy devs become like real-estate developers. A project does not stand on its own, but may affect its environment. It is not a free-for-all to just build and build.

Yes, found Unhosted via the @nlnet projects page. Was unclear on the state of the project (everything is undated), but underlying concepts certainly still hold sway.

Indeed I think the layering makes sense, is on the right track. Remember the persona's I discerned earlier? Where the Protocol developer create comprehensive specs for the Protocol implementer, who can subsequently offer #ActivityPub implementations that allow the Solution developer to get to fully focus on their application or business domain, shielded from technical intricacies and wire-level plumbing.

A robust Protocol layer will enable the network effects, but unlocking the virtuous cycle imho requires tackling more social challenges. It is an enabler to go beyond the app-centric fedi, but with post-facto #interoperability the accepted work method, will not solve the anti-patterns mentioned in the article.

The social challenge is facilitating inclusive solution development at ecosystem-wide levels.

I'm not saying it leads to mis-use per se, and certainly not "defaults", just that other people (devs) decide things on their own that may impact postively or negatively many other people (fedizens) who 'built' their home online. This is in the nature of the app-centric fediverse.

I agree that too many things are public, but root cause here is the dominant position of microblogging - a very particular type of application, that people in their offline social life hardly do - as common denominator interoperability channel. This also relates to the app-centricness, and is beyond regular fedizens to do anything about.

My blog post explores social challenges on how we might improve this situation.

Other than that I regret the drama's I've witnessed of angry mobs pouncing on a dev who didn't honor consent. Analysis on why this happens, is also in social space. Analogy to use may be seeing a factory built in front of unregulated public space of one's house, without being informed.

And the more *client* software there is, the more incentive there is for server developers to support the ActivityPub API. Especially if the base profile is very easy to implement.

I think there's a good network effect there.

To provide real-time updates, it could check for SSE support by the server. If it exists, the client could use it to get new activities and show them on the map. If the server doesn't support SSE, the client can re-fetch the actor outbox periodically, and use that to find new activities. Or, just skip real-time updates.

(I did not click through to the blog post, I'm merely reacting to your post itself.)

- A base profile; just enough to get things working
- A bunch of discoverable additional features, like SSE and search
- An "advanced" profile, essentially base profile + selected features

I didn't see a link, so I wanted to check: are you familiar with the #Unhosted project?

unhosted web apps

weekly handbook about unhosted web apps

(unhosted.org)

I think it provides a great model for networked computing -- bring-your-own identity and storage, with an open-ended application domain. It was one of the projects that was an input to ActivityPub.

I think the difference from the #ActivityPubApi is that AP supports activity distribution by default.

I am sorry, the rebuttal eludes me. If you mean announce the blog post at SocialHub and SocialCG in conversation items, I did both.

Everybody is free to write in their own journal, at the cost of reach.