@smallcircles I think at our last meeting, we suggested the following layered architecture for #ActivityPub API work:

- 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

@smallcircles the goal here would be to get server developers over the line to the basic profile. Client developers can count on the basic profile, and check for advanced features. If those advanced features aren't available, the clients can either implement workarounds or just leave out their own features that depend on those parts of the API.

@smallcircles@social.coop I'm simply bristling at the assertion that opt-out defaults to mis-use of data. The problem is less that other people are mis-using public data, it's that some data shouldn't be public to begin with.

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

@smallcircles so, for example, consider a client app that shows a map of a region, and puts pins on the map for each activity with a `location` property.

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.

@smallcircles over time, we'd hope that more servers would have more of these features available. It would be possible to create clients without fallbacks for missing API features.

@smallcircles I think there's a virtuous cycle here. The more servers that support the ActivityPub API, the more that client developers can experiment with it -- making cool projects like Nuages.

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.

@julian

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.

@evan thank you!

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.

@julian

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.

@julian

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.