User interface patterns for "neighbourhoods" modules

Thanks so much @Lynn Foster. I know you have brought this perspective to many of our discussions before. In the past I've been reluctant to build these prototypes, but I now think the time is right.

To some extent, this work has begun with our reputation libraries. At this point we've been hampered by limited access to HoloRSM, and by my basic dev skills. I would like to keep going though, and I guess that will be a function of Pospi's bandwidth and raising some initial capital get things going.

Wrt the Marketplace app - let's figure out which reputational building blocks can fit in as the first step. As we keep going, we might want reputation to also influence the price-matching logic - for eg, price of offering could vary based on which community it's being offered to, or who sees the offers first.

>Next session could be a discussion on how we generate content to describe Neighbourhoods

@Sid Sthalekar I propose some homework, a thought experiment. You've been conceptually deepening your thinking about neighborhoods and how to express that over the recent months. Let's take whatever known example(s) you prefer, and think about what modular apps they might want. You did some of that earlier. Then let's do a few mockups of what a UI/UX might look like for a neighborhood who wants to gather its software infrastructure to reflect its reputation culture, its governance, what economic activities it does. Doesn't have to be good looking, but the information groupings and navigation would be interesting I think. It would certainly help me understand more of your thinking.

A possibly related proposal for homework: Since we're actively working on the marketplace app in the context of Holo-food and modularity hackalongs, what optional reputation modules would be interesting to add to that? How would they work? What is a good level of granularity for the modules? Can they be built along side the marketplace itself? (I'm thinking of this app as a showcase of sorts, as well as an experiment in modular architecture for holochain. Although I have questions about how the marketplace might be used in the context of neighborhood thinking, need to explore with Kamal and others.)

Thanks for sharing @Lynn Foster. From my understanding, Profiles/Personas will allow a person to link each user id that is generated to a certain Persona. A person may choose to maintain separate and distinct Personas, but they do so at the cost of not carrying over the context from one Persona to another. I think this encourages well-meaning people to develop their Persona's more consciously, and develop more meaningful engagements instead of dropping user id's just because they prefer anonymity.
Did that clarify? I can share more if needed.

>In the past I've been reluctant to build these prototypes, but I now think the time is right.

Just to clarify, I think mostly it is important to think about it concretely as the next step. Doing the actual code is not necessarily critical to that, could be something that defines how the actual code will work functionally. Or maybe you've done that in your libraries? (I took a brief look, but won't be able to understand it well enough from reading the code.) I like UI mockups because they reflect how a user will understand it. What will a neighborhood look and feel like? What would my view of neighborhoods I'm involved in look and feel like? But whatever works for you, of course. :)

>Wrt the Marketplace app - let's figure out which reputational building blocks can fit in as the first step.

Sounds good. Maybe some code will fit in there after that first step, although I totally understand the constraints on coding atm. Btw, are you enjoying coding at all?

Some great topics in here. Going to try to reply to some of them as separate posts to split the discussion threads out- please feel free to move to their own topics if you think they need it.

Doing the actual code is not necessarily critical to that, could be something that defines how the actual code will work functionally.

This is good feedback.

Or maybe you've done that in your libraries? (I took a brief look, but won't be able to understand it well enough from reading the code.)

Yes, thats the result of basic coding of simplistic modules, and conversations about architecture. It's been held back because of uncertainties around bridging in Holo Redux and RSM. But I'm now at the point where we know all that we can know, and I think we just move forward in a direction. @pospi, perhaps you can help?

I would say the HC eco-system has taken a pause of sorts for exactly this reason - to wrap their heads around RSM.

I like UI mockups because they reflect how a user will understand it. What will a neighborhood look and feel like? What would my view of neighborhoods I'm involved in look and feel like?

I think this might need Pospi's inputs again. How this fits into larger priorities

Btw, are you enjoying coding at all?

You know, I am. It's been very liberating. But I'm also very aware of what my boundaries are, and that I can only ping people with my constant queries and questions so much :)

