Indexer as a service. Proof of concept

With a good indexer (low-cost, complete, fast, …), there would be an opportunity to build a special Explorer, a Where-Used/What-Used Explorer. All (related) data can be visualised in one click, without any further explicit searching or other actions to get to the final result. Only further navigation is needed to get to the result. It can/will open the blockchain to the user… for now, the Classic Explorers are the only small windows (with limited visibility) to the blockchain for end-users. These Explorers need frequent input of search arguments and selections from the user, who needs to be aware of the structure and interaction of the blockchain data.

From each entry-point (account, action, address, date, status, token, transaction, …), each result is only a few steps away, completely linked together.
The special/specific user-interface should do the most of the remaining job… after indexing and scrambling, exploring within a dynamic grid (…,parents,root,children,…) and navigation on the edge of web-standards (COULD BE A REAL BLOCKING PROBLEM !!!).

Maybe not needed for all data (blocks, chunks, access_keys), but very useful for other specific data in an end-user context (accounts, wallets, balances, transactions, receipts, staking, history, collectibles, nft’s, tokens, dates, …).

As a result, NEAR would have a special blockchain explorer, with aspects of a personal organiser/wallet. Performance issues and web interface issues, but perfectly doable and it will open the blockchain to the end-user.
Aspects of personal organiser are memo’s, alerts, visual marks, duplicating and reordering, filtering , remembering navigation paths and more.
The user can organise his blockchain data and also other selected blockchain data in a way that helps him to better control his wallet.

Like a flat data file can have another dimension when imported in a spreadsheet, a filtered subset of a blockchain can better been displayed through a dynamic grid.

With a dynamic grid, I mean a grid that dynamically adds and removes columns and each column can display a hole filtered blockchain. The columns are dynamically created and linked per cell/item and the whole looks like an open book.

The book is virtually unlimited in size (cfr. blockchain), where each data-item/cell can become the root with his parents/grand-parents/… and children/grandchildren/… in a small configurable limited physical grid (from 7P > 3P/R/1C > 5C or the smallest grid with only 3 columns (3P > 2P/R > P/R/C > R/2C > 3C) where P=Parent Column, R=Root Column, C=Child Column. The grid scales/stretches differently in a Web page (7 columns or more), a mobile app (3 columns) or just 1 column if the wallet has lost it’s metadata. The last situation is comparable with the current “Recent Activity” backed by the Explorer via “View All”.

  1. Indexer as a Service.
  2. Scrambler as a Service.
  3. Dynamic Grid Explorer.
  4. Optional Organiser (with small local db needs).

I have included a simulation with really bad test data by means of 7 screenshots, that can simulate the grid navigation in a limited way.
The data is not really related, but just forced to be used as position fillers, to demonstrate the nature of the grid.
It would be much better with real data, because it’s all about the data. Because the data is so bad, it’s difficult to follow the dependancies/links by a first navigation. It just gives an impression of what I mean with a dynamic grid, a grid that generates the content of the next column for each individual selected cell/object. In the real grid every cell can become the next new root, with his parents/children and so, the navigation starts over without a limitation.

If you select one image, and then use the left and right arrows in a correct way (the left arrow, when going left until 3/green and the right arrow, when going to the right until 3/blue), you get an almost realistic simulation of the navigation.

The screenshots are not all very consistent, I mean they change the current selected cell in some cases (in the columns 1/green and 1/blue), this is not correct, but the result of making some mistakes/retries when taking the shots. And I was not willing to redo the previous shots. Its all about the global picture, don’t look at the details.