When I go to page like https://indyscan.io/tx/sovstaging/domain/81042
and I double click on value of roothash on the transaction data overview on top of the page, it automatically selects RootHashGcfRRVeMC4AZHuWrU27anqNNRCrQpXnYqT8EjocF758i isntead of GcfRRVeMC4AZHuWrU27anqNNRCrQpXnYqT8EjocF758i, which is what you usually want.

App idea:

• listen on indyscan-daemon websockets
• send slack notification / generic webhook call if pre-configured parameters are met
• there would have to be some sort of UI which would enable users to configure their notifications criteria
• assuming we would properly expose indyscan-daemon websockets, this service could be self-hosted by its users (eg listen to wss://indyscan.io/SOVRIN_MAINNET from self hosted server running this notification app), so no need to implement authentication in the first iteration

Marking as good first issue, as this can be done pretty much without knowledge of the existing codebase. I am sure this would be handy feature for number of people/companies.

The "Indyscan" in the top left corner should be clickable, redirecting user to home page of currently selected network

The URL for lib sodium-1.0.14.tar.gz has changed, it now needs old/unsupported in the URL.

Here is the fix I used to solve this. You might like to use it instead of staying on 1.0.14, which the lib sodium authors would apparently prefer you did not do. :)

diff --git a/ubuntu-libindy/Dockerfile b/ubuntu-libindy/Dockerfile
index 7d11562..157ef97 100644
--- a/ubuntu-libindy/Dockerfile
+++ b/ubuntu-libindy/Dockerfile
@@ -39,12 +39,12 @@ RUN pip3 install -U \
 	deb-pkg-tools
 
 RUN cd /tmp && \
-   curl https://download.libsodium.org/libsodium/releases/old/libsodium-1.0.14.tar.gz | tar -xz && \
-    cd /tmp/libsodium-1.0.14 && \
+   curl https://download.libsodium.org/libsodium/releases/LATEST.tar.gz | tar -xz && \
+    cd /tmp/libsodium-* && \
     ./configure --disable-shared && \
     make && \
     make install && \
-    rm -rf /tmp/libsodium-1.0.14
+    rm -rf /tmp/libsodium-*
 
 RUN apt-get update && apt-get install openjdk-8-jdk -y
 ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64

In version 3.0, I didn't migrate AWS terraform module which was present in 2.2.1

• Implement AWS module to deploy Indypool with Indyscan to a EC2 instance.
• You can probably largely reuse the module from 2.2.1 https://github.com/Patrik-Stas/indyscan/tree/2.2.1/start-aws but you will have to tweak it to get it working with 3.0.0 (different configuration format for the daemon mostly)

I would like to contribute some aggregations and views into indyscan. How can I contribute?

In version 3.0.0 was removed Stats section. It would be nice to restore it again. This would mean

• pick some UI visualization framework integrating well with react
• implement endpoints on API necessary to request the data visualized data. It would be cool if filters and searches could be applied against this data, just as it's possible on the `
• add stats section and visualize number of transactions over time

If you start working on this task, please keep me updated with your decisions and progress (like what UI library you want to use etc. or your own ideas you want to implement)

Hello,
I would like to set up indyscan for a Hyperleder Indy network that I have set up. Are the custom deployment steps documented somewhere more clearly for layman :). It would be big help.

