@dcht00 @mayel

AFAICT: Bonfire is the only ActivityPub (AP) protocol with ValueFlows (VF) included in the protocol spec. I came here because of my understanding of that fact. VF is not yet implemented in the Bonfire instance-- just the protocol documentation.

These are the resources I've followed that got me here:
https://www.holochain.org/projects/
https://hrea.io/
https://mothership.disco.coop/DisCO_and_Valueflows
https://www.valueflo.ws/appendix/usedfor/

What information path did you follow to get here?

I'd be happy to be informed otherwise of a more robust implementation of VF in AP. I don't know of one more potentially entwined than Bonfire. My intent is to stick around and participate in whatever way is useful to help move VF effectively into the Fediverse. Plus, I donate $10/mo to the hREA development effort.

It's fairly easy to see it's early days here.

@dcht00

https://bonfirenetworks.org/ scroll down to the "Powerful Building Blocks" section, maybe select ValueFlows

Or pick the "Blog" link at the top to see what's been done

Back to this information about upcoming Bonfire capability: https://bonfirenetworks.org/docs/boundaries/ In the "circles" diagram, there is a circle of relationship "exchange" where we have a paid relationship. An example IRL exchange could be someone with which I have a handy-person relationship. I want someone who is IRL near me. With this particular iteration of Bonfire, I would have to identify all the handy-people who meet my requirement of "near" IRL and place them in my exchange circle.

Here are the two use cases I know of:

• on NextDoor (ND) app, I have a neighborhood, so I know (sort of) that putting out a "need IRL help" to my neighborhood is supposed to result in "near" IRL people seeing my help request. This assumes ND is properly not over-distributing my posts beyond my declared neighborhood.

• a Unitarian church near me offers a service to connect less-abled members of that particular church to more-abled members for getting needs met. Again, the church "instance" provides the IRL "near enough" element for connecting those with needs to those with offers.

Both of these use cases are examples where ValueFlows (VF) are intended to service (AFAICT). Seems that the Circles function in the Boundaries description are trying to set up, maybe, a future entry of ValueFlows enablement-- maybe? Or maybe, the Circles function is supposed to help set the IRL parts of VF implementation? Here's the example I'm thinking of wrt VF: https://www.valueflo.ws/assets/ValueFlows-Story.pdf In this story, since apples, pies, and truck sharing are physcially exchanged, they need to be IRL near.

Protecting oneself online is an important aspect of the boundaries (and circles) function described. IMO, it needs to go the other way, too.

For thoroughness (and to allow me to find this again later...) here is some additional connection:
The boundaries feature is explored more here: https://bonfirenetworks.org/posts/how_to_boundaries/
My take on the boundaries section of this page is boundaries are how the Fediverse environment affects the user who sets the boundaries. Another take on boundaries would include how I, as a user posting, affects the ecological environment in the sense of computational heat generation in the service of transporting posts beyond my screen and cost of services to do so. This is along the lines of https://www.theguardian.com/environment/series/the-carbon-footprint-of-everything. Me as a user might want to trade my use of email's eco-environmental cost vs using the Fediverse. I want to limit the potential reach, so I know I'm trading to my eco-environmental goals.

It looks like I can use Circles as a way to limit the eco-environmental cost of communicating (nts: see the How-to boundaries link above)

https://nlnet.nl/project/Bonfire/ Some thoughts after reading this:

• it spends more time dissing extractive social systems than describing a use case I might build by assembling pieces of Bonfire code. So, still not getting what a use case for Bonfire vs any other dialect of ActivityPub (AP) -- from a user perspective-- might be.
• good point about extractive networks being a "regression toward the payout" wrt content density
• "Switching from closed social networks to the fediverse contributes to privacy and trust, by enabling users to understand and control who sees their data." This seems like an important point. Seems to relate to the Bonfire idea of boundaries as described here: https://bonfirenetworks.org/docs/boundaries/
• one thing I wonder in regard to limiting the reach of an individual post is whether I might be able to choose the extent of environmental impact. Not that I, personally, ever write something that would get a super-bloom of boosts, but should I want to know my particular post won't do that, could the boundaries function be used to limit that by my choice? A use case might be: limit my post to only my instance or only my followers plus one boost only from my followers and no other could boost that post. Is Bonfire protocol (an AP dialect) intended to be different from other AP dialects in providing this specificity?

Noodling on use cases for a person like me wrt Bonfire. Guess that starts with trying to figure out the bits and how they might fit together. I'll toss some ideas here to try out what's there and how it feels.

There's this, of course, very oriented to dev rather than user: https://bonfirenetworks.org/

Also, there's this: https://nlnet.nl/project/Bonfire/ which feels a bit more oriented to informing users of Bonfire. Still thinking about that.

btw... couldn't find the nlnet.nl link through g**gle search but could on Duckduckgo. Interesting.

@mayel @ivan @edumerco

Another thing about the metric... trust and robustness to editing and deleting. If the post is moved by the actor(owner), trust in the "punch" allocated on the initial thread and robustness to subsequent editing (before or after move) would need to be incorporated in the "punch" metric.

Just arbitrary, calling it "punch". There is probably an official name in some standard (that I haven't found). I think it is equivalent to the flame icon mentioned elsewhere. To first order, ActivityPub (AP) spec seems to put it in the "microsyntax" vocabulary with "may" connection with other AP implementations (?languages?... Mastodon, et al.). It doesn't seem to be an ActivityType such as Like (in the AP spec). I looked in the Bonfire documentation, but I don't know how to find how the "flame" maps to AP.

@ivan @mayel @edumerco

https://www.connectedaction.net/tag/threaded-conversation/

Perhaps there is an idea for an algorithm in this report.

Here's another example of quantifying elements of a thread with real world example: https://sites.dartmouth.edu/learninganalytics/2016/01/26/the-application-of-social-network-analysis-in-canvas-discussion/

From a data portability perspective, when an actor moves themselves (and their past posts) to a new instance, each post in a thread can contain a vector of the original posting "punch" based on metrics. When the actor's past posts are discovered by the actors of the new instance it may spawn a new thread graph. This implies these "punch" metrics are supported in the new instance. Maybe as a microsyntax?

@ivan

With this entry, <1 day of engagement here. Enticed by some posts by https://xn--ocane-csa.fr/ on #Mastodon and their website. I've only just started to read https://bonfirenetworks.org/docs/ and https://www.w3.org/TR/social-web-protocols/

See document: https://www.platformaccountability.com/proposal, then scroll to the bottom. It shows some suggested measurements and some objectives for those measurements. Some for within a post/thread and some situated elsewhere TBD. The white paper contains more detail.

So sorry to be commenting without completely reading the specs first. Understood this particular comment period was for 2 weeks, and unsure I could finish and grok the specs in time to have a worthy basis for comment. I couldn't find a reference to the platform accountability document anywhere in the #Fediverse yet (but that be my weakness in search skills here). Wanted to be sure this work was known. Seemed like there were at least overlapping goals in the bonfire measurement goals noted here and the platform accountability goals.