Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Findings: Your lab notebook, reinvented

findingsapp.com

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Findings: Your lab notebook, reinvented

#11

Post by GioM »

CamperBob2 wrote: post #4

Makes no sense to do this as anything but a web app, IMO. Certainly not as a Mac-specific native app.

On the contrary, it makes perfect sense. Labs work with all kinds of data, including samples and information obtained from human trials where privacy is mandated by law. Sync that to the cloud, and you open a huge can of legal-compliance worms.

By keeping local data in a local DB, this is avoided. I see on the website that sync is coming soon. If the developer is smart, they'll allow selective sync so that labs can choose what to upload and what to keep local, or will offer some sort of non-cloud p2p sync solution.

Re: Findings: Your lab notebook, reinvented

#12

Post by eaurouge »

Great idea! You should find a partner to print to physical books - this may be a simpler export option (and added feature) while you work on your sqlite-based export. You should provide some sort of verification that notes that I claim to have entered on a certain date were indeed entered on that date, for inventions (although the US is now first-to-file). And you should allow me to scribble notes on a tablet.

Re: Findings: Your lab notebook, reinvented

#13

Post by charles_parnot »

michaelmior wrote: post #10
RaptorJ wrote: post #3

Earlier quoted context omitted.

I'm not sure if this is what they do, but it seems like a solution would be the git commit hashing procedure. So at the end of a day/worksession have the app take the hash of ( what you entered today + yesterday's hash) so you create a provable trail of changes.

I'm not sure I see why hashing is necessary nor why it provides any "proof" of what was changed. Perhaps it's the git analogy that's tripping me up because you can easily forge commits to appear as being from any user at any time.

The problem evoked here is for your institution at which you work, to know that their researchers are not changing the data afterwards and following best practices. In this scheme, the user would submit the hashes to a central server controlled by the institution. Then, the user have no way of changing the content without them knowing.

And yes, you would need to add some authentication to know it's always the same user, but that's a different, orthogonal issue.

For actual proof e.g. in court, you'd need a third party with a private key used to sign the content. A little more involved... But the main point of that would be patent litigation, and with the new 'first to file' rule in the US, it is much less relevant.

Re: Findings: Your lab notebook, reinvented

#14

Post by charles_parnot »

eaurouge wrote: post #12

Great idea! You should find a partner to print to physical books - this may be a simpler export option (and added feature) while you work on your sqlite-based export. You should provide some sort of verification that notes that I claim to have entered on a certain date were indeed entered on that date, for inventions (although the US is now first-to-file). And you should allow me to scribble notes on a tablet.

Thanks for the feedback! Nice idea about printing. The export will be here very soon, it simply did not make the cut for 1.0 because it needs more testing.

Yes, the 'first to file' thing is still new enough that many scientists still think it is useful to sign their notebooks for that purpose. There are still subtleties to those rules, though, that we need to investigate a bit.

Re: Findings: Your lab notebook, reinvented

#15

Post by charles_parnot »

GioM wrote: post #11
CamperBob2 wrote: post #4

Makes no sense to do this as anything but a web app, IMO. Certainly not as a Mac-specific native app.

On the contrary, it makes perfect sense. Labs work with all kinds of data, including samples and information obtained from human trials where privacy is mandated by law. Sync that to the cloud, and you open a huge can of legal-compliance worms. By keeping local data in a local DB, this is avoided. I see on the website that sync is coming soon. If the developer is smart, they'll allow selective sync so that labs can c…

We do plan to allow syncing to a local network drive, if that can work. The idea is that it will be file-based, and can leverage Dropbox, Google Drive or... a local networked drive. Still working on it, though! See PARStore on github for some of the basic ideas, as this is what we use for document storage.

Re: Findings: Your lab notebook, reinvented

#16

Post by michaelmior »

charles_parnot wrote: post #13
michaelmior wrote: post #10

Earlier quoted context omitted.

I'm not sure I see why hashing is necessary nor why it provides any "proof" of what was changed. Perhaps it's the git analogy that's tripping me up because you can easily forge commits to appear as being from any user at any time.

The problem evoked here is for your institution at which you work, to know that their researchers are not changing the data afterwards and following best practices. In this scheme, the user would submit the hashes to a central server controlled by the institution. Then, the user have no way of changing the content without them knowing. And yes, you would need to add some authentication to know it's always the same us…

If you have a trusted third party that can hold content for you, why not just have them store the actual data? Unless of course it's very large, but that seems unlikely to be the case in this scenario.

Re: Findings: Your lab notebook, reinvented

#17

Post by charles_parnot »

michaelmior wrote: post #16
charles_parnot wrote: post #13

Earlier quoted context omitted.

The problem evoked here is for your institution at which you work, to know that their researchers are not changing the data afterwards and following best practices. In this scheme, the user would submit the hashes to a central server controlled by the institution. Then, the user have no way of changing the content without them knowing. And yes, you would need to add some authentication to know it's always the same us…

If you have a trusted third party that can hold content for you, why not just have them store the actual data? Unless of course it's very large, but that seems unlikely to be the case in this scenario.

You could actually have quite a lot of data generated in a lab, depending on what you do. By only storing the signatures, you can have a much cheaper service that what would be needed to store GB of data, and really focus on other aspects that are critical for this: security, backup, user interface, speed,... Having only to worry about backup of a bunch of signatures is a much easier task than having to worry about backing up the actual data.
Post reply on HN