Should work fine. Ping me dan@detail.dev or @danlovesproofs with your account info so we can look into it?

We've been thinking about this too. We have some ideas. Thanks for the comment, in any case – gave us a lot to chew on.

As far as we can tell this is a github-ism, and any OAuth permission is a form of "acting on your behalf": https://dappling.medium.com/a-github-app-would-like-to-act-o...

I looked for an explanation of what the tool does on my behalf on your site but didn't see anything.

I guess I expected on the homepage or maybe "About" but I was looking for something related to whether you open PRs on my behalf given that OAuth prompt.

I think adding that or some explanation during onboarding about the permissions might help.

That's good to know, but I would still suggest an on-ramp that only uses GitHub for authentication (i.e. no permissions needed). To that end, it would be nice if I could also authenticate with other OAuth providers instead, like Google, etc.

Again, I understand that this would limit me to scanning public repos, but that would be fine.

Other auth providers for sure. We'll be adding shortly.

Using an alternate auth provider won't even prevent you from scanning non-public GitHub code. There's a GitHub OAuth App just for auth (which is what you're seeing here), and a separate GitHub App that you need to install either way to give Detail access to the right repos. We can swap out the former for Google/Okta/pw if you want to avoid this warning. GitHub Apps (the half that manages repo access) have a much finer grained permissions model.

Hi bflesch, fair point – our About Us page has a lot about what we think and not about... us!

I'm the founder. Previously I was at Heap for nine years. There's a company LinkedIn with the rest of the team: https://www.linkedin.com/company/detail-dev/

We're located in SF. The About Us page lists some of our angel investors at the bottom.

Regarding security in particular, there's a lot more info in our Trust Center: https://trust.detail.dev/

If anything else seems conspicuously missing, please flag. In all likelihood it's omitted without intent.

Thanks for your reply. As I said, on your website there is no address, there is no legal entity name, there is no company registration number. You could sit in north korea for all I know.

Now I spotted in the last sentence of your "about us" that "We're based in SF". Oh and only now I see on the "terms" page has "15. Contact information qqbot, Inc 3624 16th St San Francisco, CA 94114 Email: support@detail.dev"

Why not put that address into the footer or add an imprint section to the website? It's such a quick win to establish trust. Also if guillermo rauch is an angel investor why mention him at the last sentence of the "about us" page and not in the middle of your landing page. Why did guillermo not post a testimonial that add to the landing page? Did he not like the product? Or did he not review the product?

PS: When I search for "qqbot" on kagi a lot of chinese-language results show up. Is the company affiliated with china?

Sorry for challenging you. I wish you good luck if your claims hold it is a worthwhile effort.

We've run it on a few firmware repos and gotten good results. A lot of firmware code tends to have really poor type-safety which means lots of low-hanging bugs.

We should be able to handle cross-compilation. Want to try it? Ping me in any direct channel (dan@detail.dev / @danlovesproofs) and we can keep an eye on your repo.

Just github for now, but purely for reasons of plumbing. We'll add gitlab and others.

We support java, c/c++, kotlin, ruby, and swift as well. Did you have something specific in mind?

My immediate personal use case would be C# on a self-hosted Gitea instance.

Realistically, anything paid would need to be fully self-hostable, though. There's a bunch of Java codebases that I work on that would benefit from something like this, but they're all behind two or three layers of Citrix...

Github only for now. Out of curiosity, is yours on gitlab? Something else?

We should be able to find something interesting in most codebases, as long as there's some plausible way to build and test the code and the codebase is big enough. (Below ~250 files the results get iffy.) We've just tested it a lot more thoroughly on app backends, because that's what we know best.

> Out of curiosity, is yours on gitlab? Something else?

Something else, it's a self-hosted Git server similar to GitHub, GitLab, etc. We have multiple repos well clear of 1k files. Almost none of it is JavaScript or TypeScript or anything like that. None of our own code is public.

Fix is deploying, sorry about that!

Fwiw, the authors never actually claimed this. From their technical report [0]:

> Chai-1 achieves a ligand RMSD success rate of 77%, which is comparable to the 76% achieved by AlphaFold3

[0] https://chaiassets.com/chai-1/paper/technical_report_v1.pdf

He owns the IP, but we all lose out from this system.

Art has asymmetric upside – bad art doesn't really harm anyone (usually just gets forgotten) but good art enriches millions of people's lives.

It might have been amazing. It might have been bad-but-interesting. We'll never know!

As a writer, I really would not like someone taking something I wrote, trashing it and then have that person’s version be the one everyone knows.

On a personal level I can absolutely empathize, but respectfully, I don't see why that should be the state's concern. The goal of IP law should be to promote the creation of good art, not to make sure artists' wishes are respected.

So, for example, theft should be illegal, because a world of unrestricted IP theft might be one in which we would get a lot less art. But allowing Tolkien to block adaptations of his bestseller 14 years after publication was probably not good for art.

The creator of Pepe the frog might disagree. It's a fine line.

If it would have been done poorly, no one might have funded Jackson, it’s hard to judge in hindsight.

Do bad adaptations prevent good adaptations? Lynch's Dune flopped but Villeneuve had a $165m budget.

We can't know the contrapositive but I don't see why giving the author a veto makes good outcomes more likely, especially decades after a book is published.