ssbc / fusion-identity-spec Goto Github PK

is it:

• the root message key?
  • if yes, then why is the proposed format @sdafsdfsdf=.fusion-v1
• is if the public part of a public/private keyPair that then gets used for DM'ing?
  • if yes, how do we share the private part, and publish the public part?
  • how do we cycle the dm keys? (do we need to?)

great that you push that frontier!

When reading the spec, I stumbled over tangle fields where I was surprised to see the same values popping up. Are these editing errors?

In the invite op, there is

  tangles: {
    fusion: {
      root: '%ZxAJbfRTwhkhpD9viErN9zBzIEzrm6FTndaH/bEnbfI=.sha256', // init
      previous: ['%ZxAJbfRTwhkhpD9viErN9zBzIEzrm6FTndaH/bEnbfI=.sha256']
    }
  }

and in the consent message, the exactly same tangle data appears

      previous: ['%ZxAJbfRTwhkhpD9viErN9zBzIEzrm6FTndaH/bEnbfI=.sha256']

while I would have expected that its previous field would point to the invite message.

The proof-of-key section has placeholders, it seems:

  tangles: {
    fusion: { root, previous }
  }

And in the tombstone operation, the given previous value is the same as the root

tangles: {
    fusion: {
      "root": "%IyaQ/IeV2PYpznyBFCO+qSz3Uu/8HtlqoBbwCE7+dvU=.sha256",
      "previous": [
        "%IyaQ/IeV2PYpznyBFCO+qSz3Uu/8HtlqoBbwCE7+dvU=.sha256"
      ]
    }
  }

which would be quite a special case of tombstoning a fusID immediately after having created it (and before sending the DM to self, or having received an invite etc).

Or do I get it wrong and there are reasons for these field values being correct?

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?

I like the message sequence chart very much, helps reading the protocol! Here is a copy:

   @laptop                      @phone
   -----------------            -----------------
   init ->
   invite: @phone ->
                                <- consent
   entrust ->
                                proof-of-key

where I suggest to

• have all messages included,
• mark those which are DMs, in contrast to public ones.

More a personal preference: all non-encrypted entries are essentially meant to be a global broadcast, hence I think that the -> arrow is misleading. May I suggest the following iteration of your MSC?

t  @laptop                                 @phone
-  --------------------------------------  -----------------
1  init(@fuID)
2  enc(entrust(sk)) -> [@laptop,@fuID]

3  xID=invite(@phone)
4                                          cID=consent(xID,yes)
5  enc(entrust(cID,sk)) -> [@phone,@fuID]
6                                          proof-of-key(cID,proof)

I suggest to add the consentID to the proof-of-key message in clear, not only implicitly in the signature, because one should close all invite transactions individually (I understood that there can be several of them running in parallel, e.g. issued by different members of a fusionID), visible for all to see this closing.

From that transaction point of view, the xID is its identifier. Hence, I suggest to replace all consentID values with xID, as I called the invite's message ID, and use the fieldname inviteID.

Finally, in the consent section of the spec, one could spell out that this message format also permits to decline the invite which then also closes this transaction.

in the specification it says the following is true:

• fusion identities is intended to be used for private messages (being able to pm the fusid and all related accounts will receive it)
• not intended / out of scope: Inviting fusion identities to private groups

as i see it is this is more of an issue today than when originally forming the spec. the reason is that that private groups are now being worked on, with initial implementations of it targeting deployment in manyverse under the guise of private messages i.e. replacing private message functionality with private groups chats (tho iirc there will be some layer to decide if to PM or to PG?)

anyway: the first bullet above feels like one of the most important drivers of fusion identites, and very soon it will effectively not be true anymore. have the ngi assure batts working group planned a revision of this specification? cc @arj03

Might make sense because:

• They are general concepts
• They are not 100% needed for the spec, a MVP can be just the fusion

Related, we can do authenticated redirects as as extension without complicating this spec too much.

Right now we use:

Private messages are encrypted as box2 using using the group key slot.

• Be clear about message schemas
• Document clearly preconditions in each step (state machine)