Cross-network coordination problems

eg, price of offering could vary based on which community it’s being offered to, or who sees the offers first

Because separate intents on multiple DNAs will be a nightmare for co-ordinating trades that match.

These are very interesting use-cases to consider. We can replicate automatically at the DNA level via Holochain-layer configurations, or we can replicate with user intervention at the UI layer by selectively choosing networks (which FWIW under the hood looks like separate GraphQL mutations). This feels like it’s probably something for the latter case as it’s a complex configuration of unrelated Intents which you’d group with a Proposal:

• Seller creates offer intent in their immediate, most trusted network.

• Seller navigates to market A:

  • replicates offer intent into this network as offer intent A

  • creates Proposal referencing offer intent A as a gift

• Seller navigates to market B:

  • replicates offer intent into this network as offer intent B

  • creates request intent B for payment of offer intent B

  • creates Proposal referencing offer intent B as primary intent, request intent B as reciprocal

The question is how to manage these associations. We have EconomicEvent.triggeredBy, but nothing else to make the association between related Intents (or even Proposals) like this. So, on a “cross-marketplace” UI app, you might even want some locally stored user-level mapping of all these datums so you can track their relation to each other.

Because in the end, it will come down to you as the listee to manage such an arrangement. If it is automatable at the Holochain level, then it’s only so due to you being online or having a Holoport with your agent key running & able to service the request. Because you’re the only agent guaranteed to be connected to the networks in question. But probably for most cases it’s actually safer for manual intervention, in case you decide to accept multiple proposals from multiple marketplaces to collectively complete the same offer.

@pospi, perhaps you can help?

Yeah! I think it's a "let's converge in what we're doing" sort of conversation at the moment. I guess the gap I'm seeing is design- and I'm wondering whether some of the few designers we do have in the ecosystem might be interested in joining in. Especially in the context of what Kamal has been doing with Hylo-based UI mockups. I'd like to see us organise our design work better across projects, and try to index things and make them available across the community. Will ping CommonsPub about that too.

I think first priority for me is still the marketplace, but the UI work I am doing there is going to involve this stuff in the near future anyway. I can see some implementation details becoming clearer in the above:

the information groupings and navigation would be interesting I think

Well said. The first that comes to mind is "people" and perhaps (back of the napkin) "contexts for people"? Then you assume that everywhere in the UI where details of a person can be displayed, there is a `slot` in that UI component that can take any child components which accept the details of the person as `props`. From this you could then have user-configurable sets of components for each "person context" that determine which child modules should be displayed. From this you get the notion of "everyone gets to decide which details they want to see about everyone else".

But agree with Lynn that this is a design conversation prior to an implementation conversation, and hope we can proceed in this direction with mocks & conversations prior to hitting implementation stage / me proofing Svelte UIs and getting other collaborators into the marketplace UI development.

Because in the end, it will come down to you as the listee to manage such an arrangement.

That makes sense.

I think this is where memetic bridges kick in. If a matching bid is received in market B, and the Seller is offline, the bidder can check for memetic bridges available at that time, ping the Sellers most trusted network, which then pings market A. If memetic bridges to all markets are online, the offer intent can be edited, and the trade confirmed.

I think this should work?

This has come up a couple times in conversations with Art. His solution for nodes going offline has been 'index nodes' that are dedicated for this purpose. I think that doesn't work for modular/NH-style designs. I'm getting more convinced we need to develop memetic bridges to solve the modularity problem.

Yeah, should do! You're talking about essentially routing toward the best possible trade via all active contexts you have with a potential trading partner? I think that's mostly just going to be about searching & ordering results.

Hmm - slightly more specific than that. If you have an offer to sell open across neighbourhoods, the relaying of information when a matching bid arrives should happen through memetic bridges. One of the pieced of logic we build could be: 'If even one of the neighbourhoods cannot be informed, the trade doesn't go through, because it could result in a double spending problem.'

