Truly Agent-Centric Applications

So far, with our current Holochain alpha prototype, each application is its own thing and brings its own UI.  Look at Clutter for instance:

Standalone UI of Clutter, our distributed Twitter clone. 

The UI of Holochain apps is loosely coupled in that the Holochain run-time after reading the application’s DNA and spawning a node just serves a directory containing a web UI.  The application’s DNA defines certain functions that are made accessible to the UI. 

In our chat, a community member recently posted a chess implementation on Holochain which of course has a completely different UI:

UI of Holochess. 

Now this is fine and dandy and in conjunction with distributed hosting via Holo on an army of HoloPorts, we could basically rebuild every centralized Facebook or Amazon application in a distributed fashion and have the same UX as we do now.  Because of the agent-centric architecture of Holochain that is working under the hood (and thus eliminating the need for either a centralized server or a huge blockchain that forces everybody to store, sync, run and validate everything) these distributed apps could actually scale to Facebook size while running a full client on a mobile device.  That in itself is already a huge step forward. ( Again, if this huge claim renders you doubtful please have a look at our whitepaper and benchmarks and try out Clutter now — and then give us feedback.) 

But what really deeply excites me is to elevate this agent-centric paradigm-shift into high-level user interface semantics.  Because here’s the thing:

The whole point of the Internet is to have agents/humans communicate with agents/humans. 

See, those 2 billion Facebook users are not visiting facebook.com because they want to learn more about the company Facebook — they want to connect to their friends.  Right now, you point your browser to medium.com to read this post of mine.  It does look very different if you get my messages through Slack or WhatsApp, and I have to search many places for that link somebody sent me last week.  Interoperability isn’t always compatible with business models of the big 4.  But the intention for us to use these tools is the same.  The Internet’s implicit central use case is telepathy — exchange of thoughts between humans.  It is the technological embodiment of culture.  And human culture is human-centric, not word- or book- or site- or app-centric. 

Besides censorship, privacy and power concerns, the problem with monolithic, data-centric and centralized applications is that they are silos.  Not only data but also user interface silos.  One does not simply rip out Facebook’s timeline to show updates from friends merged with those coming in through Twitter, Google+, WhatsApp and email in one view.  Even if you would have access to all data via APIs then you would need to write the UI from scratch and resembling the native UI would be hard work.  And what if, after you did that, all your friends switch to Snapchat? 

The way we think about Holochain apps is that they should be microservices, small units, modules with a clear purpose, inputs and outputs.  Similar to text-based Unix/Linux command line apps that are combined in shell scripts or steered from a GUI to cater for a certain use-case. 

With Holochain apps already being decoupled from their UI and using bridging, you could write an app that talks to all other apps running on the same device under the same agency (basically authorizing apps to access the same functions exposed to the UI) and presents you with an aggregated interface.  But if every native app UI is its own standalone front-end (one built with React, the other with Angular, another one with native iOS widgets…), reusing UI components is almost impossible. 

I would like to see the Holochain app ecosystem be smarter and make use of one quite significant fact:

Since Holochain is a space of distributed, agent-centric apps, it intrinsically is a human/social network. 

Network topology of five agents running three different apps.  Every app is it’s own p2p network.  The user’s agent (=device + Holochain installation) is the point where apps meet.  A better fitting metaphor than application might be language.  You could be speaking “Clutter” to two other agents, and simultaneously speaking “HoloChat” to two different agents.  Maybe everybody is understanding “DPKI”.  Either way, knowing which other agents are there and what apps they are running is an implicit basic layer of the Holochain ecosystem.  It is a social network of agents — isomorphic to the underlying human network of users. 

Instead of reiterating the misplaced ontology of documents, websites and monolithic applications, why don’t we invert that dependency and put agents/users/humans at the center of how the Holochain app ecosystem works?  Not only under the hood but consistently throughout all layers, including the user interface? 

To be explicit, I propose to:

build a general-purpose UI for Holochain apps, implying certain protocols that app developer could choose to follow.  I am talking about a browser for the Holochain app ecosystem that is not opening HTML documents but instead is facilitating communication between the user and other users, groups, teams, organizations and the network as a whole.  Think: decentralized WeChat.  Basically a very generalized address book/team chat/social network/collaboration UI with no specialized functionality as that is to be filled-in by those many apps which are meant to work together as micro-services.  It is an agent-centric UI in that it represents other agents and the relationships/teams/threads/social spaces the user is part of.  And it is of course a container of Holochain instances.  It displays entries of all Holochain apps using the new entry type semantics we are about to introduce with the next Holochain DNA iteration to automatically create a more fitting UI widget.  Ultimately, it sports a UI component system that enables app developers and users to customize how entries are rendered.  Qt’s QML is a super elegant UI component language that I see as the perfect fit for this.  The native version of this browser could use native Qt.  For Holo’s pure web based access to Holochain apps we could use this QML web port. 

