Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add BARE Message Encoding #306

Closed
wants to merge 1 commit into from
Closed

Add BARE Message Encoding #306

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions table.csv
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 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?

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Techcable : are you able to incorporate feedback here so we can get this merged? Thanks!

libp2p-peer-record, libp2p, 0x0301, permanent, libp2p peer record type
libp2p-relay-rsvp, libp2p, 0x0302, permanent, libp2p relay reservation voucher
memorytransport, libp2p, 0x0309, permanent, in memory transport for self-dialing and testing; arbitrary
Expand Down