@smallcircles GDPR etc. “right to be forgotten” is really not that; it’s the right to have your digital records purged, at least within jurisdictions where the law applies/can be enforced. Ofc, much law everywhere actually is not enforceable and relies on more or less voluntary compliance with user requests. Should/Shall/Will Delete vs. Must Delete

@dan_kn

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.

@dahukanna

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)

@hipsterelectron

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

I think the general rule should be it's not OK to show something publicly after receiving a delete request. Keeping it privately in its original form is not ethically different from keeping a private screenshot of something seen anywhere online which is later removed.

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

@hipsterelectron @EUCommission @NGIZero @nlnet

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.

@smallcircles Conversations offline are ephemeral unless explicitly documented/recorded. (In theory with the consent of all participants.) Conversations online should, IMO, also be ephemeral.

@teresa_athome

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.

@hipsterelectron @EUCommission @NGIZero @nlnet @SRAZKVT

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.

@smallcircles @hipsterelectron activitypub isn't a good base for development because most of it requires to have the entirety of the content to make an informed decision, and activitypub doesn't guarantee that

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

@navi @hipsterelectron @smallcircles i consider chat to be a non ephemeral thing, but it also requires the entirety of the context, which is why it's bad

same for forums

@navi @hipsterelectron @SRAZKVT

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.

@navi @hipsterelectron @SRAZKVT

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.

@navi @hipsterelectron @SRAZKVT

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.

@navi @hipsterelectron @SRAZKVT

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)

@smallcircles @ireneista beyond the single-user instance. What if not every memory is worth keeping? for example a debate veering into ad hominem, would you even want to keep something said and regretted, or others to do the same?