Must we replicate an intent to get it to different markets? Can the same intent (same hash) be stored in different markets? (different dna's) I'm also thinking ahead to transfers, where each agent involved would ideally have the same identified record.

It could be, but I don't think it will be. Because of the ontological translation needed for converting classifications and specifications between networks, there's no guarantee that the data will match and have the same hash. Unless we do something clever RE splitting it up into more bits.

I see where you are coming from, and I guess there is a whole discussion there about where classifications and specifications live, and if agents can and will use the same ones. Maybe located in a public or shared dna? Or even in the other agent's dna? Like if you offer something specified as X, and I order it, I want to be committing to that exact product specification. Or, on the identifier side, maybe we need some other reference numbers like happens today and gets shipped around to everyone who needs it, order # 123, product # xyz, whatever. Some unique identifier, at least per agent, that can travel with the duplicated records so we don't get so much of that "nightmare".

The UI/UX for a neighbourhood

Indeed, it’s a fun thought experiment to think about what this ends up looking like. For me it’s essentially a thought experiment as to the kinds of features I’d like in my apps; as a “power user” with access to & knowledge of all the backend data sources that might intersect with our collective.

First I want to answer a few of the questions above quickly and simply (bluntly?), because the design philosophy I have in my head for NH leads to particular conclusions. A lot of them I think are informed by the Unix design philosophy—

when I’m hovering within Economikit do I see offers stream in within the EK-verse?

Yes, if it’s relevant then it should become part of the collective’s standard app suite & embedded into whatever dashboards & other apps are appropriate.

Or do users view a consolidated marketplace of offerings and transactions across all the communities they are part of. Or is it both?

Both. The contextual marketplace of the community as visible within the community; and the non-contextual (or individually contextual?) “virtual marketplace” of all of our personal marketplace-like interactions across all spaces which have marketplaces in them.

We are essentially switching between group & individual experiences when toggling between the two. In the former space we are acting fully in service to the group; in the latter we are balancing our personal energies among the many groups we have relationship to.

Should the consolidated view across communities be part of the reputation vault?

I don’t think so. It should be a whitelabel marketplace app that’s connected to every compatible REA network the user has installed.

Perhaps another way of saying the above RE group/individual contexts: You end up with apps for specific community contexts which encompass many operational details; apps for specific operational contexts that encompass many communities.

I also want to point to the Unix philosophy here in particular. Just because the reputation vault connects to many source datasets doesn’t mean that it should try to reproduce functionality from those network spaces. What is the reputation vault’s interface for, specifically? What is the thing that you would jump out of another workflow for and enter the vault to manage?

My first thoughts are that it would be a mostly ‘administrative’ interface akin to the stuff Holo-REA needs for knowledge management. Somewhere to connect reputation data sources from other DNAs and to import, author & share reputation scores with others?

I think that most of the functionality of the reputation vault is probably about UI components that it provides to other applications, so that they can embed reputation data that it provides and show it in relevant contexts when you’re doing tasks across the Neighbourhood.

I’ll post a few followup threads and separate out the necessary technical requirements, which might help to make some of what I’m saying here clearer.

I’m going to continue thinking in terms of the “datatype / display context” model for now; mostly because my brain wants to ensure that it’s programmable. (Let’s revisit that core underpinning if it’s not making sense to everyone else though.) So—

“Datatype” is the underlying “thing”, stored in one or more Holochain DNAs, that we might want to display in the UI. Examples could be people, economic events, files or comments.

“Display context” is an abstract concept to describe where and how the data is presented in the UI. Examples could be: list view item, full page detail, summary view, icon row. Deciding on display contexts is difficult. Over-abstraction leads to a loss of comprehension and “blocky” or “bitty” UIs which feel cumbersome. So, in early phases at least, perhaps it’s best to design the management of display contexts in an app-specific, non-generic manner. This would mean contexts that sound more like “marketplace listing avatar” than “list view item”; but the hope would be that through iteration and development of more apps, similarities can be found and common abstractions can be built.

“Person” datatype

People are going to be one of the core “anchor” data elements in every network, and the central items in most reputation economies. The display of a great deal of extended information is likely to be desired by agents seeking to add context to their online interactions.

Just low-hanging fruit that feels like it could be useful…

• Network commonality

• The number of networks which you share with other agents, perhaps indicated as a function of colour saturation

• Presence in specific networks may want to be emphasised, perhaps with badges or icons

• Web of trust

• People are going to want to pre-load their real-world trust into their networks; we could provide a DNA to manage GPG-like trust levels against other agent keys. You could then surface these trust levels into the UI in any application.

• Availability

• This seems to get pulled from the Holochain Personas DNA or something similar in a few demos I’ve seen from the HOLO team; could be useful to make visible.

Actually I won’t go too far into these, I think some might end up being things that emerge more as the applications being built in our networks do. Seed sharing statistics from Seedshare are a good example of this- not something you’d normally consider a part of many other apps, but can become a significant indicator in you’re a FairBnB host with a particular ideological leaning.

Organisation datatype

Placing this here to note that with the architecture I’m currently using in Holo-REA, Holochain DNAs are equivalent to organisations / group agents. Related data includes the agents who are a part of the organisation in addition to whatever kinds of organisational metadata we decide to standardise across apps.

Again, I suspect the kinds of metadata needed will differ by use-case.

Economic event datatype

Another big one for us is recordings of economic coordination events. In these cases, there are various other DNAs you’d want to have plugged in by default for the display of extended information: location of the event, comments & discussion threads, file attachments are a few that come to mind.

In list view can see some of these doing interesting things- eg. the location could simply be a “5km away” kind of widget in a list view; map showing other nearby events in detail view.

There are also some “extension” modules planned for Holo-REA which we would want to surface around events- for example the visibility of pending events which have been marked as disputed (along with the details of the dispute).

Good thread this. The way I see it, the Neighbourhoods implementation of Marketplace means each community can spin up it's own micro-marketplace for circulation of goods within the collective.
- Implications for UI: Does a user view the marketplace as a section within a community. For eg, when I'm hovering within Economikit do I see offers stream in within the EK-verse? Or do users view a consolidated marketplace of offerings and transactions across all the communities they are part of. Or is it both? Should the consolidated view across communities be part of the reputation vault?
- Pushing intents to different membranes: If an intent to offer goods/services is pushed across multiple Neighbourhoods, how do we co-ordinate this? From a central user-chain that then pushes out intents, and also confirms trades? Because separate intents on multiple DNAs will be a nightmare for co-ordinating trades that match.
- Reputation based Price matching: When a user makes an offer within a Neighbourhood, it is made with a conditional element of reputation associated with it. So basically, another user can only pick up offers if they have the necessary reputation to back it up. For eg, you might want to offer organic produce from your home garden only to people who volunteer at community gardens.

I could break this down further if we want to get into this. Personally, I think this social-fabric-interwoven-commerce is what NH is all about :)

