Closed staltz closed 1 year ago
[x] change those to getters, so they cannot be written to
Great idea! I did that now in a new commit.
[ ] do you want a Buffer returned instead? Or as well?
I thought about this, but Buffer has the downside of not being as easy to compare as strings are. Also, transforms (shs, shse) are free to define their own identifiers, and this means that if you want to customize the identifier then it's just a matter of making your own transform plugin (which is not that hard to write, if you look at the shs plugin in this repo).
Plugins (and swapping plugins for compatible ones) sounds like the secret-stack way, instead of forcing a standard everywhere (which is what ssb.id
is).
Context
This work is motivated by PPPPP using secret-stack with new identifiers for peers based on their public key.
Problem
Currently, secret-stack hard codes IDs
@<BASE64>.ed25519
.Solution
I first thought about adding a special config that allows you to customize the peer ID to be whatever you want, but this was more complex to implement and also requires you to configure such if you want a new ID system. That's not the secret-stack way, which so far has been mostly driven by plugins.
So what I went with instead is that secret-stack doesn't (or shouldn't) have a secret-stack-wide ID, but instead the transform plugins have the responsibility of determining the IDs. This is already true for secret handshake, because
lib/plugins/shs
is the one who setsapi.id
.See the tests changed in this PR for a simple example.
So now
shs
=> sets "legacy"api.id = "@<BASE64>.ed25519"
shs
=> sets "modern"api.shs.pubkey = "<BASE64>"
(this is the same assecret
filepublic
field)shse
=> sets "modern"api.shse.pubkey = "<BASE58>"
So instead of using
ssb.id
, the modern way will bessb.shs.pubkey
or with PPPPP it'sppppp.shse.pubkey
.