that is not opening HTML documents but instead is facilitating communication between the user and other users, groups, teams, organizations and the network as a whole.  Think: decentralized WeChat.  Basically a very generalized address book/team chat/social network/collaboration UI with no specialized functionality as that is to be filled-in by those many apps which are meant to work together as micro-services.  It is an agent-centric UI in that it represents other agents and the relationships/teams/threads/social spaces the user is part of.  And it is of course a container of Holochain instances.  It displays entries of all Holochain apps using the new entry type semantics we are about to introduce with the next Holochain DNA iteration to automatically create a more fitting UI widget.  Ultimately, it sports a UI component system that enables app developers and users to customize how entries are rendered.  Qt’s QML is a super elegant UI component language that I see as the perfect fit for this.  The native version of this browser could use native Qt.  For Holo’s pure web based access to Holochain apps we could use this QML web port.  define a human-centric/social API (the protocols/interface functions) this browser uses to query apps for entries.  Besides UI, every Holochain app consists of a set of entry types it defines, their validation functions and semantics, and zome functions that are UI facing (see documentation).  In order to support the browser’s ontology, an app needs to provide, for instance, a way to retrieve all entries that should be displayed when a user’s/agent’s profile is visited or rendered: get_entries_per_agent(visited_agent). 

Or when displaying all entries within a social context (like a private message thread or a team collaboration space): get_entries_in_context(thread) . 

When entries can be read from social contexts they also need to be posted:

post_to_thread(entry, thread)

or

post_to_agent(entry, agent). 

I’m just naming a few examples here to communicate the idea in principle.  Maybe what we need is just all CRUD operations on all levels of the social holarchy — i.e. for agents, message threads, teams, organizations, …

(the protocols/interface functions) this browser uses to query apps for entries.  Besides UI, every Holochain app consists of a set of entry types it defines, their validation functions and semantics, and zome functions that are UI facing (see documentation).  In order to support the browser’s ontology, an app needs to provide, for instance, a way to retrieve all entries that should be displayed when a user’s/agent’s profile is visited or rendered: Or when displaying all entries within a social context (like a private message thread or a team collaboration space): .  When entries can be read from social contexts they also need to be posted: or I’m just naming a few examples here to communicate the idea in principle.  Maybe what we need is just all CRUD operations on all levels of the social holarchy — i.e. for agents, message threads, teams, organizations, … establish an inter-app URL schema to have fully qualified entry references.  Within the context of a Holochain app, an entry’s address is just its SHA-256 hash which is used to do a DHT lookup within the network that is this app to retrieve the content (remember, each Holochain app is its own p2p network).  In order to fully address content from an inter-app context, any link needs to include the app that is the space in which this entry lives.  Luckily, every Holochain app is uniquely identified by its DNA.  The current alpha version is already using the DNA’s SHA-256 as the unique identifier of that app when looking for and connecting to peers running the same app.  Protocol Labs’ IPLD is built for the very use-case of linking entries across applications/networks/blockchains.  Can we have every Holochain be an IPLD protocol specifier? 

/<App DNA Hash>/<Entry Hash>

One central aspect here is these social contexts.  Following the notion of Holochain apps being micro-services, like Unix commands, that can be aggregated within the context of an agent to implement more complex tasks, there should be a Holochain app for these social contexts that is:

storing a list of friends in each agent’s local source chain

introducing social context entries that are publicly shared in the DHT and that link to their members (think teams)

allowing for cascading/fractal social contexts, so we can have teams of teams, i.e. organizations etc. 

Social contexts is what the browser displays as locations.  And there are implicit, transient locations like for instance all friends that are online right now:

UI mock-up of Holochain browser showing virtual location of online Friends.  Each agent is rendered with all entries that are visible for the user, across all apps, applying entry semantics defined in the app. 

This example shows entries from three different apps (Clutter, Holochess and HoloChat, and maybe even another app for the avatar: HoloVault).  The red puzzle-piece shows that this is an entry of an app that is not installed locally.  We are not part of that network so we can’t retrieve its contents, but since the browser knows which app it is (because it was referenced via the intra-app schema) it can offer an install button, which in-turn would use the Holochain of Holochains (HCHC), the distributed “app store” to download and install that app.  This way of discovering new apps through the interaction with other users already using the app is an aspect that seems trivial but my feeling is that it would make a tremendous difference for the adaptability of this ecosystem.  Especially since apps, in this alternative universe, are really a superposition of full-fledged application and plug-in. 

