domob wrote:
I would suggest to add any keys present in the imported name, but have them overwritten by keys explicitly specified in the value.
This seems counter intuitive to me. I would expect it to work like the python import, overwriting everything that is present by what is being imported. Any particular reason for this behaviour?
Multiple imports could be done using an array of names as value of "import", and having them processed in this order.
+1
I think we should make import non-recursive - both for performance/security reasons and because it is not really necessary (IMHO - but with non-recursive import the effective value size is again restricted by a finite bound; maybe we should restrict the maximum recursion depth instead?).
If recursive depth certainly would have to be restricted tightly to make ddos attacks less easy. 0, 1, 2 levels?
General JSON entries seems like what we should do. Which actual use-cases of Namecoin interpret import is up to them, I think we should just define the general behaviour of import and let "everyone" (DNS / NMControl, NameID, ...) decide for themselves whether or not to make use of this feature. (This means, I'm not in favour of specifying that *every* Namecoin value should be interpreted as if import as processed, only how importing should work if it is wanted. Like the "signer" field we recently discussed.)
+1
Several import statements shouldn't be possible, at least I think that JSON disallows that. (Although of course the textual value could include them, but wouldn't this be invalid JSON then and thus something we should disallow?) Use name arrays instead.
Python json only seems to use the last occurrence.
Another question: Should import work only on the top-level JSON scope of a value, or for any object within the JSON value? (Like the "map" entry of a DNS name.) But I think this should be defined by the actual use-case specification for each namespace.
Hmm... this would allow for several imports per name. Should we limit the total number of allowed imports? Or the size of the resulting object?
biolizard89 wrote:
1. "import" should not assume the "map" field; it should be generic JSON (so works with other namespaces than d/).
Check, no "map".
2. Fields added by "import" should be overridden by the existing fields. This is critical to allow cold storage to work.
As domob suggested... but I don't get it. Why would I use import but also have the field present in the actual value? Could you please elaborate?
3. Allowing partial import (only import a subset of fields) is critical to allow cold storage to work.
...
4. Recursive import is necessary to allow a logical name to span large numbers of raw names. If someone is willing to pay the fees for 50 names, they should be allowed to use them as subdomains instead of requiring them to be separate 2nd-level domains. It might be useful to include a limit on recursive depth, and recursive loops should be ignored.
Ignoring loops sure is a good idea.
agorism1 wrote:I have attempted to implement the "import" feature. It is all in python.
Import is (should be) recursive in my design.
It has not been tested much yet, but I also added the ability to leave posts on an your ID. or to leave comments on your own or other people's posts.
I wrote it for namecoind (it uses your browser as the GUI) , and will be updating for namecoinq soon.
https://rlevykyswlg7ibqi.onion.to/
Hopefully this will make namecoin's value go up.
Is the code available somewhere? For this application there should not be a difference between classic namecoind and namecoinq daemon/qt.
domob wrote:biolizard89 wrote:Seeing as the spec is not decided on, I'm not sure why you implemented something without being involved in the spec design process. Also, my opinion is that this should be implemented within nmcontrol.
+1 for nmcontrol. However, I think there will be alternative implementations, too, as not everyone might want to use nmcontrol. (Not sure about NameID, for instance.) But for them, I think it should be rather easy to implement "import" anyway (once the specification is defined precisely).
It needs to be in NMControl. Maybe in a modular way so that the code can easily be integrated into other software.
Should we use "import" or should we use something new (shorter)? What about "imp" instead of import? It would also avoid any potential conflict with the existing "import" (e.g. the "map" stuff).