Anyway, maybe this is enough examples for now to start to get us thinking about the relationships between different datasets and how those become useful to us as interpreters of the information.

And I also don’t want to think too much about which kinds of reputation modules are useful to folks; my head is full of making REA work and I think it’s mostly up to Sid to dream about what he sees as useful there, and what/where derived information from things like “likes” and “upvotes” might be useful & interesting to see.

“To see”, hmm.. well, adding context visually is just one part of it. There might also be data dependency things at play here which we could experiment with (eg. ordering & filtering of marketplace results, price matching etc). Worth thinking about the specifics of both.

Just because the reputation vault connects to many source datasets doesn’t mean that it should try to reproduce functionality from those network spaces.

I've been mulling over this, and I agree. In fact, we could consider another container altogether called 'Bazaars' for decentralised marketplace co-ordination. (Only if required)

I think that most of the functionality of the reputation vault is probably about UI components that it provides to other applications, so that they can embed reputation data that it provides and show it in relevant contexts when you’re doing tasks across the Neighbourhood.

Interesting. Hadn't thought about it like this.

So, in early phases at least, perhaps it’s best to design the management of display contexts in an app-specific, non-generic manner. This would mean contexts that sound more like “marketplace listing avatar” than “list view item”; but the hope would be that through iteration and development of more apps, similarities can be found and common abstractions can be built.

