Nickolay Olshevsky

> > I.e. something like rnp_weak_feature(type, bool)/rnp_weak_features(type, string) > > `rnp_weak_algorithm()/rnp_weak_algorithms()`? @antonsviridenko Sorry, mislooked this question. Basically I proposed `feature` semantics since it can go beyond of just algorithms in...

> > @antonsviridenko Sorry, mislooked this question. Basically I proposed feature semantics since it can go beyond of just algorithms in a future - it may be curve, RSA key...

Thanks for reporting, we'll add corresponding functionality once get to this issue.

@andrey-utkin Feel free to take it! The only thing is that I'd prefer to make this feature configurablte via the SecurityContext, so user may enable or disable this. Feel free...

> I will proceed by investigating it and in parallel fitting the test into some existing test suite. > Pythonic one seems to be well-suited for such things, is that...

@andrey-utkin Good news! Agree with your approach: `on_recipients()` should have original recipient list (so implementation which uses corresponding FFI API may see that original recipient was hidden), and `used_recipient` should...

@andrey-utkin Great! Could you please create a draft PR from your branch? It would be easier to discuss changes there (and would run CI including linters and so on)?

Some more details: key contains userid revocations, not the key revocations. So, since key itself wasn't compromised, and user just revoked and then certified userid back, we should not mark...

> However, PHP code can always call external command line tool, like `gpg` or `rnp`. This would not be a good approach for high-loaded servers, and may lead to some...

> ok, how it should look like? > All API functions from exported as close as possible to original C version? It should be something similar to `ruby-rnp`/`py-rnp` : first...