feat: (BREAKING CHANGE) new record definition

[vasco-santos]

PR for having the libp2p-record protobuf definition compliant with go-libp2p-record.

At first, go-libp2p-record was compliant with this. However, in the meantime it was changed in the following commits:

• go-libp2p-record/commit/1c075e0108b178f30857ca532ecf1202388cbde6#diff-54fa770b67867a8d12468f7a9237c6f1
• go-libp2p-record/commit/a3d01a3eec21dfeacf5d493b40470978631b71ee#diff-54fa770b67867a8d12468f7a9237c6f1

All in all, author and signature were removed, as well as all the logic inherent to the signature.

Note: this is a breaking change

[vasco-santos]

cc @jacobheun @diasdavid

(Don't know why, but I do not have permissions for requesting review in here)

[jacobheun]

The right teams probably weren't added to the repo. @libp2p/dx can you make sure the right teams are added to this repo?

[victorb]

Team @libp2p/javascript-team has been added with write perrmission. Hope that helps!

[jacobheun]

Is there are reason for keeping these lines in here? People can always use git history to look up the changes.

[vasco-santos]

Well, I personally left them as a reason for keeping timeReceived with identifier 5.

optional string timeReceived = 5

In go side, they removed it first, but then reverted to comment it.

[jacobheun]

Bah, okay, fair enough.

[jacobheun]

Since this is a breaking change, do we know what the impact of this is on js-ipfs since it's the primary package level consumer downstream?

[vasco-santos]

We will need to go through every single module using this module and:

• change the constructor to the new one
• remove all the logic using the record signatures

I think that in this case, it is better to create the breaking change instead of maintaining all the current logic and just change the logic here, as we would have unexpected behaviors from what consumers expect.

Here is the list of the modules using this:

https://www.npmjs.com/package/libp2p-record

Two of those modules are already deprecated, so we will only have to modify 3 of them

[jacobheun]

Yeah, I agree, and this looks good.

[vmx]

The commit message format doesn't really conform to the JS Guidelines. The "breaking change" information should not be in the header (though it could be I guess), but there should be a section in the body.

The section from the body will then also show up in the changelog, which I think is important. The commit message should contain all the information on what this breaking change is about and how you need to change your code. A good start is already the original pull request message.

[vasco-santos]

Thanks @vmx

I will add to the commit message body the breaking change information, when merging it.