ipni / cid.contact Goto Github PK

the /cid/bafybeidbjeqjovk2zdwh2dngy7tckid7l7qab5wivw2v5es4gphqxvsqqu endpoint returns 3 entries: 2 graphsync and one bitswap.

when using the web ux and searching for bafybeidbjeqjovk2zdwh2dngy7tckid7l7qab5wivw2v5es4gphqxvsqqu you only see the bitswap entry rendered.

Example:
bafy2bzacebc3bt6cedhoyw34drrmjvazhu4oj25er2ebk4u445pzycvq4ta4a

From the cid.contact website I get this which seems to indicate dag-house is running graphsync, which last I checked wasn't the case.

curling the routing/v1 endpoint shows only Bitswap from /dns4/elastic.dag.house/tcp/443/wss
curling the /cid endpoint seems to also only show bitswap (although it shows the many IPNI internal duplicate records)

I don’t see garaphsync metadata listed in json response under daghouse :
$ curl https://cid.contact/cid/bafy2bzacebc3bt6cedhoyw34drrmjvazhu4oj25er2ebk4u445pzycvq4ta4a | jq -c '.MultihashResults[].ProviderResults[] | select(.Metadata | length > 4) | select(.Provider.Addrs[] | contains("dag"))'
There are, however, providers for that CID over graphsync it seems:
$ curl https://cid.contact/cid/bafy2bzacebc3bt6cedhoyw34drrmjvazhu4oj25er2ebk4u445pzycvq4ta4a | jq -c '.MultihashResults[].ProviderResults[] | select(.Metadata | length > 4).Provider.Addrs | unique'
If I have not missed anything this looks like a bug in cid.contact web UI.

Update to #ipni slack channel.

The current status page use UptimeRobot, which periodically checks a fixed endpoint and allows us to set ad-hoc announcements. But it does not show the history of ad-hoc announcements once they are resolved.

Ideally, the status page should:

• show the history of all announcements set as type issue.
• change the all green to yellow during issue announcement.
• allow us to set status per component.

FileCoin uses Atlassian status page. Look and see if we have access to that and see if it makes sense to switch.

The total number of CIDs indexed fluctuates based on which backend serving stats. The calculation itself is dependant on the datastore used to store information: not all KV stores offer accurate count of unique keys due to performance reasons. A solution needs to be specifically designed to keep track of unique CIDs indexed that at the same time does not impact the ingest throughput due to locking etc.

An example of such solution is to keep atomically incremented numbers based on CID prefix, then periodically aggregate them to get a total.

In the meantime, remove the count from the landing page to avoid confusion.

Cc @TorfinnOlsen

Status page is now moved to Atlassian StatusPage, which allows a set of automations and metrics. Add automation for changing status based on metrics that correctly reflect the state of cid.contact.

See: https://developer.statuspage.io/

Using CID for testing: bafybeihnb7pf32arwdvzmlht24n6jf3362jjgobbwex7delf5ya2eompc4

1. Using anything but indexer CID Contact from the first query fails
2. keeping the CID the same when using CID Contact as the first query and then switching to another indexer fails
3. Switching to SXX and even other from #2 will cause
   Application error: a client-side exception has occurred (see the browser console for more information).

Use alternative free software to host documentation as a result of gitbook pricing increase, such as: https://docusaurus.io