On the page displaying list of transactions (here https://indyscan.io/txs/sovstaging/domain) add date range selection. I think it might be nice to reuse this react module https://www.npmjs.com/package/react-date-range

Good day! Have a strange problem - I deployed indyscan to VM, connected to existing indy networks (on other VMs). All is working, after open port 3707 on VM can access transaction explorer in browser.
But when I restrict access to 3707 port on VM only from my IP using Azure NSG rule, I get in browser endless loading page instead of transaction explorer. This is repeated when setting any restrictions on incoming traffic on port 3707

If verkey was abbreaviated on NYM or ATTRIB tx, fullVerkey in expansion is simply concatentaion of the did and verkey. Whereas correct value is calculated as follows here:
https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/utils/crypto/verkey_builder.rs

Just curious, why did you use mongodb? We can fetch the transactions directly from the ledger right?

The docs say I should be able to run "node genesis.js" to setup the genesis blocks, but I cannot find that script.

There's a "genesis" target in indyscan-daemon, so I could type "npm run genesis", but no genesis.js file.

Hello!

I hope you are doing well!

We are a security research team. Our tool automatically detected a vulnerability in this repository. We want to disclose it responsibly. GitHub has a feature called Private vulnerability reporting, which enables security research to privately disclose a vulnerability. Unfortunately, it is not enabled for this repository.

Can you enable it, so that we can report it?

Thanks in advance!

PS: you can read about how to enable private vulnerability reporting here: https://docs.github.com/en/code-security/security-advisories/repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository

https://indyscan.io/ doesn't look great on phones. If you can optimize it for mobile, that would be wonderful!

If I am currently viewing list of domain transactions for Mainnet (here https://indyscan.io/txs/sovmain/domain) and then click "StagingNet", it redirects me to homepage for StagingNet (herehttps://indyscan.io/home/sovstaging) . It should redirect to domain transactions view for StagingNet instead (here https://indyscan.io/txs/sovstaging/domain).

It should probably not go deeper than that though. If I am viewing a specific transaction on MainNet (like https://indyscan.io/tx/sovmain/domain/54014) and click "StagingNet", it should still get me just to https://indyscan.io/txs/sovstaging/domain, not a specific StagingNet domain transaction.

It would be useful to be able to look at transactions on the payments/token ledger of Sovrin, i.e. ledger id = 1001.

Are you already working on this? Would you be open to a PR?

While debugging situation with one of nodes on BuilderNet I've found that transaction time as written in logs and as shown on indyscan.io differs by 3 hours - and I'm in a UTC+3 timezone actually. I tried to change local timezone and indyscan.io showed yet another timestamps, which confirmed that it actually shows local time. This is weird, because column header states that it is Timestamp UTC. So, either column header should be changed to Local Timestamp, or (preferably from my PoV) timestamps should really be shown in UTC.

BTW, thanks for building and maintaining this project, it already helped debugging network issues several times.

Add the radar icon https://github.com/Patrik-Stas/indyscan/blob/master/indyscan-webapp/static/radar.png next to "Indyscan" in the top left corner of the page

• Plan out the structure of the Indyscan 4.0.0 daemon
• Example daemon 4.0.0 configuration

We've been trying to remove the term "CLAIM_DEF" in favour of "CRED_DEF" for quite awhile. While I realize it is still in some of the Indy code, it would be nice to banish the term in public places. IndyScan is the most of public of places for Indy Networks, so it would be really nice to have the label changed to the more appropriate "CRED_DEF".

In the work we are doing in creating the specification for AnonCreds (here: https://anoncreds-wg.github.io/anoncreds-spec/) we are only using the term "CRED_DEF", with a note that in some places in the code it is "CLAIM_DEF".

Thanks!

IndyPool + IndyScan on localhost

Description

indyscan-daemon exits and restarts

» docker ps                                            

CONTAINER ID   IMAGE                                                        COMMAND                  CREATED          STATUS                        PORTS                                            NAMES
f61931cbe3f2   pstas/indyscan-daemon:4.1.0                                  "/bin/sh -c 'npm run…"   14 minutes ago   Restarting (1) 1 second ago                                                    indyscan-daemon
46855b570c89   docker.elastic.co/kibana/kibana:7.15.2-arm64                 "/bin/tini -- /usr/l…"   14 minutes ago   Up 11 minutes                 0.0.0.0:5601->5601/tcp                           indyscan-kibana
0cd055888f65   docker.elastic.co/elasticsearch/elasticsearch:7.15.2-arm64   "/bin/tini -- /usr/l…"   14 minutes ago   Up 11 minutes                 0.0.0.0:9200->9200/tcp, 0.0.0.0:9300->9300/tcp   indyscan-elasticsearch
2bb423df5f2f   pstas/indypool:indyscanpool-v1.15.0                          "/usr/bin/supervisord"   59 minutes ago   Up 11 minutes                 0.0.0.0:9701-9708->9701-9708/tcp                 indyscanpool
812460bf881f   pstas/indyscan-api:4.1.0                                     "docker-entrypoint.s…"   59 minutes ago   Up 11 minutes                 0.0.0.0:3708->3708/tcp                           indyscan-api
d864baf5eddd   pstas/indyscan-webapp:4.1.0                                  "docker-entrypoint.s…"   59 minutes ago   Up 11 minutes                 0.0.0.0:3707->3707/tcp                           indyscan-webapp
0129826a65b2   pstas/indyscan-daemon-ui:4.1.0                               "/bin/sh -c 'npm run…"   59 minutes ago   Up 11 minutes                 0.0.0.0:3710->3710/tcp                           indyscan-daemon-ui

Steps to reproduce:

Follow instructions for IndyPool + IndyScan on localhost

• used current images for elastic-search and kibana
• run ./init-local.sh
• create entry in /etc/hosts
• start docker containers using make up

Expected result

all instances running, indyscan connects to local indyscan-pool and web-ui is accessible

Actual result

indyscan-daemon           | 
indyscan-daemon           | > [email protected] start /home/indyscan/indyscan-daemon
indyscan-daemon           | > cross-env NODE_ENV=production node ./src/index.js
indyscan-daemon           | 
indyscan-daemon           | Loaded configuration: {
indyscan-daemon           |   "LOG_LEVEL": "info",
indyscan-daemon           |   "WORKER_CONFIGS": "/home/indyscan/indyscan-daemon/app-configs-docker/INDYSCANPOOL.json",
indyscan-daemon           |   "SERVER_ENABLED": "true",
indyscan-daemon           |   "LOG_HTTP_REQUESTS": "true",
indyscan-daemon           |   "LOG_HTTP_RESPONSES": "true",
indyscan-daemon           |   "SERVER_PORT": "3709",
indyscan-daemon           |   "AUTOSTART": "true",
indyscan-daemon           |   "ENABLE_LOGFILES": "false"
indyscan-daemon           | }
indyscan-daemon           | 2021-11-12T16:13:34.200Z [--] info: Will bootstrap app from following operations definitions [
indyscan-daemon           |   "/home/indyscan/indyscan-daemon/app-configs-docker/INDYSCANPOOL.json"
indyscan-daemon           | ]
indyscan-daemon           | 2021-11-12T16:13:34.228Z [--] info: Going to build workers by rtwSerialization from {"indyNetworkId":"INDYSCANPOOL","genesisPath":"/home/indyscan/indyscan-daemon/app-configs-docker/genesis/INDYSCANPOOL.txn","esIndex":"txs-indyscanpool","esUrl":"http://indyscan-elasticsearch.esnet:9200","workerTiming":"FAST"}
indyscan-daemon           | 2021-11-12T16:13:34.260Z [--] info: Connecting to ledger INDYSCANPOOL.
indyscan-daemon           | Operation not permitted (src/thread.cpp:122)
indyscan-daemon           | qemu: uncaught target signal 6 (Aborted) - core dumped
indyscan-daemon           | npm ERR! code ELIFECYCLE
indyscan-daemon           | npm ERR! errno 1
indyscan-daemon           | npm ERR! [email protected] start: `cross-env NODE_ENV=production node ./src/index.js`
indyscan-daemon           | npm ERR! Exit status 1
indyscan-daemon           | npm ERR! 
indyscan-daemon           | npm ERR! Failed at the [email protected] start script.
indyscan-daemon           | npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
indyscan-daemon           | 
indyscan-daemon           | npm ERR! A complete log of this run can be found in:
indyscan-daemon           | npm ERR!     /home/indyscan/.npm/_logs/2021-11-12T16_13_34_351Z-debug.log
indyscan-daemon exited with code 1

Environment

• macOS 12.0.1
• Processor: Apple M1 Pro
• Docker Desktop 4.1.1 (8GB RAM, 4CPUs)

Thanks for writing this! I am currently experimenting with the code and my computer crashed a few times because I was multitasking while doing so. I ran some tests in isolation and I just wanted to ask you if you are aware how resource-intensive the build command is ./build-all.sh. I'm running Ubuntu 16.04 with an i5-5300U and it is maxing out all 4 cores of my CPU. Granted its a modest machine but is this behavior expected? Is most of this build process being eaten up by the webapp as opposed to the daemon?