Add BARE Message Encoding #306
Conversation
BARE stands for Binary Application Record Encoding. See https://baremessages.org for more details. Registered as a draft RFC: https://datatracker.ietf.org/doc/draft-devault-bare/
| @@ -133,6 +133,7 @@ swhid-1-snp, ipld, 0x01f0, draft, SoftW | |||
| json, ipld, 0x0200, permanent, JSON (UTF-8-encoded) | |||
| messagepack, serialization, 0x0201, draft, MessagePack | |||
| car, serialization, 0x0202, draft, Content Addressable aRchive (CAR) | |||
| bare, ipld, 0x0203, draft, Binary Application Record Encoding (BARE) | |||
There was a problem hiding this comment.
The tag should be serialization as by default it doesn't support links (CIDs). After a quick look, I've seen that BARE supports user defined types. Would the plan be to specify a user defined type for CID?
There was a problem hiding this comment.
Yes. If the user wants CIDs, it would be very straightforward to define one.
Because BARE is not self-describing, user-defined types have no overhead and are no different than builtins.
I see json marked ipld on line 133, but the official JSON RFC(s) don't specify support links. Is this possibly a mistake, confused with dag-json?
There was a problem hiding this comment.
Yes. If the user wants CIDs, it would be very straightforward to define one.
Should then perhaps the information about which one to use be defined somewhere?
I see
jsonmarkedipldon line 133, but the official JSON RFC(s) don't specify support links. Is this possibly a mistake, confused withdag-json?
json (and others) should really be serialization, it just grown historically. We even still haven't it properly written down what qualifies an ipld codec.. No one took the time to look over the whole table and make the call. Though I'd like to get it "as right as possible" for new additions.
What emerged over the past few months (I also touch it a bit at #204 (comment)) is: The codec field in CIDs is about "how do I process this data in order to get links/CIDs out". And currently I see the ipld tag as codes that qualify for that.
There was a problem hiding this comment.
@Techcable the current position is something like this - if a serialization format doesn't potentially emit a Link (CID) type then we're calling it a serialization, but if it does emit Links and therefore allow us to form a graph of connected blocks then we're calling it ipld. The existing entries that are ipld that don't match this are historical and we're probably going to change that. So for now this would be appropriate to be serialization. If you could change that we can probably merge it.
There was a problem hiding this comment.
@Techcable : are you able to incorporate feedback here so we can get this merged? Thanks!
|
@Techcable : closing for now, but feel free to reopen if you still want to pursue this (and incorporate the feedback). Thanks! |
BARE stands for Binary Application Record Encoding.
See https://baremessages.org for more details.
Registered as a draft RFC: https://datatracker.ietf.org/doc/draft-devault-bare/