User interface patterns for "neighbourhoods" modules

>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 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.

>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?

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.

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 :)

@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.

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.

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.