API queries as I stumble over them

API queries as I stumble over them…

DNS Create long name(s)
If I log into an existing account in the launcher and create a second longName via API, then I can’t see that new PublicID in the Demo App, as that notes the first one.

  1. Is there a limit on the number of longNames an account can request via the API?

  2. Should the Demo App display many longNames, where those exist; or should the API match the Demo App, in limiting one account to having one PublicID?

DNS List Services
Why is List Services necessarily authorised? -is that again app v drive, which I’ve yet to fully understand the use of?? Still perhaps should be like “Get home directory” as “Authorized and unauthorized requests can invoke this endpoint, but private data can only be acquired via an authorized request.”

DNS Delete long name
Delete appears not to remove a longName to the point that it can be created again… is that expected to always be the case or will delete evolve to properly remove longNames?

Still having got create service working and haven’t attempted NFS but happy to have made some progress today :smiley:


The demo app handles only one public id. Even if there are multiple public id for a user, it will pick only the first one.[quote=“davidpbrown, post:1, topic:234”]
Is there a limit on the number of longNames an account can request via the API?

No, there is no limit for the number of public id as of now.

The long name or the services configured for a long name should not be made available for public read IMO. The management of the services/long name should be authorised.

The unauthorised request can fetch the data only if a service, longname is mapped to a public directory,

But if there are valid use cases for exposing the list for unauthorised access, I would definitely like to correct my stand on this.

The DNS is saved in the network as StructuredData. The delete workflow of StructuredData was updated in the last testnet. The SD is not deleted from the network but it can be claimed again by anyone. I think DNS should be able to recover this SD in this case and assign the ownership to the user. @ustulation can definitely help better than me in this regards.


On first pass at using API, I like the use of headers more than the URL. There does seem to be rather a mix of URL and headers in places; given others apparent liking of URL fields, perhaps both can be made available? - though I do wonder for some fields only headers are appropriate and perhaps URL with data offers less privacy??

Connection: close
headers make no mention of
post_headers.insert("Connection".to_string(), "close".to_string());
which appears to be needed, so that request doesn’t just hang… or is that just a rust related issue?

Overwrite file?
What option for direct overwrite of files?.. I was expecting perhaps NFS File PUT for that.

Is there a size limit on file metadata?

Drive structure
Could be made more obvious in docs - perhaps in Create Directory.
From what I can see it seems top of drive is /SAFEDrive/ and top of app is /appName-Root-Dir/
Does SAFEDrive then contain the /public/ and /private/ that are seen in the DemoApp?

and following my confusion of drive structures then:
NFS list directories?
What option is there to list private directories?
Is there an option to list app directories? Obviously drive and current app directory are apparent to an app but what option is there for a user to see what directories have been created? Also, will users have write control over the app directories to delete them?.. expecting perhaps user control is preferred - that needs to be understood by app developers.

NFS Create directory
docs example tempts creation of parent and subdirectory as one action
= http://localhost:8100/nfs/directory/drive/websites/www-example
so perhaps should be suggested as two steps possible
= http://localhost:8100/nfs/directory/drive/websites
= http://localhost:8100/nfs/directory/drive/websites/www-example

NFS Update directory

  • Perhaps should include an option to update isPrivate?
  • Trivially ‘name’ field would be better as ‘newName’

dir isPrivate could do with fuller explaination
-> Is that private to the user and the app… or private to the app and not accessible/?visible to user.

Drive permissions to an app appear as null="" but does that necessarily always allow app to write to its own directory… is that obvious enough to user? What with cookies and tracking being contentious, perhaps needs to be made clear. Otherwise app will know more that the user expects they allowed.

Cost of writing app data
Who pays for app write to its own directory and how much might that be?.. Are we expecting use of micropayments for such trivial writes??

1 Like

My rational for preferring url parameters over header variables is one of usability. Setting headers requires specialist tools/software, but url parameters can just be typed into a url bar/string (of browser, curl style app, etc).

Given most parameters are unique to the command, having header parameters seems overkill for most things. Access token aside, I don’t think there is anything else which applies to all commands?

When the client provides an accept header of text/html or application/json, then the browser can even produce useful renders. Fetching a directory could list the files/subdirectories out of the box, for example. If you can then apply more filters to the query string, you can do useful things with this data with no extra tooling.

Taking it further, you could have a page with a button to initiate an authorisation attempt, when the accept content type is text/html, which could be embedded in the header while browsing private safedrive directories with NFS.

OK, just illustrating simple examples, but I think less tooling to get results is generally a good thing.

1 Like

Yes, that’s a good use case. My thought is that at user’s risk if they think the balance is worthwhile then use it and in the case that it’s within SAFE browser environment that’s fine. The risk I suppose is where any logging of urls might be trivial and then posting headers is to be perhaps preferred.

DNS Add service
Why does DNS Add service have rootPath=app option? What does service mean within /app??
The serviceHomeDirPath that might be appropriate, is not obvious in the doc.

NFS Create file
Is it just me or does NFS Create file not work at depth?.. I can’t seem to use it to create file in a /foo/subdirectory/ where it works for any drive /foo/

Work ok now.

I’ve been creating files in /remotestorage/myfavoritedrinks (isPathShared=true, isPrivate=false), both REST and beaker/safe-js.

1 Like

NFS Create File
Is [Content-Type]=[The media type of the file being uploaded.] used?
I’m looking at the code in nfs.js:line189-221 and wonder that it’s unreliable to resolve content-type anyhow… routes in rust appear to be guessing at content and use of extensions; then I can’t see how it would be useful to creating a file. Should it just be ignored or even removed?

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