nsreed/ouronote

Needs instructions on how to file a bug report? (also feedback)

Opened this issue · 1 comments

I clicked on bug report and it brought me here when I clicked on github issues. I have no idea what this stuff is or how you want it to be presented. I'm assuming you want me to do something to submit an issue, but as I've never interacted with your thing, I don't know what you expect.

I also saw some junk under "preview" and it seems to be copied to my clipboard when I click copy. But I also see it lets me download it as a .json?

Should I attach it as a file? If you include the ``` junk in the copy/paste, it would make it easier to include that way, but it ends up being a mess?

I can't copy it in here. It says

"There was an error creating your Issue: body is too long (maximum is 65536 characters)."

and if I try to add the .json file it says

"We don’t support that file type. Try again with a GIF, JPEG, JPG, MOV, MP4, PNG, CSV, DOCX, FODG, FODP, FODS, FODT, GZ, LOG, MD, ODF, ODG, ODP, ODS, ODT, PDF, PPTX, TXT, XLS, XLSX or ZIP."

I would love some options to not include stuff like what peers I'm connected to. and maybe replace my public token with '[token removed]' placeholder or something like that.

Excellent points.

I think I can create github issue templates to make this process a little bit easier. As for the specifics of the contents of the bug report (peers, and pubkeys), I'll have to mull this over. Looking for the community's thoughts on the following:

I don't have an expert understanding of what compromising data may be contained in the "peers" key (which is a key/value pair of the gun.root.opt.peers variable). While I haven't seen any identifiable data (WAN IP addresses or the like) in my local tests of this feature, this concern is still probably valid. If I included a checkbox to include/exclude that section from the bug report, would that be adequate (I can default to exclude it)?

Public keys are another issue. I understand not wanting to directly associate your public key to your github account. But I have limited options for dumping data that may be necessary to debug gun-specific problems. I'm open to suggestions about how to submit this data, if and when it becomes necessary for diagnosing problems. Off the top of my head, replacing instances of pubkeys with placeholder text may be an option, though a diligent stalker with enough time and resources could match the content of these records to your public key. I could limit the contents to something like metadata (just the update times for each field in the graph). I could also strongly recommend that users attempt to reproduce the bug using a new account. As with the peers key, would it suffice to make it optional to bundle this data with the bug report?

At the very least I need log messages, which for the time being, contain paths to specific nodes which may be problematic. This may also leak possibly sensitive information. I'm blanking on a way to gather useful data about the state of the database where someone may say "Item X didn't show up on my (User Q's) machine when User Y added it on their machine". De-identification of these data poses an interesting challenge.

In the mean time, and until these specific issues are addressed, I will add warnings about the disclosure of potentially personally identifiable information in the contents of the bug report JSON. I should also include clarification about how to submit these files, if not publicly as a github issue, then to me personally.