User interface patterns for "neighbourhoods" modules

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.