I get the app-specific, non-generic manner thing. But explain the marketplace-listing-avatar thing more? I feel like understanding the example you used is critical.

Actually I won’t go too far into these, I think some might end up being things that emerge more as the applications being built in our networks do. 

Agree.

The marketplace-listing-avatar thing is just to say, we'll probably have fairly context-specific UIs to begin with. Listings on a marketplace app might look quite different to listings in an inventory management app; so at this stage it's better to consider those two separate display contexts even though at some point down the line we'd hope to be unifying the two and arriving at something that makes sense for all people when displayed in all kinds of lists in all contexts.

RE the reputation vault and where these things bubble up in the UI, I think it might make sense to start thinking of Holochain app bundles as not just DNAs + app UI; but as DNA + app UI + UI components. So most of the components that the reputation vault offers to other apps are going to be aggregate in nature (badges, ratings etc). In other words, it won't offer the "like this post" widget or "liked by 5 of your friends" widget itself; because those components would be bundled with the "likes" app rather than the "reputation vault" app.

The marketplace-listing-avatar thing is just to say, we'll probably have fairly context-specific UIs to begin with.

Thanks, this is helpful. I think from a marketing/strategy perspective there's stuff to think about here though. Ideally, we want to implement projects that rely on new ways of collaborating and information exchange to showcase the power of neighbourhoods. Or else, we run into the same problem of users being drawn to it and using it like an app in the same old way.
So it could be a social-networking/conversational tool, or a bazaar-style tool that can be offered to different neighbourhoods. Will share more tomorrow.

Neighbourhoods and network agency

How do neighborhoods map to economic agents?

are some neighborhoods looser than that, have some identity as a group but no economic agency as a group?

Could there be neighbourhoods which are not engaged in commerce?

I think it’s a mix, as we’ve discovered with CommonsPub. Some networks could be said to operate in a “Neighbourhood-like way”, maybe if they meet some of the requirements I’ve bolded above. But I don’t think that implies anything about agency of the group, at least at this stage. You can have a group of folks collaborating tightly without any formal governance or organising principles, sure.

What you didn’t ask was-

How do neighbourhoods map to networks?

to which I think the answer is, “loosely”. So “farmers in Wisconsin who grow organically” could be a Neighbourhood in of itself, but it could also be simply part of some neighbourhood of folks who fit into this and other usergroups. And the notion of its “neighbourhood-ness” could be an emergent property of the higher-order compositional structures of the networks around the organic farmer network! As in… maybe each network itself has no membrane control built in; but simply as an artifact of the visibility of information in different networks, different tiers of users might emerge.

are all non-person economic agents neighborhoods, by definition?

I want to say “no” here. I think being a Neighbourhood implies some technical constraints regarding the customisability of user interface and backend data sources (which at this stage are quite complex, I’ll admit. Hopefully we can automate away a lot of that.)

It’s interesting to end up at this conclusion… I think perhaps I’ve had a looser idea of this in the past. For those who disagree, I’m wondering what you see as the specifics of “Neighbourhood centric tech”?

I guess this is Sid’s view—

the minimum qualification (for the way I’m defining Neighbourhoods) is for reputation/monetary/governance layers to be articulated in agent-centric environments.

Whereas (perhaps in addition to this) I see some requirements around access to information and customisability of UI which lead to my idea of “true agent-centrism” as an individual with their own subjective view of a neighbourhood.

I also want to point out that I broadly agree with the need to articulate a reputational culture in a neighbourhood, I just didn’t want to rewrite a lot of this. I wonder whether there might be something to tease out RE “actual neighbourhoods” (with articulated culture) vs “virtual neighbourhoods” that individual users might assume the viewpoint of across networks. The latter has no culture articulated other than to the single person observing their view of the available datasets.

