You might have missed it, let me paste the relevant section for you here:
Always use a unique API key for each team member on your account.
I’ve highlighted the relevant parts in bold so they’re a bit easier to spot.
It is not sharing an API key if only you use it. In this app you are the only user of your API key. I think this line is more like people sharing their Netflix passwords with family and friends, which makes way more sense as an activity to curb.
I do not say the user shares their key. I say they enter it, and I store it and make calls on their behalf. That is different from sharing. Sharing is where I give you my key and you use it for whatever you like as if it were your own.
My app is ages from production, I can refactor it to use my own api key if need be. But it’s not unsafe to build an app this way and it’s an onus for devs because you have to build a system to meter usage and charge users for access. It’s a huge extra piece that means you can’t build an app that users can access for free. It’s absurd.
That means you can’t build an app that forces users to give up their security by transferring their credentials to an untrusted third party with unknown security or possible nefarious purposes, where their use is not just not free, but can expose them to bad actors that would rack up massive fee abuse with use cases that would cause account termination.
Not putting API keys into bring-your-own-key applications that make requests on your behalf is the exact clarifying language that needs to be made for users. On the API key screen, imagine for those needing common sense: “This key is for your own locally-controlled software, not for putting into some AI waifu sex chat site.”
I’ve already refactored the app to only use my own key set securely via environment vars on the backend.
I think it’s possible that there are some assumptions being made about the potential slapdashedness going on with my implementation. This is an app meant primarily for me personally. I want to allow extremely gradual expansion only by working directly with small cohorts of hand-picked users. I just didn’t want to build a billing and metering system for this mostly experimental collaboration tool IMMEDIATELY. It isn’t for everyone in the world to access tomorrow or anytime in the near future.
Don’t worry, champ. I believe people just want to help you and everyone else stay safe on the internet. Congrats on the ~8h refactoring, that was a quick turnaround.
I think people just got the impression that you were further along than you were.
We’re trying to understand your intention with the project, it would be helpful if you could provide a description?
As I’ve suggested before, hosting it on GitHub can be valuable. Beyond the public sharing aspect, GitHub offers robust version control to easily track and revert changes. It acts as a safety net by providing an off-site backup, facilitates collaboration if you decide to invite others, and can serve as a testament to your coding skills. Plus, you can always keep the repository private, ensuring access only to those you trust.
You can see more about what I’m up to at PlotRocket. It’s a tool to help writers find the beats of their long form episodic fiction stories, using the AI as a collaborative partner. There are a lot of stepwise and iterable prompts that are very effective. The app is meant to refine those flows and the data structures so that only what needs to be in the context actually is for a given prompt.
So I’m just on the road to automating and parameterizing these prompt flows so that rich characters and plotlines can be developed and refined into the beats that a writer can turn into a series of scripts, novels, manga, whatever.
The reason I’m building it is I want to write a series and I need to 10x any part time efforts I can spend on it. I will want to work closely with others to get their take on it, so that’s where the BYOK idea crept in.
I’d previously used an implementation of OpenAI BYOK on Etherscan(which I did not realize at the time was client-side managed), so I just sort of naturally followed the path of least resistance and built a quick implementation for my app so a friend could test with me using his key. The reason for not using cookies/local storage and client managed approach is that I recently read Google is phasing out cookies.
Always happy to help,
I had a look at PlotRocket and must say, it’s a pretty good looking website! The project itself sounds interesting, offering a fresh perspective on how writers can approach episodic fiction. It’s evident that you’re putting a lot of thought into this.
Have you considered setting up a Discord or Discourse forum? This could be an ideal space for a community of writers to share stories, feedback, and experiences using the tool.
On the BYOK front, while I understand your approach, it might be worth considering using GitHub for collaboration. Plus, if there are any specific files or data you’d prefer not to share, you can always utilize the .gitignore feature.
Keep up the awesome work! I’m genuinely excited to see where this goes next.
I know how you feel. I’ve made every effort in my app to secure the api key, and I agree that it is way more secure hidden in my server than transmitted from someone’s browser. But, I think the people here aren’t commenting on the security of your system so much as the rule itself.
Like they say, they don’t make the rules, they just try to help us understand them. Trust me, I am as disappointed as you are about OpenAI’s rejection of BYOK, but it’s the law. At least for now.
Stinks that I will have to be very conservative with early testers.If everyone brought their own key it would help, expense-wise. But that’s ok, it’s how big companies who can’t otherwise build a decent most around their product do. Ensure small players have a hard time entering the market. And seek regulatory capture to fetter their large rivals.
I love the product, but operationally, I’m underimpressed.