Late reply but was going through the AI code and it reminded me of the discussion..
Bigbug
yea.. definitely "OpenAI" isn't "Open" at all (as in oss)
The timing on your comment is funny… https://www.theguardian.com/technology/2024/sep/26/openai-planning-to-become-for-profit-company-say-reports
I like that with the AI integration we ask you to specify the URL so you could self host something or use a different third party of your choice.
-
Password strength indicators could be nice. NIST 800-63B 5.1.1.2 recommends these (in addition to checking against a breach list)
Verifiers SHOULD offer guidance to the subscriber, such as a password-strength meter [Meters], to assist the user in choosing a strong memorized secret.
-
Troy at HIBP is a great guy, but that doesn't change my stance on integrating with things. Most of these requests are, or could be, possible through the API.
My main issues with direct third party integrations are:
- Flexibility - We have to do things the way a third party says so, and then have to add bits of specific code to account for multiple ways of doing it with that third party.
For instance, when setting up SMTP we allow you to set the port & TLS. If every third party has a pretty essential setting that is called differently, we end up having to do lots of work & add lots of extra fields just to account for use cases that someone that might use that integration might use.
- Ongoing maintenance - as the other side changes things, we then have to maintain these - probably indefinitely - or at least until the vendor becomes too expensive and people want to move elsewhere..
- Having to provide alternatives / "Can we have X too" requests - for every service we add an integration for, there will be requests for a different one, for whatever reason (but probably cost)
- Most of these requests are for proprietary, paid services
So we'll end up spending our unpaid time writing neat little features that put money into the pockets of companies. Anyone using ITFlow that wants integrated functionality for that feature is then forced to pay that specific third party company, because that's all we support.
The only person that really wins there is the vendor.
In the case of invoices, we are basically forcing you to use Stripe if you want to take online payments easily. I don't like that (and want to add others to balance things), but given that you can't just spin up your own payment gateway, it's a reasonable trade-off in my view.
In most cases, I would rather spend my time expanding the API (that already allows viewing credentials..) than directly increasing the revenue of third party companies with a 1-click integration. I'm not against building some sort of framework/middle-ware to make writing, sharing & using integrations easier, but this is probably best hosted as a third party service (such as 8N8 - though they are source-available) that again just uses the ITFlow API to interact with third party APIs.