What I think is a very powerful perspective to take is to treat the network as an actor-based, mostly event-driven, service-oriented architecture.

I only took some notes thus far (the social coding forum serves as a note-taking tool) ..

Protosocial ActivityPub protocol

Protosocial ActivityPub v1.0.0 Pro-social protocol suite for the social web, based on ActivityPub Protosocial ActivityPub protocol is an extension of W3C ActivityPub that focuses on ease of use for the developm…

Discuss Social Coding (discuss.coding.social)

The most important point in my blog post on Grassroots fediverse evolution is that imo the way we talk about the social web, influenced by the ActivityPub implementations that exist, gradually lead to AP narrowing itself in to very specific areas, and thereby losing most of its promise and power.

Grassroots fediverse evolution

Social dynamics in the grassroots fediverse ecosystem and laisséz-faire practices led to divergence from power and promise of the ActivityPub protocol. Grassroots standards and the ActivityPub API initiative can get us back on track.

Social coding commons (coding.social)

ActivityPub offers decentralized addressable actors that exchange activities with an object payload. All fully extensible.

And then we have the fediverse that is somehow totally dominated by Microblogging, just one tiny sub-domain of "Social networking", and an app domain at that, not a business domain. Same with forums, another app domain.

All the protocol decay that crept in over time, forms a huge restriction, and a barrier to innovation. It does not make ActivityPub attractive for people to adopt as a technology, unless they happen to have an interest in these specific app domains.

The only issue is that it isn't specified how to use this framework, and everyone gives their own interpretation and approach to it now, or copies from others. This is part of the very costly "misconceptions" that aren't addressed.

In the past I have called AP et al a protocol framework, rather than a network protocol specification as we usually understand them. It is a box of building blocks, and it is actual solution design where particular use cases are to be fleshed out in terms of wire formats, message exchange patterns, and business logic.

same for forums

(same reason as to why activitypub is a bad for for instant messaging and for forums)

Just found @aral related poll about Delete on moderated multi-person instances, to which I responded with similar lines of thought..

🫧 socialcoding.. (@smallcircles@social.coop)

@aral@mastodon.ar.al curious if your poll was inspired by mine, where I took a single-person instance as the example of my #ThoughtProvoker toot.. https://social.coop/@smallcircles/116542809803489003 Like in the responses to your poll it triggered a whole bunch of interesting discussion. Unfortunately all happens on a communication medium where all insights are lost tomorrow (except for those who keep records and archives, I guess :) I think really this is an "if all you have is a hammer, everything looks like a nail" kind of thing, which is inherent to how we evolve the app-centric fediverse. We try to hammer all forms of communication into a Microblog design. The app platform becomes a straightjacket way of doing things as intended by its developer owners, plus a bag of features to allow variations to that for instance owners, so they can deal with a certain set of edge cases. I'd choose the option "it depends". It is solution-specific. But there needs to be crystal clear mutual expectations and proper management thereof.

social.coop (social.coop)

Without proper attention to the social side, and with current app-centric post-facto interoperability approach the only thing that can be created is a fediverse that represents a technical switch box, where app devs plug in their platform device and deal with the sparks that sends flying to the extent needed for the app.

A huge innovation potential is missed this way. To reimagine social. Envision a peopleverse.

ForgeFed is a good example. It needs a different approach going forwards from where it is now. Rather than focus on the lowest common denominator between code forge apps, it should bring support for software development to become native to the social web. In other words become open standard ActivityPub extension for a business domain, not an application domain.

Yes, you are correct in saying that. But also in offline contexts we switch contiuously between different communication modes, and when it is time to note things down we bring pen and paper to bear.

Here online on the microbloggoverse, we try to cram all modes of communication onto a fleety microblog sticky-notes-on-a-fridge channel, and add more and more bells and whistles to try to support all the edge cases.

Curious to learn more about @SRAZKVT approach.

For Social experience design I defined a number of so-called SX formula's. These are long-running themes within a commons where value is being created and aggregated that follow a shared vision.

One such formula is "Joyful creation" which in the narrow form (which is actually super broad already) envisions how the FSDL, the Free software development lifecycle or Fediverse solution delivery lifecycle depending on context, can be natively supported on the social network.

The broader version of this formula deals with how *any* cocreation can be supported online, i.e. beyond just the "Software development" domain.

Where it comes to code forges, for instance, app focus is a big hindrance I think, to coming up with innovative social experiences. In a way a code forge explicitly leaves out the social component in the app design, offering categorized lists of tasks, leaves process to be manual.

If something is newsworthy, like a public figure posting slurs or threats, then overriding their delete request and continuing to show it publicly seems justifiable.

@smallcircles@social.coop

Yes, a great thought train. There's so much in here that deserves deeper thought. This is why Social experience design is really important, imho, bringing a new perspective to look at social networking.

In my Grassroots fediverse evolution blog post I make an argument for @EUCommission to fund social web innovation, like the @NGIZero programs via @nlnet, to broaden the eligibility for initiatives that pay attention to the social side, beyond the pure tech R&D. Focus on social supply chains, and bridge the gap to where people's needs are satisfied.

Grassroots fediverse evolution

Social dynamics in the grassroots fediverse ecosystem and laisséz-faire practices led to divergence from power and promise of the ActivityPub protocol. Grassroots standards and the ActivityPub API initiative can get us back on track.

Social coding commons (coding.social)

The app-centric approach to fediverse evolution makes it really, really hard for good social support online to emerge over time. Because the app is an unnatural silo to slice things, a random bag of features collected by its owners / interest group.

Re:Identity. How identity is dealt with today is another example of protocol decay. I would treat it differently too, and still be AP compliant

Yes. I think you are asking exactly the right question:"What does it mean in this context?"

Many replies to the #poll ponder related questions, or state an "it depends". It is clear there's a lot of nuance and edge cases.

Reformulated, how delete should work is solution-specific, depends on domain, use cases, and stakeholders in SX terms.

And Delete activity in #ActivityStreams is not the well-understood part of #ActivityPub it is treated as today. See also:

🫧 socialcoding.. (@smallcircles@social.coop)

@hipsterelectron@circumstances.run @ireneista@irenes.space @kopper@not-brain.d.on-t.work I consider this to be part of the "misconceptions" that exist on the ActivityPub fediverse, to once more quote the term as Rich Hickey uses in "Hammock driven development". See: https://coding.social/blog/grassroots-evolution/#remove-misconceptions The way I look at ActivityStreams is as a toolbox of social primitives, building blocks for federated solutions. Not as core capabilities of the ActivityPub protocol. Because they are simply not specified as universal and ubiquitous protocol capabilities. If one particular object supports CRUD is solution-specific in my book. Ideally the ActivityStreams primitives all have well-defined singular purpose, but unfortunately that is not the case. More the opposite where everyone is encouraged to hammer their business domain into an ActivityStreams straitjacket.

social.coop (social.coop)

That is the nice thing of the #ThoughtProvoker hashtag. Leaves it to anyone to have and express an opinion, and those discussion hopeful input to social experience design of our collective social web. I agree with your Should/Shall/Will on the other post. Thank you for your replies.

I’d like to have a single person server as a publish once, share syndicate everywhere(POSSE) & would keep the dialogue

cryptographic signatures solve some problems for vcs, but i think the solution there also involves losing some convenience (more awkward diff generation, requiring a signature for merges and not just commits). as with fedi, there may be multiple valid threat models here, so a "git that doesn't generate diffs i didn't sign off on" might allow for skipping signature requirements in certain cases.