search

ssbc / ssb-meta-feeds-spec

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

Decoupling ID from feed #14

Closed staltz closed 3 years ago

staltz commented 3 years ago

I'm terribly sorry to bring this up now, some things I only notice once I start getting my hands dirty, but maybe in the big picture, it's still early enough to bring it up.

Keep it @*.ed25519

I'm inclined to say that meta feeds should be marked with the ref @*.ed25519, not @*.bbfeed-v1. Today was the first day I discovered that bbfeed refs are actually ed25519 public keys. So in a way, @*.bbfeed-v1 is a special case of @*.ed25519 which only indicates what the identity is used for. See tangential comment 1.

There are two concepts worth pointing out. Conceptually they are different things, although in practice they are married to each other:

In practice in SSB, an ID is often used to identify a feed, and sign the messages on it. But that's not the only use case for the crypto keypair of that ID. We also use the keypair to establish an encrypted channel via secret-handshake. The establishment of the shs connection has nothing to do with feeds, and ssb-tunnel / ssb-room proves that you can have an ID that is not related to any feed (the room server's ID). See also tangential comment 2.

I would like to propose that we use @*.ed25519 as the serialized format for the ID used to identify the meta feed, because:

Tangential comment 1

In a parallel universe, instead of the sigil-based refs, we could have pursued a "multiserver address" style of writing these identifiers. Multiserver addresses have the shape transport~transform, e.g. net:foobar.com:8008~shs:xyzxyzxyz. We could have the shape cryptoscheme~feedformat, e.g.

Since we're talking about refs and formats, it's also worth mentioning SSB URIs, which are currently spec'd as:

ssb:feed/ed25519/<FEEDID>

But it's not hard to extend that spec to become

ssb:feed/classic/ed25519/<FEEDID>     <--- JSON.stringify V8 stuff
ssb:feed/bbfeed-v1/ed25519/<FEEDID>   <--- meta feeds
ssb:feed/none/ed25519/<FEEDID>        <--- rooms would use this

Tangential comment 2

One tangential discussion, which I'll try to go into details in another issue/occasion, is "when I possess multiple IDs, which one is the owner of the shs connection?"

staltz commented 3 years ago

One counterpoint to my own arguments is that for shs connections, we don't use @abc.ed25519, we use abc, so for metafeeds this means that we just strip the @ and the .bbfeed-v1 to get the ed25519 public part for the shs connection.

cryptix commented 3 years ago

Related discussion about SHS in a world with more encodings: https://github.com/ssb-ngi-pointer/ssb-secure-partial-replication-impl-spec/issues/1

Just for historic reference re: the actual meaning of the suffix: A couple of years ago there was a protocol meetup where we discussed getting away from the current signing format. One of the takeaways there was that .sha256 does not just signify the hash function but might stand for scuttlebutt happened anyway and also denotes the format, too. And for me this translates to the signature creation scheme.

I find it hard to extrapolate why this proposal (adding a new type of identifier) is better then having new values for field in an identifier format we already have just because of semantics that are broken to begin with (again, sha/ed25519 is not enough and has implicit meanings).

arj03 commented 3 years ago
  • Semantically, the cryptographic keypair which signs bbfeed messages is an ED25519 scheme, it would be good to make the scheme obvious in the ID ref

A key has 3 fields: id, public and private. It would be good if we can only touch the id part. Also this is mainly internal handling, for external we mark the different identities with their type. This is important for example to figure out if a subfeed of a metafeed is a metafeed itself or just a classic feed.

  • Implementation throughout the existing SSB stack would be easier to adapt, not having to do checks for bbfeed-v1 everywhere

From what I have seen until now quite a high number of the cases where we need to add an additional check for bbfeed-v1 we need to handle that case differently anyway, so it doesn't really hurt. And in general we have ssb-ref to abtract away these kind of checks if we don't care about the feedformat. I'm expecting we use a different EBT connection for these bendy butt feeds as they are binary. There is also the usability aspect to consider that when you get the data from the database, you can easily see what kind of feed it is. While URI's would also solve this problem, that seems like a big change.

staltz commented 3 years ago

@cryptix

I find it hard to extrapolate why this proposal (adding a new type of identifier) is better then...

To clarify what my proposal is, it's not the tangential comments, it's just to keep using @*.ed25519 also for identify BB feeds.

One of the takeaways there was that .sha256 does not just signify the hash function but might stand for scuttlebutt happened anyway and also denotes the format, too. And for me this translates to the signature creation scheme.

It's more true for %*.sha256 than it is for @*.ed25519, because it's a cryptographic fact that %ABCDE.sha256 is a valid signature only for messages in the classic format, with V8 JSON.stringify. But for @*.ed25519 we don't have any such hard facts.

Another thing to note here are blob refs &*.sha256 which are not related to any message format. There was also a plan to add &*.blake2s for blobs (has that ever gone to production?), which is another example that these suffixes designate cryptographic algorithm, not purpose.

staltz commented 3 years ago

@arj03

A key has 3 fields: id, public and private. It would be good if we can only touch the id part.

I see another problem with modifying the ID part: it's not recoverable from mnemonic words, a similar situation to #13. The user would have to remember the 24 words plus an additional info.

The semantic argument still makes sense here: the cryptographic identity is just that, a cryptographic identity. What it's used for is a different concern that should be stored elsewhere, and there would be 3 different use cases: for muxrpc shs connections only (the room server case), for the classic feed, for the bbfeed-v1.

Also this is mainly internal handling, for external we mark the different identities with their type.

Right! That's good we have another way of marking which feed type is it. Based on how the readme is written,

Identity type

Sometimes also know as feeds.

Sounds like identities are being conflated with feeds. My point in this thread is that they have been very often married to each other, but they are still fundamentally different concepts.

From what I have seen until now quite a high number of the cases where we need to add an additional check for bbfeed-v1 we need to handle that case differently anyway, so it doesn't really hurt. And in general we have ssb-ref to abtract away these kind of checks if we don't care about the feedformat.

How do you suggest we treat the case of extracting the sigil ID from a multiserver address with a shs section?

E.g.

Input: net:wx.larpa.net:8008~shs:DTNmX+4SjsgZ7xyDh5xxmNtFqa6pWi5Qtw7cE8aR9TQ= Output: @DTNmX+4SjsgZ7xyDh5xxmNtFqa6pWi5Qtw7cE8aR9TQ=.ed25519

How would we be able to extract @*.bbfeed-v1 in the case above?

staltz commented 3 years ago

I'm close to quitting now that I learned that these are already baked into TFK and ssb-tribes :weary:

staltz commented 3 years ago

Still one open question is how are metafeed secrets stored and whether they include .bbfeed-v1 suffix or not, and how is that going to affect 24-word recovery in the future when the "main" ID is the meta feed ID.

arj03 commented 3 years ago

I think you have two options for the case where the main feed was generated from the 🌱. Either you use the normal setup and encrypt the seed to yourself. Or you store the seed as you mnemonic key.it should have the same size as a ed25519 key. In either case a marker for the type would be good. 1 byte gives you 256 possible values extending the mnemonic from 32 bytes to 33.

staltz commented 3 years ago

Yeah, I think 25 words to remember is not a dramatic departure from 24 words. I hope this number stays limited and other proposals in the future (similar to "seed location") don't extend it to 26 and beyond.

I still think the semantic separation is ideal, but we're too committed at this point to do the separation, so for pragmatism I won't insist on this anymore. Closing it