The 'My' Protocol Stack
The emerging human-centric Internet - My Identifiers, My Data, My AI, My Terms
This post is a bit of a ‘brain dump’, and an anchor that I’ll point back to with deeper dives on the four component areas. The purpose is to set out the various components of the ‘My’ Protocols stack. But that I mean a series of technical and data capabilities that empower people in the digital realm. Empowerment Tech is probably the best wrapper term. The category name will change when one or more of the deployments catches fire and creates a consumer facing terminology.
In this iteration of ‘the stack’ I’m pointing to the art of the now possible in functional terms, and what I then believe to be state of art in each area. I fully expect and hope each will evolve and push forward that art of the possible. One of many great things about ‘empowerment tech’ is that within that space there is a real race to the top. That is to say if a functionally better component emerges then people should adopt it; and in doing so people become more empowered rather than less. That comes about becomes of the inherent human-centric nature of empowerment tech; there is no ‘lock-in’ mind-set or reality in that space. So when there is no functional or data lock-in, the way to succeed is to build the best product/ service. And that means product/ service in the ‘4 P’s widest sense - product, price, place and promotion.
The components of the ‘My’ stack, by definition, work from the perspective of individuals, hence the ‘My’ moniker being appropriate.
Let’s dive in. The ‘My Protocols’ stack’ consists:
MyKey. A digital identifier that a person creates, own and control themselves.
What do we mean by digital identifier? We mean data string in a particular format, most typically a decentralised identifier complying with the W3C DID specification, that has inherent digital capabilities. Within that context, there are a range of ‘DID Methods’ that have slightly differing capabilities/ areas of focus. The MyKey service, based on the FedID protocol, is breaking new ground at present. This is NOT about digital identity of a person, although that is very much in scope in terms of capabilities that can be improved upon when people create, own and control strong digital identifiers. When that is the case people can:
Sign up for web sites, applications and agents without having to rely on identifers provided by the service provider.
Sign-in to web sites, applications and agents without having to rely on identifers provided by the service provider.
Sign contracts and agreements at web sites, applications and agents without having to rely on identifers/ ‘customer numbers’ provided by the services themselves.
Prove that data attributes delivered via the owned identifier have the provenance and technical capability to be verified as correct.
Build an audit log of data actions and transactions where they are associated with an owned identifier.
The MyKey utility app is shown below, available shortly in the App Stores.
MyData. Data sourced, managed and used by me under my control either directly or via a service provider working for me on a fiduciary basis.
What do we mean by ‘MyData’? That could become very broad subject, but I tend to regard the data that an individual may wish to control as consisting four broad categories of data as below; each of which then sub-divides.
- About Me (my context)
- Things I Have (‘my stuff’)
- Things I Want (Intent)
- Jobs to be Done (workflow, automation and agents)
The visual below is a very much simplified view on to the data model logic that already underpins all customer management systems; and which therefore is also a good start point for running data FOR people. Explaining that will undoubtedly take at least one post to drill down. But simplistically organisations aspire to have a 360 degree customer view that enables answering these six questions. With the right tooling, the individual is by many orders or magnitude better placed to be the source of this data than any single organisation.
My AI/ Agents. Algorithms, Workflow, Automations, Artificial Intelligence and Fiduciary Agents working on behalf of individuals.
My AI is Personal AI, not Personalised AI. The former works for the individual, on a fiduciary basis is accessed via a service provider. The latter can be provided by any entity or codebase but will be operating on terms that are non-fiduciary.
As I see it, Personal AI will surface like the visual below; namely that individuals will have:
A primary ‘orchestration/ conductor’ agent
As many fiduciary task specific agents as they have tasks/ jobs to be done
In effect, their own Small Language model, when pointed at their ‘My Data’
MyTerms. By this I mean specifically data sharing agreements (aka privacy policies) that are written from the perspective of the individual. These are being specified in IEEE7012, and published by Customer Commons.
MyTerms, the fourth of these capabilities is, in my view, the final piece of the jigsaw required in order to much improve the capabilities of the individual on The Internet.
These agreements will emerge over the next few months. Five of them have the potential to be very high impact as they are designed to tackle specific problems in the current modus operandi. These are problems that can only be fully addressed when working from the individual/ demand side.
I’ll drill down into these four areas over the next week or two.
What if the problem with trust is not "How can the centre (the enterprise) trust connections from the edge (users)"? Maybe the real problem is how humans can trust what they are connecting to? This is what my protocol stack addresses.