Daniyar Itegulov
Daniyar Itegulov
> To simplify this down, would it be possible to do a firebase db transfer from one account over to another? Yes, this is actually what I did during that...
Seems unlikely that this is happening for POC1. There are also just general concerns regarding this approach, reposting @DavidM-D's message here for context completeness: > Apparently aggregate key derivation isn’t...
This is a part of a bigger problem where near-sdk-rs decides whether a function is `call` or `view` purely based on how `self` is borrowed. In this case, `factorial` borrows...
I think this might be helpful, but I would rather wait for a user-driven demand to appear first to understand the use pattern. Unless you already have something specific in...
Yeah, it's going to be impossible to traverse the entire call tree outside of rustc, so I don't think we can do much here tbh.
> It seems the error might originate from git2, cargo uses this internally, and [we do too](https://github.com/near/cargo-near/blob/885437e5c966766e981e36ccd9a88fcdeb6cf882/integration-tests/tests/cargo/mod.rs#L12). So you suspect this is some sort of concurrency issue between us and...
Yeah, that is my intuition as well, was just wondering if you had a specific issue in mind. Yet to experience it myself, but I will keep my eyes open...
Just to chip in from the backend side on this, we are already using [`tracing`](https://docs.rs/tracing/latest/tracing/) so from our perspective as long as you can provide us with a unique tracing...
We definitely need to organize all of the possible non-500 errors from mpc-recovery and add them to the public API. What would you prefer this to look like though? Would...
> Implement human readable errors on MPC Also, just to clarify, I think they are reasonably human readable even right now. For example the most common error we return right...