Questions about node api

2Questions. 1)


i cannot find the explanation of the body param

Subscriber id

what is that ?

JSON schemas

at the atom model schema

we have the following example

            "hid": ":uid:038719d2c71985f5ca02a73368514a10",
            "metaData": {

that hid value, is that the AID ?

Hey, this is an answer from our devs:

  1. The “subscriberId” parameter is a client provided unique identifier that is used to control the subscription. It’s supplied in the subscription, and needs to match when cancelling a subscription. Notifications from the node will have a matching “subscriberId” parameter when responding to this subscription.

  2. In this case it looks like our example has not been updated to match the new AID, and it does not appear in the included JSON. The HID (Hash ID) is still included, and is a 128-bit truncated hash value. The AID is a 256-bit value.

Hope this helps!

A bit. Thanks for your help.

However i’ve got an issue with understanding how the java client serializes it’s atom object.
In the “radixdlt-java/src/main/java/com/radixdlt/client/core/atoms/” class i cannot find a EUID object representing the so called HID. And the only function for a AID is getAID wich does not seem to be called by the serializer. (maybe i missed it)

Also in the javascript lib “src/modules/atommodel/atom/RadixAtom.ts”
We have a getAid, but i cannot find a UID. If i look at the config files of the latest branch i find the following.

“genesis”: [
“metaData”: {
“timestamp”: “:str:1551225600000”
“shards”: [
“hid”: “:uid:f9df5a6574bcbef6df9a2ad80f90e79b”,
“serializer”: “radix.atom”,

So it clearly has a UID, but not a AID. Needless to say, I am confused with the differences i see in the documentation, code and json output.

FYI, i do not run or debug any of the clients. I am just looking at the code as a way for me to learn.
(this will help me build a client of my own)
Thank you for any further help

Hi Jonas,

The API docs are out of date, for atoms the HID has been replaced by the AID. If you want to see an up to date json, I would recommend looking at a universe radixdlt-java/betanet.json at release/1.0.0-beta · radixdlt/radixdlt-java · GitHub (It looks like the universes in radixdlt-js haven’t been updated to the latest version)

Anyway, there are slight differences in how the serializer is implemented in the core, and in the libs. The HID(and the AID for atoms) is a fully computed property, that can be computed for any Radix object, so it’s not necessary to include it in the serializer output. The core however does for debug reasons, the libraries just ignore it.

The serialisation to JSON is pretty permissive, you only need to be very strict about it when serializing to DSON for computing a hash. In that case, you obviously cannot include the HID or the AID, since you need the hash to compute the HID, which would lead to an infinite regression.

Thank you edgars. Understood, beta.json is usefull. however like you said. formatting is extremely important for creating a correct hash. example, to create a HID for a particle i need to use the dson format to compute a hash.
This also means i really need to have a full understanding how to communicate in DSON.

Any eta for a up to date node api doc?

The description of the DSON format here is fully accurate

The other part of it are the list of properties to include for each type of an object - none of the JSON output examples are a good reference for this, as the set of properties for hashing is different from what needs to be sent over the wire.

The best place to figure this out from currently is the actual code of any of the libraries, in JS look for the @includeDSON decorator radixdlt-js/src/modules/atommodel at release/betanet · radixdlt/radixdlt-js · GitHub
In Java, it’s @DsonOutput(DsonOutput.Output.ALL) with at least HASH output level
radixdlt-java/ at release/1.0.0-beta · radixdlt/radixdlt-java · GitHub

As an aside, all of the libraries currently can only encode to DSON, not decode, as it is not used for any communication, just for hashing.

In general, the code will always be the most up-to-date resource, as we just have to move quickly at this stage. As we’re getting closer to launch, more and more things will be set in stone and documented in more detail, but a higher priority is building out our own libraries and ensuring they are documented, as the immediate benefit to our users is a lot higher there, the node API comes after that, but we should have a more solid set of docs for that sometime before launch.