Fractal identities
staltz opened this issue · comments
I had an idea which relates to this spec so it's worth sharing, I don't know if it's something already discussed between @arj03 and @mixmix but it doesn't hurt to share my thoughts.
As a philosophical framework, I highly recommend Emmi's old blog post about fractal identities: http://emotionalanarchism.com/widening-the-bridges-beyond-consent-and-autonomy-emmi/ just the first 40% of it is enough to give context on what I'll comment here.
Fractal identities
It may be that "same-as" is not a clear boundary, but just a soft consensus on what is an identity, and this consensus depends on your level of zooming. Basically a multi-device identity is just a way of "zooming out" from this group of highly-interconnected nodes and talking about that mesh as if it were one. But you could still individually address its member nodes.
But there are other ways you can "zoom out" and consider a group to be one thing. For instance, you could take the identities arj, cblgh, cryptix, zelf, staltz, glyph, and zooming out they would be considered one identity, ssb-ngi-pointer. And you identify that group with a cryptographic handle. They can belong to a "private group" but "public" (similar to feedless identities) and this would enable some external node to send encrypted messages to ssb-ngi-pointer and so forth.
Zooming out even further, you can group all the core 100 persons in the SSB community and give them a cryptographic handle (a feedless identity?) to address them as if they were an individual.
You probably get the idea of zooming out, and the point is that maybe these mechanisms we're building are not just to "identify a person" but they can be used to "identify groups" where the meaning of "group" is not just "gathering of persons" but much more flexible. E.g. a person as a group.
Now, instead of zooming out, what about zooming in? Can we split the "classical feed" concept into several different pieces and then do "soft grouping" of them? I think so. I think that's what metafeeds and partial replication are about. Feeds can now be split in the microscopic level.
So we can have fractal identities in both microscopic and macroscopic scales. My main question now is: why do we have different mechanisms for the microscopic (metafeeds) and for the macroscopic (feedless identities, fusion dance)? Could we somehow unify these concepts? Would it make sense?
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.
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).
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.
Which is then subject to hijacking. If there is not one source of authority about your identity then your identity is not well defined.
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.
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
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.
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.
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.