{"op":"OpenTableDb","name":"local_records","column_count":1}
this will reply with a value key in it that you use as the db_id for poking at the opened table.
similar to how a RoutingContext gets used after doing NewRoutingContext
{"op":"TableDb","db_id":1,"db_op":"GetKeys","col":0}
These two things will cause it to dump... something or another.
I kind of expected them to be the IDs of the locally stored DHT keys.
but they aren't. unless they're encoded in some other way.
on my computer they all started with VkxEM
that VkxEM seems to be the start of a base64'd binary blob that starts out with "VLD0"
I guess the key names are stored pretty packed.
you can use
{"op":"TableDb","db_id":1,"db_op":"Load","col":0,"key":"VkxEMGYvVcQMfwj5iazODhWeOz5SVog5vgn4e7NZCaPOZe-B"}
to get back a base64'd blob of json about the key.
I figured out how the Keys can be decoded to the more common VLD0:[stuff] format.
deb64url the key, then skip the first 4 bytes, and enb64url the remaining bytes.
because the bytes might contain stupid stuff like nulls or newlines, using something like cut
on that data isn't reliable, so I use xxd to turn it into hex, then cut the hex.
it is in vld0-decode now.
$ vld0-decode <<< 'VkxEMGYvVcQMfwj5iazODhWeOz5SVog5vgn4e7NZCaPOZe-B' Zi9VxAx_CPmJrM4OFZ47PlJWiDm-Cfh7s1kJo85l74EK
combining all this crap I now have veilid-dht-list-local and veilid-dht-list-remote.
and I use this to see what all the keys are without having to open veilid-cli.
which is kind of handy I guess.
=> the commit with the stuff I'm talking about This content has been proxied by September (ba2dc).Proxy Information
text/gemini