MarkusTeufelberger

The new UI is in beta now: https://blog.jupyter.org/jupyterlab-is-ready-for-users-5a6f039b8906

Practically every x509 certificate out there has version 3, please use that if you fix this.

x509_ptr cert = x509_new(); x509_set_pubkey(cert.get(), pkey.get()); x509_sign(cert.get(), pkey.get()); Hngggghhhh... As the co-author of https://docs.ansible.com/ansible/latest/collections/community/crypto/x509_certificate_module.html this looks a bit... let's call it fast and loose. Yeah, version 1 or 2 might...

I'm not too sure if HTTP return codes should reflect the underlying JSON-RPC calls, but the spec there is surprisingly sparse...

Golang has a nice implementation too by the way, in case you don't want to read OpenSSH code: https://pkg.go.dev/golang.org/x/crypto/ssh#Certificate

`actual_median_fee` sounds more like an elaborate joke to be honest. If the `median_fee` is defined as the median fee of the last validated ledger, it should be either 0 or...

This information doesn't have to be stored on-ledger, it can be just returned by `rippled` (if necessary: in a new API version)?

I also would prefer removing the NTP stuff from the code base. It is a nice safety net in some edge cases, but it masks operator errors and could lead...

Is the y axis inverted or are you actually talking about a _maximum_ fee? This would just slow down the response time to attacks that cause the fee to spike...

I'm not certain this requires an amendment? It would make coordination/communication easier, but in the end transactions with higher fees are still valid to every node that doesn't run this...