In Python, it is fine to have bytes (buffer in JS), or integers, as keys for dictionaries (object in JS).
The current implementation in JS, which somehow serves as spec, insists on object keys being strings (lines 120 and 121 of index.js):
// JavaScript only allows string-valued and Symbol keys for objects
if (tag & TAG_MASK) throw new Error('required type:string')
Maybe this is not meant to be a restriction of BIPF - just a JS-specific precaution. Then this GitHub issue is void.
Otherwise, I suggest to not have this restriction being part of the BIPF spec in order to let other languages use BIPF for data struct serialization. The spec should enumerate the allowed key types: string, int, buffer/bytes, bool and even null can make sense in some programming language (while having arrays or objects as keys is more doubtful and needs more thoughts before allowing them in a spec).
In order to let JS handle incoming "buffer keys", a convention could be adopted for JS land, for example that buffer keys are automatically converted to strings, using base64 or similar.
Note: I do not advocate that objects with buffer keys are used in any SSB public data structure. But I want to use BIPF also for serializing internal Python data structures, instead of having to add redundant serialization libraries (CBOR etc). The quite ubiquitious use case in my code are dictionaries (that I persist) whose keys are feed IDs, which I keep in binary format throughout the implementation for space and comparison speed reasons.
This is good input. In JavaScript we now have map that can store any value as key. I'm thinking of doing a proper spec of bipf as I need to go a bit deeper on the api anyway in order to support more efficient encoding.
In Python, it is fine to have bytes (buffer in JS), or integers, as keys for dictionaries (object in JS).
The current implementation in JS, which somehow serves as spec, insists on object keys being strings (lines 120 and 121 of index.js):
Maybe this is not meant to be a restriction of BIPF - just a JS-specific precaution. Then this GitHub issue is void.
Otherwise, I suggest to not have this restriction being part of the BIPF spec in order to let other languages use BIPF for data struct serialization. The spec should enumerate the allowed key types: string, int, buffer/bytes, bool and even null can make sense in some programming language (while having arrays or objects as keys is more doubtful and needs more thoughts before allowing them in a spec).
In order to let JS handle incoming "buffer keys", a convention could be adopted for JS land, for example that buffer keys are automatically converted to strings, using base64 or similar.
Note: I do not advocate that objects with buffer keys are used in any SSB public data structure. But I want to use BIPF also for serializing internal Python data structures, instead of having to add redundant serialization libraries (CBOR etc). The quite ubiquitious use case in my code are dictionaries (that I persist) whose keys are feed IDs, which I keep in binary format throughout the implementation for space and comparison speed reasons.