Heimdall-rs integration initial version

[technophile-04]

Description :

Since we are done with migration from SE-1 => SE-2, I think we should start thinking about heimdall-rs integration basically to allow people to interact with the abi of unverified address.

Some initial steps on top of my head :

~1. We need an heimdall-rs backend~ ~1. Maybe we can create a dir heimdall inside packages basically a yarn workspace similar to how we have packages/nextjs & packages/hardhat~

EDIT: The above does not apply since seems backend needs to in rust

2. To keep things simple for initial version maybe we can create new tab "Heimdall" on abi.ninja Home page

3. Figure out deployment of heimdall-rs backend

Lol not completely sure if I am on right track but maybe @portdeveloper has more context on this 🙌

Let's try to keep the initial version minimal and get basic things working we can always iterate nicely once we have a nice basic setup

[portdeveloper]

https://heimdall-api.fly.dev/

I already have a backend ready but it definitely is not an optimized one :D

The way you use it is: https://heimdall-api.fly.dev/generate-abi/0x78bee64f2e74a2e5b561152059c389da74124914

This is the SimpleStream contract by buildguidl

[technophile-04]

Ohhh this is great !!

I think then lets get the frontend working with this api endpoint what do you think ? If we hit any limit with fly.dev hosting we can think of some better ways also cc @carletex if has some different idea 🙌

[carletex]

Maybe we can use it while we develop, but eventually, I think we should deploy our own BG Heimdall instance

[portdeveloper]

My current backend is not optimized at all but it works fine for testing purposes. I made gpt write the code for it and it is a huge image right now. You can check a simple frontend that uses it here: gulltoppr backend code One option is to optimize this backend. The other could be to adapt heimdall to work inside the browser using wasm. I don't know if this is a viable option, looking forward to hear your opinions on this matter.

[carletex]

You can check a simple frontend that uses it here: gulltoppr backend code

This is great Port!

One option is to optimize this backend.

Do you mean that the docker image is too big? Maybe we could use alpine instead of ubuntu for a smaller image.

In any case, I think it'd be great if we use gulltoppr. We could deploy an instance for BG. Where are you deploying it right now?

---

Regarding UI... I was thinking about something like:

1. Initial page

2a. If the contract is verified => just do as usual, going to the contarct page

2b. If the contract is NOT verified => Show an intermediate screen:

"The contract 0x65a...5605 is not verified". Two options -> 1. Paste the ABI

-> 2. Use heimdall (experimental) (maybe a tiny explanation here)

=> Go to the contract page.

What do you all think?

[portdeveloper]

@carletex

Yes, the docker image is too big and I am having trouble optimizing it since I don't know how to handle dockerfiles and it currently is deployed to fly.io. Let me try to optimize it one more time, with the best of my knowledge, then since the source is available on gh, we can fork and then deploy as BG. I will let you know when I finish it.

Also the UI idea you have is very similar to what I have in mind. So I think it is great. It makes using abi.ninja easy for people who are not web3 native, which is something we are definitely after.

[portdeveloper]

I have changed the way heimdall backend works, here is the current address: https://heimdall-api-cool-frog-2068.fly.dev/ for example https://heimdall-api-cool-frog-2068.fly.dev/10/0x964d0C9a421953F95dAF3A5c5406093a3014A5D8 gives the optimism sandgarden stream contract abi. the endpoint is /CHAINID/CONTRACTADDRESS

As for the optimizations, since this is literally a whole ubuntu system that calls commands, I failed to optimize it. The img size is 1.95 gb. If you would like to try the code is here: https://github.com/portdeveloper/gulltoppr

[carletex]

Thanks @portdeveloper !

We can use that URL for testing & building the functionality and then we can decide.

As for the optimizations, since this is literally a whole ubuntu system that calls commands,

I'm not an expert in Docker, but I know that there are some «slim» images like Alpine or debian:slim. It could be an option if you want to try. But if you don't enjoy doing so, like this is fine :D

[portdeveloper]

Thanks @portdeveloper !

We can use that URL for testing & building the functionality and then we can decide.

As for the optimizations, since this is literally a whole ubuntu system that calls commands,

I'm not an expert in Docker, but I know that there are some «slim» images like Alpine or debian:slim. It could be an option if you want to try. But if you don't enjoy doing so, like this is fine :D

Even with a slim image i can get it down like 100-200 mb, which is not worth it I guess. So until we have problems with this I think we can keep it as a 1.95 GB image lol

[technophile-04]

Completed at #71