The work we're planning will not enable EVM compatibility. There's been some other people who talked about such possibilities, but I suspect it would be quite a lot of work, so I an not really sure it

I see. We work pretty much exclusively on Ubuntu, and I've no experience at all with Proxmox. I can say that in my own personal experience, I found administration with ZFS infinitely more friendly than

Hmm, just FYI, we've been running on ZFS on nvme SSDs for a couple of years now without any issues. We pretty much exclusively work on SSDs for our databases.

1st layer functions don't know anything about 2nd layer stuff. So you can't escrow 2nd layer tokens. But you can create a 2nd layer escrow function. You can achieve all functions on the 2nd layer just

Most recently I've been thinking that complex financial instruments are all better handled at the 2nd layer. In other words, bonds, markets, escrow, etc would all be implemented there. Any link to base

We're in the process of simplifying and standardizing deployment of haf apps right now: soon it should be trivial to deploy properly configured ones.

I'm not sure what's available nowadays, there used to be a service by buildteam.

HAF was designed exactly to allow such api calls to be added easily. In this case, I suspect it could be easily added to the hivemind app. I don't consider such changes "core changes", nowadays

My understanding of publish/subscribe is very limited, but does it allow to selectively copy over only some of the data from a table, e.g. only custom_json ops with a certain ID? It doesn't, but there's

Sounds good.

I think all the features/benefits described here are already available thru the publish/subscribe features of postgreSQL. In other words, you can run a HAF server that publishes some of its tables and

HAF doesn't place any restrictions on the shape of the API. So it is certainly possible to use GraphQL with HAF and it can be done without much effort.

The database software runs in the same container as hived (this is the "haf" docker), but by default you end up bind mounting your hived workdir and the database's storage to a local directory.

Actually several of our devs are on vacation now, which is a bit painful for me as I await their return :-)

Good catch, you're correct. It was supposed to be need, not new. I've fixed it now. I do try my best to avoid mistakes, but I sometimes go back and edit sentences to try to improve their readability and

The repo for hived is located at . The repo for HAF is located at .

The base spec for a HAF server is extremely small (something like 6GB of storage space). So I suspect you're looking at the storage needs to store the entire blockchain (theoretically around 3.5TB, but

Yes, it's mainly SQL, and we did spend a lot of effort speeding up that SQL code (as well as refactoring it for easier future development).

I haven't read it, but I can imagine the problems that result :-)

I tried my best, although on a re-read I still see a lot of unexplained terms like docker containers. But hopefully the gist of it is clear.