Generating external IDs

[aaronwolen]

The API provides endpoints for generating and listing external IDs (currently limited to DOIs). We could implement something like

osf_generate_id(proj, type = "doi")

which would return a modified version of proj with a new doi column.

• The generic name provides for the possibility of being able to generate other IDs
• generate is annoyingly long... might need a different verb
• Should it verify a node is public? Is that a requirement?

Would also need osf_ls_ids() to list previously generated IDs since they aren't returned by default.

Comments/suggestions, @cboettig?

[aaronwolen]

Also like the following function names for making entities public/private:

• osf_publicize()
• osf_privatize()

They'll both need recurse arguments to control whether lower-level components are affected.

[cboettig]

@aaronwolen Apologies for the long turn-around here!

I think this would be super helpful. osf_generate_id() is fine, but maybe osf_mint_id() is more concise? I'm also not sure but osf_get_ids() might be more intuitive to non-UNIX-bearded?

Related to this: is it already possible to "bring your own id" for an OSF object? e.g. I'm particularly keen these days on using content hashes as unique identifiers for data objects. For example, if I put a file on GitHub and then make a permanent archive of it via the Software Heritage API, I can always request my precise bits & bytes back by using the SHA-256 hash of the object as the identifier. I'd love to be able to query OSF by content hash as well (ideally OSF would compute that for me like Software Heritage does, but I could still use this workflow if I mint the hash-based identifier myself and can use it as my object's GUID in the OSF index...) more background at https://cboettig.github.io/contentid/articles/technotes/identifiers-for-iterative-forecasting.html