You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.
As part of my PR ipfs/kubo#6012 go-ipfs will be encoding key's names into base32 in order to unify behavior across all platforms (case sensitivity). As a small bonus because of it, it will be able to use any characters for the key's names (like namespacing for example "websites/some-website").
I assume that since js-ipfs has a goal to have interoperable repositories with go-ipfs, this behavior should be propagated from go-ipfs to js-ipfs as well.
I am happy to provide PR for js-ipfs as well.
I have a few questions.
Is this desired from your side? Will you accept the PR?
My idea of implementation of it would be to create something like EncodedDatastore wrapper that would be used in js-ipfs-repo for the keys property and would do the translation from/to base32.
I believe the base32 encoding won't be necessary for the datastore-level, should I hardwire exception for it or also encode it?
The text was updated successfully, but these errors were encountered:
But I am actually working on migration tool here: https://github.com/AuHau/js-ipfs-repo-migrations and this will be first demonstration migration. Hopefully next week I should have first version for review.
Type: Enhacement
Description:
As part of my PR ipfs/kubo#6012 go-ipfs will be encoding key's names into base32 in order to unify behavior across all platforms (case sensitivity). As a small bonus because of it, it will be able to use any characters for the key's names (like namespacing for example "websites/some-website").
I assume that since js-ipfs has a goal to have interoperable repositories with go-ipfs, this behavior should be propagated from go-ipfs to js-ipfs as well.
I am happy to provide PR for js-ipfs as well.
I have a few questions.
Is this desired from your side? Will you accept the PR?
My idea of implementation of it would be to create something like
EncodedDatastore
wrapper that would be used injs-ipfs-repo
for thekeys
property and would do the translation from/to base32.I believe the base32 encoding won't be necessary for the
datastore-level
, should I hardwire exception for it or also encode it?The text was updated successfully, but these errors were encountered: