XOR-URL RFC discussion

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.

20 Likes

Final Comment Period

The XOR-URLs RFC will remain open for 10 more days to allow any final comments to be made.

Thanks for contributing! :slightly_smiling_face:

Dev Forum thread where most of the discussion has taken place

3 Likes

Final Comment Period

FCP on the DevForum has closed now, thank you :smiley:

5 Likes