Maybe it’s sort of a paradox, where in order for Neighbourhoods to exist we must also build non-Neighbourhood liminal spaces that allow individuals to “hover” at the margins, and see across Neighbourhoods with different value sets.

>I think this social-fabric-interwoven-commerce is what NH is all about :)

Let's do a little ontology mapping, just for fun. How do neighborhoods map to economic agents? Do all neighborhoods have economic agency themselves (different from the individuals who make up the neighborhood)? Or are some neighborhoods looser than that, have some identity as a group but no economic agency as a group? Do some or all neighborhoods have some form of governance, formal or informal? And/or can a neighborhood be defined through some circumstance or activity but not be actually identified or organized in any way, like "farmers in Wisconsin who grow organically"? Inversely, are all non-person economic agents neighborhoods, by definition? (This would include Monsanto or Goldman Sachs too!) If not, which kinds of economic agents would be neighborhoods?

I'm also curious about the "commerce" part. Could there be neighborhoods that are not engaged in commerce? For example, purely social groups? For another example, can a project that is engaged in producing something but not engaged in any form of commerce or exchange be a neighborhood? Like say ValueFlows? ValueFlows is also an interesting example in that it has always had a slowly evolving core group; and also had a lot of people moving in and out, not really members, rather contributors. (Note that there is disagreement if VF itself is an economic agent or not - I think it is and Pavlik, another core member, thinks it is not. So there's that.)

>the Neighbourhoods implementation of Marketplace means each community can spin up it's own micro-marketplace for circulation of goods within the collective

This makes sense to me, especially where there is some internal economic governance involved, like a timebank - but really for any community that wants to. Seems like there is also a range of options from that to completely open, like say etsy. Seems like Kamal was thinking of a marketplace for Seattle, geographically based and maybe a focus on circular economy? (Is Seattle a neighborhood?) But I'd like to dig into that a bit with him. Actually the question of what are the different scopes of marketplaces we want to address in this app is a big question I've had.

>Implications for UI: Does a user view the marketplace as a section within a community. For eg, when I'm hovering within Economikit do I see offers stream in within the EK-verse? Or do users view a consolidated marketplace of offerings and transactions across all the communities they are part of. Or is it both?

In the Mutual Aid Network for example, I'm pretty sure there is a requirement for both, but they have expressed the latter since they already have the first in their separate software that doesn't talk to each other.

>Because separate intents on multiple DNAs will be a nightmare for co-ordinating trades that match.

Could be challenging, although I'm not sure if you are thinking more of holochain's distribution mechanisms or the model. I think the VF model should help, because if you have a Proposal (an offer or request), you can post the same Proposal to multiple groups (Agents in this case) and I assume the identifier will stay the same in the different dht's (?). If you have say the same thing you are offering (same Intent), but you want to price it differently in different groups, that is different Proposals. (I don't know if that was clear at all.)

I wonder whether there might be something to tease out RE “actual neighbourhoods” (with articulated culture) vs “virtual neighbourhoods” that individual users might assume the viewpoint of across networks

Read this a couple of times, but I don't think I get it. Elaborate? Or maybe we discuss in the NH sync

Whereas (perhaps in addition to this) I see some requirements around access to information and customisability of UI which lead to my idea of “true agent-centrism” as an individual with their own subjective view of a neighbourhood.

Makes sense.

RE actual / virtual; think of our recent work with BASYN. You could consider them an "actual" neighbourhood (putting aside for the moment the specifics of their governance) since they are a real usergroup with a real client base and therefore some form of community (formal or informal) built around it. You could say the same of Shiro or Seedshare.

But the whitelabel marketplace app which I am building isn't for any specific usergroup or community. It is "virtual" because it can be connected to as many VF-compatible marketplaces as the agent has installed. And what that agent sees as context for others within that space is entirely up to the agent as an individual- not part of the formal articulation of any of the groups that they exist within.