Take my favorite example: a dislike button.  If I want to dislike Philip’s Clutter post up there, I could just write my own new Holochain app that is basically just storing dislikes, with every dislike consisting of just one inter-app link.  I could now dislike any entry of any Holochain app (or even any IPFS object, git commit, etc…).  Now, with either a custom (QML) UI component or (even better) a few more traits in our social API, the browser could show those dislikes on every entry that has one.  If we choose the latter implementation, adding functions to the inter-app API that know about inter-app links, those dislikes could now be shown to everybody as an entry from an uninstalled app, just as the HoloChat example above.  Which means this functionality can spread through the ecosystem easily if users choose to install the app.  And that would work without having to change the code of Clutter itself, and without having to get the whole community to fork into a different “consensus”.  New ideas could easily be tried and if they prove useful they could be adapted by the ecosystem in large.  Just as sub-cultures invent their own jargon which then sometimes becomes mainstream. 

Now, if we zoom out of this online list, we would see several different social contexts that the user is part of:

UI mock-up of Holochain browser showing several social contexts, the fundamental fractal type of its agent-centric, social ontology. 

For each of these, the browser receives lists of entries from all installed apps which are being rendered inside those areas respectively.  Depending on the apps installed and used by the members of a context (and maybe the access rules of that group), a social context is like the power set of a chat room, a mailing list, a YouTube channel, a shared Google Drive directory, a ticket system, a git repository, a video chat or any real-time collaboration tool, and many more. 

The point here is that being able to add any new functionality with just a click but maintaining the social structure in which the need for this new functionality arose makes a lot of sense for the user experience.  This is how we think right now anyway when we cross app boundaries and build the stack we need to collaborate. 

Social context, now as a general term, is the main thing we as social beings rely on to make sense of what is going on.  It is what is always there for us to contextualize information, experiences and decisions — mostly implicitly.  I believe it is crucial to build communication tools that make social contexts explicit. 

And remember, since every Holochain app is its own sub-network, it is totally possible to spawn a cloned app instance (of say HoloChat) for each team, also with just the press of a button.  It would create a fully distributed, encrypted by default, and, as described above, customizable virtual space that emerges just between the machines of the members of this team, no central servers, no miners, no peers that can’t cross the app’s membrane. 

Convinced? 

Let’s co-create! 

What I’m proposing here is actually reaching out of the scope of Holochain core itself.  Though, it is true that these ideas could inform certain implementation details as we go through the next iterations of Holochain.  But in order to create a thriving and synergistic ecosystem, it needs many agents working in coherence. 

And the seeds for this are already planted. 

Our anders.aamodt expressed very similar concepts for interoperability in his Wrex paper some weeks ago, which our Philip Beadle started prototyping on the current Holochain alpha version already, laying out an idea about Social DNA, a inter-app identity management called HoloVault, and details about one very central Holochain core app: DPKI (distributed public key infrastructure). 

What I am describing here is touching and integrating the work of my dear friends and colleagues at Noomap in many ways.  This Holochain browser feels like a light version of H4OME — the brainchild and big vision of Chris Larcombe and myself — but infused with the agent-centric paradigm-shift.  I had many co-creative sessions with Andrea Harding about social architecture and social holarchies that prepared several of these ideas.  Tan, I’m sure Synergy Space would benefit so much from this architecture.  And I’d definitely love to see Chris coming up with a fractal, Noomap-like UI for this Holochain browser! 

I am engaged in ongoing conversations with Harlan T Wood on this matter.  We actually came up with a name for this browser: HoloScope!  My feeling is that Harlan’s Trust Graph is also a very interesting candidate for one of the Holochain core apps.  It could be used by HoloScope to represent these social contexts. 

I know that Adam Apollo is also deeply involved in next-gen, decentralized Internet projects with extraterrestrial UI and surely would have some interesting thoughts on this. :) 

Sebastian Deutsch, my former boss at 9elements, gave me very helpful feedback on Holochain core already that is finding its way into the next iteration.  Your thoughts on this? 

I also want to reach out to Malek Jaber!  Malek, long-time no see but I remember very well how our first half-night long conversation evolved around socially inspired, global software architecture. :)  I think we need to talk again! 

An interesting project that has many similarities to the Holochain approach and especially the social piece I am talking about here is Secure Scuttlebutt.  I would love to get into touch with Dominic Tarr or mix irving and start thinking about an implementation of SSB on Holochain using the node-to-node communication capability as some middle-way between private source chains and public DHTs. 

Since I’m suggesting to build a new kind of browser, maybe Desigan Chinniah or his colleagues at Mozilla are interested in a collaboration? 

My gut feeling is that this thing wants to be co-created among several experienced architects, developers and designers.  With this post I’m inviting discourse and participation across organizational boundaries, not only from those mentioned above but everybody who has feedback to share! 

Next steps: hearing and incorporating your feedback and creating a more formally detailed spec.