[ibgib]

"Reworking" identity from the ground up as OP suggests is actually one of the goals that I've been working on with ibGib. No one really cares, but I'm going to describe some of the more interesting (to me) aspects of it, to bounce it off of you and others here.

First, ibGib's structure is like a block chain. I've been developing it for a long time, and I had no idea what a block chain was, and the like. But an ibGib's structure is like this:

* ib - unstructured text, like a name.

  * often provides data or metadata for convenience per use case, i.e. data is just in the address, without loading entire record.  

* gib - hash of ib, data, & rel8ns, providing internal integrity.

  * ib + gib (ib^gib) is a "content address", but I think of it as like a memory pointer in an infinite memory space.  

  * Currently sha256 but that is metadata and can be specified in the data section.  

* data - internal data, like a "value" or "content" of the record.

* rel8ns - named "merkle" links to other ib^gib.

  * special rel8ns include...  

    * "past" - provides a linked list of mutations  

    * "ancestor" - provides linked list of forks  

    * "dna" - provides event-sourcing-like complete history of how to build the record.

You can see examples of this, e.g., in the info view at https://www.ibgib.com/as-file/ibGib%20Tutorials%5E1E371C4463... . Use the button in the bottom left to change your view, depending on your use case.

So, it's effectively like a tree-version of a block chain, or a distributed (and scalable) block chain. Or if you're familiar with IPFS (which is where I learned the term "merkle"), it's like a merkle forest. (I've been working on ibGib for 15+ years though - had never heard of IPFS either, but I digress). Basically, you can think of the entire thing as self-similar git repos, but for anything - not just code (currently working on VCS use case for it, which is why I've taken the code off of GitHub. You can see my current "issue" for it at https://www.ibgib.com/as-chat/version%20control%20in%20ibGib...).

So this works with identity in a different way, in that each record is internally associated with multiple identity ibGibs. For the above example, check out the "identity" key in the "rel8ns" section. So, each individual datum is associated with _multiple_ identities for multiple things: users, nodes, sessions, etc. The piece I'm working on right now (in the active process of whiteboarding/coding at this very second) is the public key infrastructure "replacement". Because the data has this entire integrity chain, you can do different things for verifying provenance.

The way that you "prove" who you are is similar to the current SPHINCS algorithm (https://sphincs.cr.yp.to/ or ), which is an ever-expanding many-times hash-based signature scheme. In my algorithm though, you can create "keystones" which act similarly to public/private key pairs. Each stone has a list of hash challenges and the specs of the challenge difficulty. For example, if I have a stone of 100 challenges, the stone may say that a valid challenge requires a minimum of 5 challenges to be answered. The challenges are based on 1-way hashes (recursively called with a depth that is included in the params of the stone). So, when you first communicate between nodes, you provide a public global stone, that is replicated, e.g. to a "public key server" analog or wherever. In the initial contact between any two nodes this global stone is challenged, and if successful any future communications between the two nodes works on a private stone (created also in the handshake). Then, each transaction - in the form of ibGib data structures - is proven in the future using that private keystone. The ibGib internal integrity allows for integrity of the data exchange, as it's basically hashing the entire communication for verification.

And so, identity is established among nodes, and all data is verifiable. It's very tricky to really try to "nail down" the provenance once you get multiple nodes involved, but even if there is a known mistake, that is where another aspect of the data comes into play: non-monotonic (append-only) data.

Again, this is like a version control repository for your data. This leaves a full audit trail, yada yada yada, it's really neat. I've typed enough for people to ignore anyway. If anyone is interested, ask about how this affects identity with users AND IoT devices AND AI! Ah well. At the very least, the website is instructional for navigating around merkle forests.