Apologies if this is not the right thread, this whole question is broader than UI. The discussion around neighborhoods vs economic agents has sent my thinking on a different direction for how we model "groups" to try to use the loosest name I can. History:

• In VF we have had an insular view in that we care about groups with economic agency. We also know that there are networks that do not have agency themselves, that emerge out of the economic interactions. And a bunch of gray areas.

• When we looked at integrating VF and ActivityStreams (AS) for CommonsPub, we decided to call groups with agents Organizations (because that is in VF) and groups without agency Groups. (AS has Actors with types Person, Group, Organization. VF has Agents with types Person, Organization. There are other vocabularies in the semantic web scene that basically have Agent (defined pretty loosely) with types Person, Group, Organization.)

• As we now look at neighborhoods we understand they are sometimes economic agents and sometimes groups without economic agency.

Problems with all of this: For one thing a non-agent group could decide it wants economic agency, and then it gets a new type? Ouch. And also we have these overlapping definitions that will just get more complex.

I think that the initial model was faulty. We let roles creep into the core definitions of what something is. I think the core definition should be Person and X, where X is a collection of people which has some kind of identity. So not just a set of filters from the outside like "all the organic farmers in Wisconsin", but some sense of understanding of who is in the X and why it exists. (Perhaps people and other X's must agree to be in the X? Definition to be refined.) Then X has roles or behaviors they can decide to engage in, like reputation schemes or economic activity. Those things are not part of their definition as X, and also the software is structured this way. (Like delegation rather than inheritance, in the object oriented world.)

I'm still thinking this all through, and not sure what to do about it atm.

(To note to those reading along: the more Holochain-specific technical conversation regarding these particulars has forked to https://www.loomio.org/d/S1lBFPa7/technical-requirements-for-neighbourhoods-compatible-software.)

Nice questions. So the minimum qualification (for the way I'm defining Neighbourhoods) is for reputation/monetary/governance layers to be articulated in agent-centric environments. Here are some answers to your questions:

> Do all neighborhoods have economic agency themselves
Yes, as defined by their governance.

> And/or can a neighborhood be defined through some circumstance or activity but not be actually identified or organized in any way, like "farmers in Wisconsin who grow organically"?

Yes. For eg, Sid's group that shares entertaining content everyday.

In general, a Neighbourhood is specifically identified by its culture. If Sid's group rewards its members on the basis of who generates the most 'claps' everyday, it forms its own unique Neighbourhood. If Bob thinks this isn't good design, he may 'fork' this Neighbourhood to form a new Neighbourhood with the same members, but with upvotes/downvotes instead of claps. Bob's neighbourhood stands distinctly different from Sid's, even though the content might be somewhat similar.
At this point I should also say geo-location maps on to Neighbourhoods as a reputational data point. For eg, only people within 50 miles of me can join my Neighbourhood. If they hold this data point on their source chain, they gain access.

> Inversely, are all non-person economic agents neighborhoods, by definition? (This would include Monsanto or Goldman Sachs too!)

No, because they leverage reputation systems that aren't agent-centric (i.e. legal system articulated by the nation-state). On that note, some neighbourhoods will also have a footprint in the legal system to function in the real world.

> I'm also curious about the "commerce" part. Could there be neighborhoods that are not engaged in commerce? 

Absolutely. I reckon somewhere in the region of 90% of Neighbourhoods won't have commercial activity for multiple reasons: either they're purely social i.e. groups of people sharing conversations, or ideas, or volunteering; or they haven't gotten to the stage where social fabric can support commercial activity. In fact I'm excited about building with Neighbourhoods without commercial aspirations initially - let's us play and evolve systems together.

> But I'd like to dig into that a bit with him. Actually the question of what are the different scopes of marketplaces we want to address in this app is a big question I've had.

Yeah, I'd be keen to do that too. I think they're still thinking of it as an 'app' instead of a Neighbourhood.

>  If you have say the same thing you are offering (same Intent), but you want to price it differently in different groups, that is different Proposals. (I don't know if that was clear at all.)

That was very clear, thanks. So it seems like we would have multiple proposals generated from a single intent. And once a proposal is accepted, updates the intent, which then propagates to the other proposals that are open?

I think I got all your questions. Happy to keep this going.

@Sid Sthalekar this is very helpful, but I'm still struggling a bit to understand Neighborhood in the context of concepts I'm used to thinking about. I'm pretty sure that Economic Agent and Neighborhood will be overlapping concepts, but neither will be contained within the other, if you are thinking about a Venn diagram.

Here's a try at what I start to understand of what a neighborhood is/has/behaves. Please correct me, this is more like a question than a statement....

A neighborhood must have:

* a reputational culture with rules explicitly defined

* defined membership, a membrane around person agents who have to join explicitly

* some elements of governance, explicitly defined

* all of the above is decided by the members, and voluntarily agreed to by new members, and can be re-negotiated by current members (is this close to what you mean by agent-centric environment? some definition of little-d democracy?)

A neighborhood can have:

* economic activity within it, or with others

* social activity within it

I do want to make sure I understand what you mean by "agent-centric". Holo-REA and holochain have different definitions, but they are fairly clearly understood by now. Here is Art's definition for holochain: https://forum.holochain.org/t/how-will-holochain-handle-group-agents/1095/4

I'm struggling a bit also with technology vs real world. For example in any kind of grouping in the real world, there is probably always a "culture", usually informal and often unspoken, but there. And probably always some level of social activity. But in our holochain world, it matters if something is captured as data or not.

> I'm pretty sure that Economic Agent and Neighborhood will be overlapping concepts, but neither will be contained within the other, if you are thinking about a Venn diagram.

Yes this seems about right.

Wrt the points you listed about Neighbourhoods, they all seem on point. I would just add some membranes may have no qualifying criteria. All that is required is that a user downloads the code and joins in.

> I do want to make sure I understand what you mean by "agent-centric"

For me, agent-centricity is the user's ability to own, and port the data they generate within a Neighbourhood. They would then hold the right to port it to another Neighbourhood, without having to seek prior consent. Also, any other Neighbourhood cannot gain access to a user's data without the user's consent. This is critical, because it shifts the dynamic in reputation design - and allows users to play with it, and port it.

> For example in any kind of grouping in the real world, there is probably always a "culture", usually informal and often unspoken, but there. And probably always some level of social activity. But in our holochain world, it matters if something is captured as data or not.

This is a super interesting topic you've raised. In communities where culture is held informally (tribes/religious or communal groups/volunteer networks etc.) rules are articulated, but the enforcement mechanism are not drawn out formally. As a result they have a tendency to decay over time, or be appropriate by whoever gains influence in the group (devolving into paternalism?). In other groups, like organisations/corporations, the nation state is leveraged to award power to titles like directors/shareholders/management etc. In Holochain environments, we're saying agent-centric ledgers play the role of formalising culture.

>For me, agent-centricity is the user's ability to own, and port the data they generate within a Neighbourhood.

Ok cool. Just focusing on this view of agent-centricity for a moment, how do you see users vs people, and do the holochain profiles/personas concepts play a role in how you think about reputation and neighborhoods?

I can go first. :) For VF, although not in Holo-REA yet, and speaking for myself, I think it is important to distinguish between person and user. A user being a set of credentials, as in a person would afaik need to have a different user on each device when they are using holochain apps. There are lots of reasons that user credentials are not very stable over time, in addition to the issue that a person needs to have many of them at one time. But if a real world person promises to deliver a resource, they are responsible to do that, irrespective of what user id was involved.

In terms of profiles/personas, I don't think that matters for VF, they are at a level even lower than user in holochain if I understand correctly. (I think they can be useful concepts, for people who want to separate aspects of their lives, and have online personas and such, but probably not for economic activity.)