lithp / turtlescan Goto Github PK

If you try to navigate right in the txs pane of a block that is empty, the tui crashes.

First step is to find somebody who would like to use this, I've never wanted to do this so I don't understand the use-case

termion makes it possible to receive mouse events, the difficult part will be mapping clicks to panes. When we draw we populate a structure which remembers the mapping from positions to panes? And what about scrolling, when you scroll should it scroll the pane which is currently focused or should it scroll the pane directly under the cursor?

this logic should be internal to the database, remove that method!

This would be neat :)

It doesn't appear geth serves this endpoint, which causes an unwrap on an Err value when navigating to the txs pane.

some columns, such as hashes, can easily consume more or less space. If there is more available terminal width why leave it empty? make the columns a little wider!

complications:

• what should the interaction look like? there's a third pane, the transaction inspector?
• what should be rendered, is it useful to show call traces?

raw addresses like 0x11bc..d08f are not very useful, at all. turtlescan would be much more useful if it had some kind of local or shared database of mappings from common addresses to names and annotations. Instead of seeing an address, you should see things like "Uni v2 WETH/BTC" or "Ethermine Coinbase".

In the same vein: ENS integration would also be dope.

technically turtlescan can work against infura but it does not at all rate-limit itself and I expect that infura would ban someone who actually tried it.

currently the blocks all scroll down but the selection stays fixed, which seems undesirable unless you want turtlescan to be in some kind of dashboard mode

the ui starts without any blocks selected which allows the user to get into a confusing state if they try to open the transactions pane or configure columns before selecting a block. This isn't a bug, exactly, but the rendered buffer is a little counter-intuitive.

alternative fix: make the rendered buffer more self-evident

Currently the list of blocks only shows you the most recent block, and doesn't allow you to scroll past the end. It would be nice to have a way of jumping to some desired part of the blockchain.

"j" should open some kind of popup, prompting you to enter an absolute or relative offset, and then scroll the viewport to the requested block

This likely depends on #2

• the user somehow specifies which pools they would like to watch, such as ETH/USDC
• when showing the block list do some eth_calls to figure out the price as of each block
• in the future, generalize this to any eth_call users might want to track the result of?

not important until #2 has been implemented

though, this doesn't sound particularly useful until some progress has been made on #13

currently only enabling and disabling them is supported

if you're running on the same machine as a (turbo)geth node there's no reason why you can't read data directly from their database. And if you're running on the same machine as a turbogeth node in particular you have access to a bunch more useful data such as account history.

currently turtlescan requires a websocket connection

turtlescan isn't very useful if you can't use it to watch the burn!

don't think this is a problem yet but it would be nice to find out right when it becomes a problem

If you're in the blocks view and you've selected the most recent block, hitting up-arrow enters "follow mode" where the selection always stays on the most recent block (you can leave follow mode by changing your selection in the blocks view)

A visual indication might be that there is no longer a cursor in the blocks view?

It's wasteful to make a request for each and every transaction, if it can be avoided

what would it mean to test any of this? e.g. what should happen when the provider gives us an error?

currently it's not obvious that everything is working as expected, that the block genuinely has no transactions

complication: how should configuration work? is the desired timezone to use to render dates with a global property?

currently tui only shows you the most recent blocks, that's not very useful!

one complication: what happens when new blocks come in while you've scrolled past the end of the list? it would be nice to have some kind of visual indication of how far from the chain tip the current viewport is.

Currently, viewing the txns for a big block clogs the request queue with requests for receipts the user might never want to see.

this is a problem for windows which are not tall enough to render all transaction details

if you're quickly scrolling through pages then the things currently on the screen are far more important than anything else. maybe we want a priority queue with updatable priorities or maybe we want to be able to cancel stale requests

when a reorg happens the subscription gives us all new blocks. currently the tui treats these blocks as if they're all additions to the chain tip but in fact some of them ought to rewrite previous blocks

Look in run_sled