If a person were to read this after running pool.vet, what might a more experienced person conclude?
FAIL:Error reading extended metadata: invalid json response body at DP/extended_metadata.json at main · duckpuddle-us/DP · GitHub reason: Unexpected token < in JSON at position 6
It looks like the shortened url is pointed to a GitHub file. You need to point to the raw url instead.
https://raw.githubusercontent.com/duckpuddle-us/DP/main/extended_metadata.json
Thanks a bunch. That makes sense.
Seems it doesn’t like empty values like this:
"twitter_handle": "",
"telegram_handle": "",
"facebook_handle": "",
"youtube_handle": "",
"twitch_handle": "",
"discord_handle": "",
"github_handle": ""
I went through the process to change that url to the raw- redid the certificate etc. I have disappeared from pooltool.io and while I realize it takes time- typically changes I have made have shown up on pooltool pretty instantaneously. I run it on poolvet and can see that it is not working with updated info yet so I am not worried yet.
As for the pooltool.io should I be worried? (The changes were made earlier today.)
Thank you for your responses
You have metadata mismatch:
Are you sure that you entered correct HASH when re-registered your pool?
Additionally I would not recommend to use git for storing your extended-metadata. Every-time you will update extended-metadata, you will need new link(at least I didn’t figured it how to made it constant and short link). If you will update your metadata with new link to extended this will make hash incorrect. So this means that every time when you will update extended metadata you will need to re-register pool.
Actually yes- the url that is showing up in pooltool is the old one. Thats what leads me to suspect that particular issue may resolve as the changes take place. My assumption is not based on experience however. The issue of the pool disappearing on pooltool.io has me more concerned presently. If poolvet should be synced already then I may have another problem
It was not- I needed to make that change on the actual github file. (!) And now that all matches and pool.vet, so thank you very much- you had the right answer. Pool.vet is giving a clean bill of health, I am still puzzled about pooltool
I would like to add that, I personally find github not the best place for metadata. First you can’t get short link out of the box(sub 64 symbols). Because of this we will need to generate url by git.io, what I don’t know how long will store links, probably not forever, so this is another concern.
Additionally I was not able to make metadata file url(long one before we shorten it with git.io) constant(github or gist), every-time I updated some data, it created new commit and raw data had new link, so this lead to short link to not work and needed to generate new one. Or maybe I just don’t know how to do this.
All of this lead to a lot of complication in such simple process - uploading file to internet.
At the end I decided to go with S3. I pay 0 for it and it works flawlessly, with short URL straightaway, but there are some pitfalls too, so if you never used it, maybe it will not be the best choice.
And seems git.io do not accept new links to shorten, anymore 
Yes you definitely got me pointed in the right direction and I am pretty new to all of this- I marked the solution and extend my gratitude. Thanks, I discovered the git.io being out of business too. I will look at your idea as I progress.
Might anyone be able to suggest what I have missed with pooltool?
Extended metadata can handle empty or “” values without an error. But everything @os11k said about when changing the file changes the short link requiring an update to registered pool metadata hash is correct.
Seems pooltool.io do not like mismatched metadata, now when you fixed, it seems it works as expected. Or no?
The specific problem was that I ran a new registration certificate with the correct information so my air gap and bp had the goods. What I had not done was making the adjustment to the .json file which is stored on github. I made the change of a url in the the github instance of the file and it would appear everything is as it should be.
So the answer directly is yes, the mismatch was the problem.
I would like to add that with my .json file on github- the directions I read said to upload your new file- I do not upload a new file- I modify the existing one on github and commit the changes. The url appears to stay the same but I have modified the contents so they provide the correct hash. I do want to look at this S3 option for the future, thanks for the suggestion.
Thanks to all who helped.
