search

ssbc / ssb-meta-feeds-spec

Design doc for subfeeds in SSB
11 stars 1 forks source link

Nonce field should not exist for adding existing "main" feed #22

Closed staltz closed 3 years ago

staltz commented 3 years ago

In Existing SSB Identity case, we have

{
  "type" => "metafeed/add",
  "feedpurpose" => "main",
  "subfeed" => (BFE-encoded feed ID for the 'main' feed),
  "metafeed" => (BFE-encoded Bendy Butt feed ID for the meta feed),
  "tangles" => {
    "metafeed" => {
      "root" => (BFE nil),
      "previous" => (BFE nil)
    }
  }
}

However, in New SSB Identity we have

{
  "type" => "metafeed/add",
  "feedpurpose" => "main",
  "subfeed" => (BFE-encoded feed ID for the 'main' feed),
  "metafeed" => (BFE-encoded Bendy Butt feed ID for the meta feed),
  "nonce" => (bencode byte sequence with 32 random bytes),
  "tangles" => {
    "metafeed" => {
      "root" => null,
      "previous" => null
    }
  }
}

Note that in the second we have nonce and in the first case we don't, but the message type is "metafeed/add" in both cases.

This is a gotcha, currently JS ssb-meta-feeds is wrong because it has a nonce for the main feed, which is wrong, because the nonce has nothing to do with deriving the main keys.

cc @arj03 @cryptix

cc @mycognosist for validation

cryptix commented 3 years ago

hm.. removing the nonce sometimes is a bit odd to handle when reconstructing a metafeed, tho.

Like, if i only have the metafeed secret but not the existing secret what should happen? the sometimes it's okay not to have a nonce feels glitchy and another message type might be clearer. like maybe "metafeed/add/existing" and "metafeed/add/derived"?

staltz commented 3 years ago

another message type might be clearer.

This is one of the ideas I came up with as well, when in a call with arj. I'm also fine with it.

@arj03 ?

arj03 commented 3 years ago

I'm good with another type.

staltz commented 3 years ago

maybe "metafeed/add/existing" and "metafeed/add/derived"

I like this