-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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
fix: role.fromIndex should be +ve integer #161
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,5 +14,5 @@ message Role_1 { | |
Common_1 common = 1; | ||
|
||
bytes roleId = 5; | ||
int32 fromIndex = 6; | ||
uint32 fromIndex = 6; | ||
} |
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should update the proto to use
uint32
instead...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, makes sense. It increases the max supported number of records in a hypercore. Is 2^32 records per hypercore per device enough? since this currently refers to the index of the auth cores, that seems enough, but I've also been thinking of adding a
fromIndex
for other cores, so that peers could choose not to index a particular peer beyondfromIndex
. I can see it's feasible that a blob core could have > 2^32 records, because blobs are chunked into 64kb. So maybe just make them all uint64?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know enough to make a decision here.
If each chunk is exactly 64 kilobytes, then I think
uint32
is fine. 64 bytes × 1000 × 232 = 274877906944000 bytes = = ~275 terabytes.1If chunks could be 1 byte, then that only allows about 4.3 gigabytes, which feels a little restrictive, and we might want to use
uint64
.We should keep in mind that 64-bit integers don't fit in JavaScript numbers. It looks like ts-proto uses a custom
Long
class by default, but we can make it use bigints with--ts_proto_opt=forceLong=bigint
. Not sure if that affects anything else, such as JSON serialization.In any case, I think this is best done in a followup.
Footnotes
This assumes a kilobyte is 1000 bytes instead of 1024, which is more conservative in this case. ↩
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok also sanity-checking number of records, OSM currently has about 8 billion nodes and 1 billion ways. With a uint32 we would be limited to about 4 billion records in a single hypercore, so it wouldn't be possible to import the entire OSM db into a single hypercore, but that would probably be a bad idea anyway. Anyway this is just a limit for evaluating capabilities, only really relevant with self-created data, so I think the limits are fine.