Documentation is not Accurate about amoveo

[zack-bitcoin]

If your oracle ID is base64 encoded, then the API cannot accept it.
This is not a mistake.

[Sykh]

To be fair the documentation is pretty useless then since all oracle ids you can see in the lightnode or the explorers are base64 encoded, i dont think there is any place you actually get a decoded id except the node on oracle creation which also trims that output since its too long.

So the documentation should be updated to a useable command or cover both cases or better yet, update the functions so they base64:decode themself like the curl api calls do...

[zack-bitcoin]

There are hundreds of places in the code where I would have to check the input and possibly decode base64.
I think the solution is to add oracle_close capabilities to the light node.

[zack-bitcoin]

And we need to test everything for the full range of inputs, so this would involve doubling the number of tests.

duck typing is a lot of work, we should only use it if we need it.

[zack-bitcoin]

The full node doesn't accept base64 encoded pubkeys to send veo either.
It is consistent in the format that it expects.

[Sykh]

This is logical for you since you know the source and that is what you are working with but users reading the documentation wont get far with it, like ben said, you copy paste the command and yes, it doesn't work so the documentation is wrong there since it's a user documentation, not the api.

I agree on the lightnode part, the fullnode should be needed and used as little as possible.

[zack-bitcoin]

If Ben regularly used the full node, this wouldn't matter.
I think he set up a full node just to close an oracle and nothing else.
He is a light node user, and needs to be able to do this from the light node.

[jadefalke]

I think the Documentation should empower everyone who wants it to use the Full node. Otherwise the Documentation is useless.

[zack-bitcoin]

there is no more "base64" on that page, so I guess this was solved.