* fix(lidl): give createXpr services and newPrivateKey a LIDL type
logos-cpp-sdk#127 makes an unrecognised C++ spelling a build error
instead of silently publishing it as the opaque `any`, and two
declarations in plugin.h relied on that silence.
createXpr's `services` was `std::vector<std::pair<std::string,
std::string>>` — LIDL has no pair, so it published as `[any]`. The
pair's second element carries raw binary (it becomes a
ServiceInfoEntry's NimFfiBytes), but as a std::string it round-tripped
through UTF-8, which is lossy for non-UTF-8 bytes. It is now
`std::map<std::string, std::vector<uint8_t>>` — LIDL `{tstr: bstr}` —
which reaches the record byte for byte. decodeXpr's `services` becomes
an object keyed by service id to mirror it, so a decoded record feeds
back in without reshaping; `data` stays base64 there because that value
rides in an untyped `result`, not a typed slot.
newPrivateKey took `KeyScheme`, an enum, which LIDL also has no type
for. It now takes the scheme name — the vocabulary metadata.json
already documents for `keyType`, parsed the way parseTransport parses
"tcp"/"quic". The numeric KEY_SCHEME_* values belong to the Nim
binding and are no contract for a caller in another language.
decode_xpr now round-trips 0x01 0x00 0x02 0x80 0xfe 0xff 0x03 and
compares byte for byte, which is the lossiness this fixes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(lidl): keep the decoded-record services shape as it was
The previous commit also changed recordEntryToJson's `services` from
`[{id, data}]` to an object keyed by id, to mirror the map createXpr
now takes. That was wrong: recordEntryToJson serves discoLookup and
discoRandomLookup as well as decodeXpr, so it silently reshaped three
results, and tutorial 9 aborted iterating a lookup record —
`s["data"]` on what had become a bare base64 string throws
json type_error.305.
Keyed-by-id is also wrong on its own terms here. Lookup records come
from remote peers and may legitimately repeat a service id; an object
drops all but the last, while the array represents them faithfully.
createXpr's parameter stays `std::map<std::string,
std::vector<uint8_t>>` (`{tstr: bstr}`) — that is the typing fix and
the byte-exactness it buys, and it is unaffected. decode_xpr still
proves the round-trip, indexing the array instead of the object.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
vladopajic