I was ponderingnthe PK issue some more too. The following could work:
- Create a public writeable ledger against a defined PK and name (e.g. nrs1).
- Share address to the ledger with anyone who wants to add NRS addresses.
- Users create a private register (e.g. 'my_private_app_register) and add an entry to the XOR address of their app root/file.
- Users add an entry to the above register, with a format like ‘name,my_private_app_register’ (or json for flexibility), where name is the ‘host’ (in clear net speak).
- The public nrs1 register would be first come, first serve, so duplicates get ignored.
- When nrs1 runs out of space, nrs2 is looked up, then nrs3, etc. These could be created ahead of time and/or as needed, all against the original key.
- Users update their private register as/when needed to change the destination XOR address.
Ofc, these registers could get spammed and filled. IIRC, thought is going into making thar harder/expensive though.
For revolving URLs:
- App searches nrs registers (nrs1, nrs2, etc) for a match against the name (crude/brute force).
- Apps could cache nrs into data file (xor addressable, json, etc). Processing could be done by trusted parties, if desired. Local app could provide service/interface if needed.
- Apps resolve nrs response to lookup private register, then retrieve data from XOR address.
In terms of what is in the resolved data, that probably comes into the other thread on website paths etc. Something could be standardised though, with file names mapping to XOR addresses. The app could then resolve accordingly (sn_httpd could do the same for clear net infrastructure).