Compared to the Schnorr signature, the range of applications for vetKeys is incomparable. Can you prioritize vetKeys?
Hi @andrea , thank you for the insight about the current timeline. VetKeys came up on Thursday during the Decentralized AI Working group call and based on that I wanted to provide the feedback in this thread that there are several DeAI projects interested in using it for their prototypes and products. These are use cases around private training and inference data as well as storing outputs (e.g. user chats with the AI service) with maximum privacy. So vetKeys could be a great enabler here and also a differentiating factor for DeAI on the IC compared to traditional AI services. Please let us know if we can help in any way with the potential prioritization of vetKeys.
We have an internal working group that takes a look at the feedback board every two weeks and we put quite a bit of emphasis on the most-upvoted feature requests (7/10 of the most upvoted requests are in the works or scheduled very soon for work to start).
I just noticed we don’t have vetKeys in the list yet so we don’t get reminded often enough of how much demand there actually is so I went ahead and created a feature request for it: IC Feedback
My hope is that with a fair amount of upvotes on this feature we can get it some more priority.
TLDR: upvote this please 
Hello!
Thanks a lot @Vivienne for making the ticket, and thanks everyone for the upvotes - it helps to keep it front of mind.
Thanks also @patnorris for the use case motivation. Definitely would be good for the output privacy, but we should be careful to remember that it may not be so useful in the training context as we cannot do private computation with vetKeys.
As an update about prioritisation, it’s certain now that threshold Schnorr will happen first (as it is much faster to integrate) and vetKeys will happen after.
I’ll send updates as and when we have them.
Hello,
Thanks @Vivienne for pushing this topic forward, many projects are waiting vetKeys to be completely done. I’m just curious, is there a features-list or public roadmap for vetKeys? just to have more clean understanding on feature state, like what is completely done and what has to be done according to the Dfinity vision.
AFAIU the research is done and the preview canister developed, but the implementation has not received much attention yet. From what I heard there is a lot of work left to do, which is also why tSchnorr was put before vetKeys
thanks for the clarification 
Hey everybody,
If you are interested in leveraging vetKeys in your projects, please fill out this quick survey.
Thank you 
this is definitely an intruguing idea and concept.
Is this survey still ongoing?
We’ve evaluated a while ago, but there are still responses incoming and we’ll keep it open for now as new projects are exploring vetKeys.
Hi @ais , I wondered if you might have any news to share on the vetKeys roadmap; do you know when there might be an update available? I’d love to include it in our dApp (and also optimistically have put this into our grant milestones) Thank you 
Word on the street is that the new ICP roadmap will be out this week, keep an eye out for it 
That’s exciting, will sure do, thanks
No due date mentioned.
No specific date, but this is the roadmap for year 4, so it should be safe to expect it within the year.
Schnorr has a date, and vetkeys starts right after that.
I’m not sure if they had a webpage, but I’ll forward your message on some internal channels we had!
Does vetkeys generate a unique decryption key for the user?
Preferably like proxy re-encryption. If the decryption key is leaked, it will be possible to identify which user leaked it.
@nokemono, what vetKeys will provide is mainly a management canister API that canisters can call to derive a strong cryptographic key from a master key (see vetkd_encrypted_key in the proposed API), where the master key is secret-shared among the nodes of a subnet. The derivation is done based on some derivation information that the canister developer chooses (plus the calling canister’s principal). The derivation information is essentially a byte string and can be (but doesn’t have to be) a user’s principal. The derivation is deterministic, that is, if the same derivation information is passed to the API, the derived vetKey will also be the same. So, if a canister developer uses a user’s (unique) name or principal as derivation information, then the vetKey for the user will be unique, yes. However, it really depends on the use case: for example, the canister developer could (for whatever reason) also choose to use the same derivation information for two different users, in which case both users would receive the same vetKey and it thus would not be unique.