You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We will do this as actual research objects, but it will not be possible for the authors to claim them because it's made with a different DID. This is OK.
We could potentially have imported them as "soft" nodes, i.e. public nodes that doesn't have an actual research object. This way, original authors could claim them. We choose not to do this, because:
engineering is more complex, both on app and backend side
new access type to support going forward, in an already complex flow
it's a good scalability test for the protocol(s)
Regarding key management, these were the alternatives:
Create all of them with a known, new key (1 key controlling n research objects)
Create each with a known, individual new key (n keys controlling n research objects)
Create all with a key we throw away ("tombstone" imports, no updates possible)
We are going with 1, keeping the option open for Insight Journal to manage the objects themselves.
About: https://insight-journal.org/
Data: https://github.com/InsightSoftwareConsortium/InsightJournal
The text was updated successfully, but these errors were encountered: