Creates a Signed Arbitrary Signal Payload

[Romulus10]

Alright, so this is my current model for emitting signed signals. It's a little bit simplistic right now and has 0 bounds-checking to prevent the size of signals from slowing consensus to a grinding halt, but I figured I'd open this up and we can talk through how we think the best way to tackle this might be.

[isaacadams]

starting a new thread to separate the discussions.

just rely on the SubKey signature, or generate a signature based on the key used by the application issuing the signal.

this was from your initial reply

when you say "the key used by the application issuing the signal", by application do you mean "smart contract" (or an app using a smart contract to interact with Fennel) and the "key" is the account key associated with that smart contract?

[Romulus10]

starting a new thread to separate the discussions.

just rely on the SubKey signature, or generate a signature based on the key used by the application issuing the signal.

this was from your initial reply

when you say "the key used by the application issuing the signal", by application do you mean "smart contract" (or an app using a smart contract to interact with Fennel) and the "key" is the account key associated with that smart contract?

First off, we won't really have smart contracts interacting with the chain at all. When I talk about applications here I'm talking about off-chain, more 'traditional' apps that use the chain as part of their remote infrastructure. In this case, the key I mentioned will be the key generated to represent the user of that application to Fennel - so think of it as one of the keys an app on your phone might use to identify itself to the service on the other side of the interaction. Your account might have an identity for each app, and it might have the option to have a key for each of those identities.

[isaacadams]

@Romulus10

First off, we won't really have smart contracts interacting with the chain at all.

will smart contracts still technically be able to be deployed?

In this case, the key I mentioned will be the key generated to represent the user of that application to Fennel

gotcha. yeah, I think this is what I was getting at before in my long comment. Basically, what exactly is achieved by generating unique public/private keys for every identity that isn't already done by virtue of blockchain mechanics.

If you are sending a signal from any app, all you need to do is pass in the identity index you are sending the signal with. By virtue of blockchain mechanics, the AccountID will be present (as you being the sender) and our logic will check if you are not the owner of the identity -- if not, cancel transaction. If all checks out, continue.

The signal is the cryptographically signed/secured and all desired properties are retained (ie we know the identity that sent the signal and we can have cryptographic/blockchain level certainty that this identity is owned by the account that sent it)

I am not sure if I am missing something, however

[Romulus10]

will smart contracts still technically be able to be deployed?

Currently that's not considered. We might add it (MIGHT) but it's beyond scope of this protocol.

gotcha. yeah, I think this is what I was getting at before in my long comment. Basically, what exactly is achieved by generating unique public/private keys for every identity that isn't already done by virtue of blockchain mechanics.

It's really a balance of how much emphasis we want to put on identities. I'm not sure it makes sense at this juncture to add an identity signature when all that's needed is a storage spot for it. That's easily changeable later.

If you are sending a signal from any app, all you need to do is pass in the identity index you are sending the signal with. By virtue of blockchain mechanics, the AccountID will be present (as you being the sender) and our logic will check if you are not the owner of the identity -- if not, cancel transaction. If all checks out, continue.

Yeah. That's what I'm thinking as well.

The signal is the cryptographically signed/secured and all desired properties are retained (ie we know the identity that sent the signal and we can have cryptographic/blockchain level certainty that this identity is owned by the account that sent it)

We also have the benefit of not having to juggle things to make it so you can add a signature to a signed payload without invalidating the signature. I know there are things we can do to make that so it's not a problem anymore, but it could get janky fast.