XOR-URL from dog = xor?

Support
1

Is dog suggesting XOR-URL correctly?? @bochaco

I see this example below and wonder that
XOR-URL: safe://one.hnyydys8rowdmcu3m13hy6ojtxkjobfty4tu6zij8cwh18yudbf1psrg76bqh
should be instead the “Link” on the matching “NRS name/subname”
safe://hnyynyihu4o34zgturwiap3bfxt5cwjrbr3xebcyhgnd9846skxamdfb4gbnc?v=0
because that looks like a xorurl and not a subname

:thinking:

safe dog one.hnyydys8rowdmcu3m13hy6ojtxkjobfty4tu6zij8cwh18yudbf1psrg76bqh`== URL resolution step 1 ==
Resolved from: safe://one.hnyydys8rowdmcu3m13hy6ojtxkjobfty4tu6zij8cwh18yudbf1psrg76bqh
= NRS Map Container =
PublicName: "hnyydys8rowdmcu3m13hy6ojtxkjobfty4tu6zij8cwh18yudbf1psrg76bqh"
XOR-URL: safe://one.hnyydys8rowdmcu3m13hy6ojtxkjobfty4tu6zij8cwh18yudbf1psrg76bqh
Version: 2
Type tag: 1500
XOR name: 0x8e48506b64f2b96780f41317a93009620d467ebd52765392382630964db10ddf
Native data type: PublishedSeqAppendOnlyData
+-------------------------------------------------------------------+----------------------+----------------------+--------------------------------------------------------------------------+
| NRS name/subname                                                  | Created              | Modified             | Link                                                                     |
+-------------------------------------------------------------------+----------------------+----------------------+--------------------------------------------------------------------------+
| hnyydys8rowdmcu3m13hy6ojtxkjobfty4tu6zij8cwh18yudbf1psrg76bqh     | 2020-05-24T19:56:21Z | 2020-05-24T19:56:21Z | safe://hnyynyig8h9za7q15gw57784ge4eqm33dg8oidf8bnq119qbo4s6dwnfn1bnc?v=0 |
+-------------------------------------------------------------------+----------------------+----------------------+--------------------------------------------------------------------------+
| one.hnyydys8rowdmcu3m13hy6ojtxkjobfty4tu6zij8cwh18yudbf1psrg76bqh | 2020-05-24T19:56:52Z | 2020-05-24T19:56:52Z | safe://hnyynyihu4o34zgturwiap3bfxt5cwjrbr3xebcyhgnd9846skxamdfb4gbnc?v=0 |
+-------------------------------------------------------------------+----------------------+----------------------+--------------------------------------------------------------------------+
| two.hnyydys8rowdmcu3m13hy6ojtxkjobfty4tu6zij8cwh18yudbf1psrg76bqh | 2020-05-24T19:57:03Z | 2020-05-24T19:57:03Z | safe://hnyynyzthuu6paduz1gynndg18sxzz5dijexfzj95153kybep8abxezndrbnc?v=0 |
+-------------------------------------------------------------------+----------------------+----------------------+--------------------------------------------------------------------------+

== URL resolution step 2 ==
Resolved from: safe://hnyynyihu4o34zgturwiap3bfxt5cwjrbr3xebcyhgnd9846skxamdfb4gbnc?v=0
= FilesContainer =
XOR-URL: safe://hnyynyihu4o34zgturwiap3bfxt5cwjrbr3xebcyhgnd9846skxamdfb4gbnc?v=0
Version: 0
Type tag: 1100
XOR name: 0x793d433ab9a33252b86e4257c76ca2481265e80b01c3087f3ebd653f0b1943a3
Native data type: PublishedSeqAppendOnlyData
2 Likes
2

No it’s not correct, I was even trying to fix it today (https://github.com/maidsafe/safe-api/pull/572), the expected XOR-URL should be the same as it shows but just without the subname one., that’s supposed to be the XOR-URL of the NRS Container.

I think we should also remove the PublicName: "hnyydys8row..." from it as in this case it’s not resolved from an NRS-URL, so that is also incorrect.

4 Likes
3

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