You are reading content from Scuttlebutt
@andrestaltz %qmAE4kAJitHHMek2Zd7zXqQQPQkiBw3Axxn79WIo2a8=.sha256
Re: %+c38aXIa2

@Dominic In the occasion you open up SSB again, what is your opinion if we altered SHS so that the client authenticate payload includes an extra 64 bytes that the server can use to allow the connection? Like these lines: https://github.com/auditdrivencrypto/secret-handshake/blob/7a465d19f9c36fa2bb2cf6f4e5271bbd68d2cd74/crypto.js#L164-L165 after the 96th, there would be some 64 bytes extra. This way we could pass these invite tokens or anything else, so that secret-stack auth() can make a decision not only on the remote peer's ID, but also on other data. In the default case those 64 bytes can be zeroes.

It would be backwards compatible with SHS, except that SHS implementations currently check that the client auth payload is exactly 96 bytes. So it's a pretty simple change overall, but to avoid the breaking change, we could make it a separate "shs2" transform (or "shse", where "e" means extra, or extended).

Asking you because I don't want to mess them up and you should be the best contact for this. But pinging other folks who might have an opinion: @cryptix @arj @cel

User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
Join Scuttlebutt now