Ability to display similar information like at
https://ordinals.com/inscription/6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0

For unconfirmed inscriptions, there will not be an inscription number just yet.

system: macOS 13.4 (22F66)

clang --version
Homebrew clang version 16.0.4
Target: arm64-apple-darwin22.5.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin

rustc --version
rustc 1.71.0-nightly (5ea3f0ae0 2023-05-23)

error: failed to build archive: 'wasm.o': section too large

The following warnings were emitted during compilation:

warning: In file included from depend/secp256k1/src/precomputed_ecmult_gen.c:7:
[...]
error: could not compile `secp256k1-sys` (lib) due to previous error
warning: build failed, waiting for other jobs to finish...

Guidelines

• Tailwind CSS - Core Concepts - Dark Mode https://tailwindcss.com/docs/dark-mode
• Theme toggle using Tailwind CSS in just 3 steps https://shreyvijayvargiya26.medium.com/theme-toggle-using-tailwind-css-in-just-3-steps-d92e1af6630d
• Learning Leptos: v0.1.0, cargo-leptos, & the World's Best Dark-Mode Toggle https://www.youtube.com/watch?v=AD3FHodVgE8

• add a hint how to install nodejs e.g. on Ubuntu 22.04 LTS

npm install
sh: 1: npm: not found
error: Recipe `install` failed on line 17 with exit code 127

• fix cookie file is by default in ~/.bitcoin/.cookie not .local/share/...

backend_bitcoin_core=BitcoinCore { auth: CookieFile("/root/.local/share/.bitcoin/.cookie"), root: "127.0.0.1:8332" }
thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })', src/backend/bitcoin_core.rs:53:78

first step of the dev setup should not require micro-services setup to see your nodes mempool

The scanner currently processes the blockchain from the tip backward until it hits the block that includes inscription 0. Since the scanner works with the raw blk and rev files bitcoin core needs to be turned off while it's running to prevent a race condition. Of course, this is not sufficient for operating a real-time explorer.

TODOs:

1. The processing of a single block needs to be refactored out into its own function. This should be pretty easy to do, take a look at ordilabs/bitcoin-scanner#12 where I extracted that code out into the worker as a starting point.
2. The raw file from disc processing should still be maintained and just use that function so that it can be used for spinning up new servers/services etc.
3. To continuously follow the latest blocks I would recommend using the zmq interface. When the scanner is integrated with that interface, it will be notified of new blocks coming in instantly and can process them right away. The only reasonable alternative would be long-polling the RPC interface but that would still mean that blocks would be processed slower than on other explorers and that doesn't sound great.
4. I am a bit unclear whether there is still an RPC integration needed as well. For example, raw file from disc sync is finished, the scanner stops. The bitcoin core node starts again. Once the bitcoin core node is started the scanner connects to the ZMQ interface. I am unsure whether this can be made robust enough that it can be sure that there is no block missed with this setup alone. I.e. maybe the node started already processing some blocks before the ZMQ connection to the scanner was finished. There doesn't seem to be a way to block core from downloading blocks before the ZMQ connection is established. So probably the scanner also needs the ability to request missed blocks via the RPC interface.
5. To accomplish the former but also the next item in the list, the scanner should be aware of which blocks it has scanned already. The inscriptions table has a genesis_height but that could be deceiving since there can also be blocks without an inscription.
6. The scanner should also be made reorg-robust. The seemingly simplest way to accomplish this should be: When a reorg happens just delete all the inscriptions that were in the reorged-out block (should be easy via genesis_height) and process the newly included block. Anything more complex seems unnecessary since reorgs are rare and it would maybe save 1-2 seconds at best.

Currently selected locale is stored in memory only. Persistent as same as we do it with theme: Via cookie (check #82, especially providers/theme.rs)

Solution from leptos-rs/leptos#1051 (comment)

Thanks for the explanation @gbj.

The latest wasm-bindgen and bleeding edge cargos-leptos worked for me without any Cargo.toml changes.

Commands:

• cargo install -f wasm-bindgen-cli
• cargo install --git https://github.com/leptos-rs/cargo-leptos --locked cargo-leptos

https://github.com/leptos-rs/cargo-leptos#site-parameters

https://www.phind.com/search?cache=45a8096b-653e-4d24-a6b5-3165722ca375

Takes a bit of work as alot was deprecated/changed
https://rust-bitcoin.org/blog/release-0.30.0/

During the server tick, when we discover that client.get_raw_mempool has less entries than our internal ordipool, we just assume that a new block was found and prune the entire ordipool. that is a slow process currently takes 15 seconds with ~35k transactions in the mempool.

The assumtion that a block was found when the #tx in the mempool goes down is flawed, as replace-by-fee (RBF) can invalidate a tx and it's children.

Also there exist probably more optimal ways to recreate the ordipool hashmap.

tick: bitcoin_core, 35024, 0, 35027, 504_304, 0
tick: bitcoin_core, 35028, 0, 35031, 496_436, 0
tick: bitcoin_core, 35028, 0, 35028, 16_401_797, 15_895_158
processed 31174/31250
tick: bitcoin_core, 31250, 0, 31174, 16_394_627, 15_960_592
tick: bitcoin_core, 31321, 0, 31322, 526_409, 0

Behavior:

• It seems like on every tick the inscriptions that are in the mempool are added to the website again, at least if there are no other inscriptions to show

How to reproduce:

• Run all services in the development environment
• Generate one punk
• Observe http://live-ol.local/ and wait

Compare

• cargo leptos serve
• cargo leptos serve --release

second one is broken

Put logic into app/functions/api + add Inscription data structure

TODO

• i18n provider in src/app/providers:
  • Func lang (current lang)
  • Func change_lang - handler to
  • const LANG (supported languages)
• Add combobox in header or footer to switch languages
• Add/update texts in app introduced in #123

Inspiration

• Discussion in Leptos Discord https://discord.com/channels/1031524867910148188/1031524868883218474/1077274572698701945 + https://discord.com/channels/1031524867910148188/1031524868883218474/1093024062458052678
• i18n in commonprayer https://github.com/gbj/commonprayer/blob/main/website3/commonprayer-site/src/i18n.rs
• Rust i18n libs to check:
  • fluent https://docs.rs/fluent/latest/fluent/
  • rust-i18n https://crates.io/crates/rust-i18n
  • ...

https://github.com/tokio-rs/axum

Using this commit 47dba3b
ran
just setup-once in project root