As you probably saw on some of the recent dev updates, we’ve been designing and trying out our own encoding format for the XOR-URL string, as an alternative to using multiformats CID that was part of the original proposal which is not a fully discarded option, but we decided to try this other format to begin with and see how that evolves and how it works for us.
Some more details and considerations about these two options are explained the RFC itself. There is also a discussion about these aspects in its original thread on the dev forum if you are interested in learning more about it.
We therefore have a PR to update the RFC which is ready for review and comments: Define our own content-id encoding format for XOR-URLs by bochaco · Pull Request #337 · maidsafe/rfcs · GitHub
The changes as substantial so I’d advice to simply read the new version rather than trying to see the diffs: rfcs/0053-xor-urls.md at c68925b1d5760b5b1a1b7159b295af7709851ae8 · maidsafe/rfcs · GitHub
The encoding format we designed is now implemented on CLI and it’s in summary like this:
- 1 byte for XOR-URL encoding format version. This is version 1
- 2 bytes for content type, e.g. Wallet, FilesContainer, MIME types, etc.
- 1 byte for SAFE native data type, e.g. PublishedImmutableData, PubseqAppendOnlyData, etc.
- 32 bytes for the content’s XoR name
- 0 to 8 bytes for type tag value
- The string is then encoded with z-base32 encoding
-
v=<content version>query arg for the specifying a specific version of the content, or latest if this is omitted from the URL.
Please feel free to discuss/comment either here or in the dev forum thread.
