Since you are pinging me about this, I guess you missed this announcement from last year:

Not yet, we'll need to review the scope of required work after we release all the new HAF stuff, then come up with a reasonable timeline.

Conceptually similar, but the implementation is quite different.

HAF is perfectly usable now and the docs plus examples are sufficient for someone to create a HAF-based API. But we've been develop several apps so that we could determine best practices for how to create,

I'm sorry that people are still downvoting your account, but I guess even after all this time there are people that are still upset about what happened and not willing to forgive the misguided. You could

This is my comments, I'm reasonably active:

This is rt comments list:

We build/run dockers in ubuntu 22 still. You only need 23 for the "host" that runs the dockers, so there's no need to compile on Ubuntu 23 if you don't want to.

For the most part, our systems use 980s and a couple of 990s. We got this one system a couple of weeks ago specifically when we needed to run replays as fast as possible.

It's probably not the memory speed, so much as the next generation AMD processor (7950 vs our "normal" 5940s) plus those CT4000s (those are the super-fast PCI 5 gen nvmes). This was also run

And a good example app is located here:

Readme's in these repos are good starting points:

This is the most recent post I've read on Hive related to it:

I've been studying mandarin pretty intensely this year, and one of things that worked best for me was language reactor. It is a web browser extension that "overlays" video networks (in particular,

Has the code been open-sourced yet? If not, when? As I recall this one of the key points of the related DHF proposal...

Thanks for the link! I'm not familiar with the multi-signature compression library he mentioned, but it doesn't sound like it would be super difficult to integrate if needed. The part of the code that

Seems like the best solution to me.

Thanks, I couldn't remember why it worked this way... Personally, I've still got no strong opinion one way or the other, both ways seem to have advantages and disadvantages. Given the way I suspect people

There's a lot of changes in the way we're defining new API subsets. The json_rpc API will continue to be supported for existing API subsets, but new API subsets are all defined to be accessible via REST

The 2nd layer is definitely the best place for that in my opinion. The work we're doing there should make it much easier to integrate defi apps at the 2nd layer.