Add Base8 Spec #60
Merged
Add Base8 Spec #60
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Stebalien
requested changes
Nov 16, 2019
hugomrdias
added a commit
to multiformats/js-multibase
that referenced
this pull request
Jun 3, 2020
- adds support for all the encoding in https://github.com/multiformats/multibase/blob/master/multibase.csv - better errors showing the invalid chars and inputs - `names` and `codes` export the full object that maps names/codes to base instances - two news methods exported, `encoding` and `encodingFromData` - added all the spec tests https://github.com/multiformats/multibase/tree/master/tests This module now only uses 2 base encoding implementations, 1 generalised rfc4648 and 1 generalised btc like. Note: `base8` deviates from the spec tests outputs but aligns with multiformats/multibase#60
fabianhjr
force-pushed
the
add-base8-spec
branch
4 times, most recently
from
0813aaf to
e88ecae
Compare
ribasushi
reviewed
Jun 4, 2020
There was a problem hiding this comment.
@fabianhjr so far so good! Can we add a ## Decoding section as well? Feel free to liberally C/P from the 4648 spec. Also won't hurt to link to it: https://tools.ietf.org/html/rfc4648
|
@hugomrdias when time permits can you check that the spec-as-written makes sense? You were the last to implement stuff in this area... |
|
I think it would be best to wait until the encoding is a go before trying to spec the decoding. As far as I know this encoding would fit what was implemented in multibase-js however will wait for @hugomrdias. |
hugomrdias
approved these changes
Jun 7, 2020
|
Thanks @hugomrdias. The decoding section has been added @ribasushi. |
hugomrdias
requested changes
Jun 7, 2020
hugomrdias
approved these changes
Jun 7, 2020
Stebalien
approved these changes
Jun 9, 2020
|
Hi @Stebalien, I think this is ready to be merged. UwU |
|
🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a first throw at specifying a Base8 encoding, solves some issues of #59 and multiformats/go-multibase#26
Currently the test vectors mapped to the octal value of each byte so encoding and decoding would be harder than need be and encoded bytearray values would be larger (if each byte is mapped to 3 chars) or unpredictable (if, as currently, there are some chars encoded to different octal lengths)
For example, the first test vector was:
(In chunks of 3)
["104","312","615","453","347","216","230","266","151","364","624","403","127","314","534","474","564","320","645","563","162","044","1"](In chunks of 8)
["10431261","54533472","16230266","15136462","44031273","14534474","56432064","55631620","441"]And
312seems to be the encoding ofesometimes in some places likeposition ≡ {1,2} mod 3.