Been wondering this for a while now

Support
1

and then I thought “That’s a daft thing to do, Ask someone.”

So here goes…

Why do all the address created so far on the shared vaults, on a private vault or in a private network begin with safe://h and then the next few chars are chosen from h, y, n or b

I know that answer will be something that should be obvious and I will probably kick myself when it is revealed…
Are we -as yet- restricting ourselves to a small subset of the available zillions of addresses and these chars are the result of some hard-coded value? But that would seem to me to run counter to the design philosophy so far.

And once again, thank you to @frabrunelle for decoding my horrendous typos in the original post :slight_smile: We are not worthy of such superb moderators

4 Likes
2

@Southside I’m clueless, but my guess is

It’s to indicate that your on the SAFE Network and using the SAFE protocol I suppose :thinking:
Like http or https is on clearnet
etc…

1 Like
3

Yeah, I know about the safe:// bit thats obvious, its the “h” then restricted set of [h n y b] usually repeated that form the next 5-6 chars that I was wondering about

1 Like
4

Hmmm interesting I didn’t notice that part (I’m using the mobile SAFE browser 0.3.0).

Maybe it has something to do with the NRS, I’ve been wondering for a while if that’s the same as publicid’s (NRS is not the same as Publicid’s as far as I know)… :thinking:

1 Like
5

The “XorURL” as we know it is actually a base32z string (base 32 is a string encoding scheme).

In base32, the following mappings exist:

  • 0 = y
  • 1 = b
  • 2 = n

I’m going to assume that the second value in the XorURL is the data type, from 0 - 8.

I believe the first value (the h) is the encoding_version of the XorURL, with the default currently being XOR_URL_VERSION_1 = 0x1, as for why it’s an h though, I’m not sure.

The code internally has this mapping (for the data type - the second character in the XorURL):

            0 => Ok(Self::SafeKey),
            1 => Ok(Self::PublishedImmutableData),
            2 => Ok(Self::UnpublishedImmutableData),
            3 => Ok(Self::SeqMutableData),
            4 => Ok(Self::UnseqMutableData),
            5 => Ok(Self::PublishedSeqAppendOnlyData),
            6 => Ok(Self::PublishedUnseqAppendOnlyData),
            7 => Ok(Self::UnpublishedSeqAppendOnlyData),
            8 => Ok(Self::UnpublishedUnseqAppendOnlyData),

You can find the code which implements the encoding of the XorURL here in the Safe-API libraries: https://github.com/maidsafe/safe-api/blob/fdfc7e7f132b907a4ac01ed570c7bb71aad7be79/safe-api/src/api/app/xorurl.rs#L182

10 Likes
6

This makes sense now :slight_smile: Thank you

I suppose I should now be able to work out what is going on at the end of each address with the 9s - Or have I simply chosen a small unrepresentative sample?

New SafeKey created at: “safe://hbyyyybd7if5jqa4mu74mjnh6cgiufj8d9e6kdru1rdjq5eif3myi9sg9w”
Wallet created at: “safe://hnyybyqix8y47e5fbog9hirhx4tryzsogdrchb766sy1ijn5mfbys1azooy9e”
New SafeKey created at: “safe://hbyyyybkabrnso5nbjbu6dz5dfni8uirocwrddwdtbsz3c5s3b5s4atyn9”
Wallet created at: “safe://hnyybyq9sumcgmr98perut4m6q1fpmot896aqak3h411y78asrjkzh8fsky9e”

2 Likes
7

I believe - but this is unsubstantiated and based off very little research - that the final value is the content_version, so in the case of, say, a public_name it would be the published version of that public_name

2 Likes
8

I assume the latest definition of xor URLs should be linked here

3 Likes
9

In case it helps and you weren’t aware of, you can also use xorurl decode command to get details of the targeted content: https://github.com/maidsafe/safe-api/blob/master/safe-cli/README.md#xorurl-decode

7 Likes
10

This topic was automatically closed after 60 days. New replies are no longer allowed.