Fractal identities about fusion-identity-spec HOT 12 OPEN

First off, thanks for raising this. It is a very good question.

I'll try to answer by contrasting meta feeds and fusion identity. Mostly as a way to digitize my hand written notes.

Common to both of them is that they link feeds together.

meta feeds

• single device
• identity split
• hierarchy
• besides linking does: metadata
• feed based

metafeed
|
-> feed1
-> feed2

fusion

• multi device
• identity fuse
• free linking
• besides linking does: create new identity
• tangle based

       o root msg
      / \
     /   \
    /     \
   o       o
 feed1   feed2

I'll stop there, it is getting late. To be continued.

from fusion-identity-spec.

In broad strokes yes to this idea @staltz
The trouble (as always) is the implementation details.

Things you also need to consider are :

• consent to joining a grouping
• the death of a grouping, (and maybe rebirth of another one)
• knowing who or what to replicate
• abuse vectors

We're aware of the idea of fractal identities, and are holding them lightly to see how they fit.

One major challenge is that our current identities (feedIds) are not compatible with being fractal - eg all our replication is feedId based, but any macro or micro identity, while it can use a public key to self identify, that alone does not tell you easily who or what to replicate (eg you may have to replicate 3 feeds to build a macro / fusion identity).

from fusion-identity-spec.

Why does the fusion identity be that complex?

GPG has already the concept of subkeys - that is you have a main key that is used s your identity and to perform specific operations you use subkeys.

To extend this to identities you could have a main identity key that is used to manage identities for specific purposes, and key for this identity can be stored in storage that is not readily available (needs passphrase to access, on hardware token, ...) while an identity that is used for writing messages day to day on a specific device will be easy access so long as you are in possession of the device.

If you start by creating a fusion identity you first create the main one, and then you create a key for each device and join them to the main identity (signed off both ways). If you want to create fusion identity using existing device-specific identities you sign-off the join both ways.

By publishing the joined identity sign-off the clients that support fusion identity can follow the main identity once they see it.

Only minor opportunity for hijacking is when you are upgrading to fusion identity and there are people following the device specific identities with clients without support for fusion identity for a long time, you lose access to a device, and an attacker publishes sign-off to new fusion identity using the lost device.

from fusion-identity-spec.

from fusion-identity-spec.

Which is then subject to hijacking. If there is not one source of authority about your identity then your identity is not well defined.

from fusion-identity-spec.

from fusion-identity-spec.

Or to put it differently the any key has control scheme is any key to rule them all - any key is a single point of failure, while the one key to rule them all has one single point of failure. I find the latter more manageable.

from fusion-identity-spec.

Thanks for your opinion! I disagree <3 We're going for something more like "intersubjective identity". It works well in human groups. We are defining clear rule for how a group of devices define their relationship in a clear way. If you're not interested in

This way does not seem clear. That's the issue.

this approach, that's all good (but you're probably then looking for a different spec).

And network different from ssb

from fusion-identity-spec.

There are ways to share key within N nodes with m-redundancy which will not give one node the authority to make any global decision and at the same time it will be resilient to loss of some nodes but it would require confirmation of global operations on multiple devices which is quite impractical.

from fusion-identity-spec.

from fusion-identity-spec.

The problem is that the moment any of your devices is compromised your whole fusion identity is compromised as well, and you have to reestablish you identity from zero. Then it is questionable if there is any point in having a fusion identity at all, and what problem it solves.

Because of time relativity you cannot see the global state of the whole network and the extent of the compromise so you will never know if a redirect is feasible hence you should assume it is not.

from fusion-identity-spec.

As in if you have a bunch of separate identities on which you can write informal in-band messages about the state of your fusion identity you are better off than formally establishing it on the protocol level.

from fusion-identity-spec.