search

ssbc / ssb-meta-feeds-spec

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

Seed location #13

Open arj03 opened 3 years ago

arj03 commented 3 years ago

On a call with mix, it came up that we should probably just store the metafeed seed inside the secret file. Cryptix mentioned that it would be good to put this into a section where you can put other metadata, like latest sequence number or other seeds / keys.

staltz commented 3 years ago

@arj03 and I got on a call to discuss various things, and this issue was one thing, where he asked my opinion. I don't have a lot of context in how box2 works, or all the details in metafeeds, so my comment here is just provisional.

Mnemonic recovery of secret

Primarily, I'm concerned that if we store more unique information in secret, then that changes/increases how many more words end-users need to remember when using ssb-keys-mnemonic. See e.g. this user complaint when we used to have 48 words:

... the user experience when doing so was far from delightful: I missed a word when writing down the 48 words, and I forgot a single line with words and misspelled a word when trying to confirm that I had actually written down all of the words.

I would like to suggest a method that reduces the necessary number of words to 25 (which is still a lot, I think)

We should think of the secret file as merely an expanded format for the 24-word recovery sentence. Given one, you can derive the other and vice-versa. It represents only one thing. Also, it was designed to be a readonly file, supporting only C R U D.

Metafeed-first or metafeed-bridge

Another insight I had to this problem was regarding the use case of meta feeds. It seems like there are two use cases for metafeeds:

  1. Metafeed-bridge: I have an old classic feed, which I would like to keep on using, and I would like to create a new meta feed as well
  2. Metafeed-first: The year is 2025, I just started using SSB, and I don't care about a classic feed, I started my primary account as a meta feed

We are primarily thinking of use case (1), but (2) should be a decent choice in the future, and it seems better suited as a long-term solution. (1) seems to be a bridge to the future, so it would be good to not solidify it as the only use case supported.

So we need to think how to store the meta feed for use case (1). I think the box1 self-DM is an okay compromise. I couldn't quite understand the reasons to avoid it, the meeting notes with @mixmix mentioned:

  • mix: I don't really want to be forced to use box1 to bootstrap box2

But not much more details on the why. Is it cumbersome in the implementation details? Is it a matter of principle, like avoiding depending on box1 entirely (why?)?

Could we devise (for Ahau only) a subcase of use case (1), where we store the meta feed seed in a place that does not require box1 to retrieve it? Perhaps it's a box2 self-DM.