Authentication options on behalf of a user

Well, again, as has already been said, BYOK isn’t really what OpenAI has in mind for their services.

API keys are for developers—not consumers—so the best path forward is to set up a billing system and use your own key.

Why wouldn’t you just charge your own fee and make the calls using your own secure line with your own API keys?

If you don’t have a tracking system for usage I would never want to put any of my credentials or keys on it.

I don’t understand this mentality. It’s like building a house and not putting any gas meters because … What? You don’t want to? If you are a good dev your work will be paid for. Spend more effort!

There’s two people in the digital world. Those who have been hacked, and those that don’t know. Extreme, but hopefully you get the point. If you aren’t measuring anything you are an easy target

If you decide to “host” the keys I hope you have enough money to pay your lawyers. You’re taking on an incredible amount of risk for no reason, at the expense of your users.

To me that’s just bad business.

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.

1 Like

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.

2 Likes

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. :man_shrugging:

1 Like

Thanks for the suggestion, the repo is private on GitHub but hosting is via Firebase, a solution I’ve used for years and am happy with the security of.

1 Like

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. :blush:

2 Likes

If you are running your function through Firebase Cloud you can filter the logs to meter everything (they log all your calls). I also am guilty of sometimes releasing software without metering it :face_with_open_eyes_and_hand_over_mouth:

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.

I think the main idea being that ChatGPT is for consumers and the API is for developers.

OpenAI doesn’t seem interested in being the long-term backend provider for enterprise services—that’s what Microsoft Azure is for.

Their primary purpose seems to be around developing the models and building an ecosystem around them, not in hosting scalable infrastructure, and I tend to think that’s a good thing.

Ayup. Already refactored and moved on.

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.

:sweat_smile:

That’s not what’s happening here, but okay.

¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

You just want OpenAI to handle your billing for you.

If you want a collaborative effort then open-source your project.

To me it seems like you eventually want to commercialize this product. Nothing wrong unless you are purposely hiding this fact behind “this is a personal passion project”.

You don’t need to be conservative with your beta testers. You are choosing to be so.

I have products of my own released that I pay using my own API key because

A) I want to attract people to the service
B) It’s closed-source and completely inconsiderate to ask people to use their private API keys for it (Not to mention probably against OpenAI policy)
C) I am benefitting from seeing how they use the product

And I’m cheap. Cheap cheap :hatched_chick:. I am hosting the knowledge graph portion on my own PC just so I don’t have to pay for a server.

I like your idea though. I wish there was more substance in your website. How are you ensuring coherency throughout the story?

You just want OpenAI to handle your billing for you.

Yes, Absa-frickin-lutly correct. I would like for people to use their API keys to hit the OpenAI API via my app. Right now, I get one day a week to work on it, and I don’t want to spend that time building a billing system. So sue me.

If you want a collaborative effort then open-source your project.

I understand how open source works. I created a framework that’s been ported to 17 different programming languages by the community. This project is not ready to be opened up yet.

To me it seems like you eventually want to commercialize this product. Nothing wrong unless you are purposely hiding this fact behind “this is a personal passion project”.

It IS both a passion project AND something I eventually want to commercialize. Passion now, commercialization MUCH later. And not necessarily via the “Pay me 50 bucks a month” business strategy. It’s actually more akin to the James Patterson co-authoring strategy.

You don’t need to be conservative with your beta testers. You are choosing to be so.

Pre-alpha would be a better categorization, and yes, I do need to be conservative, because all their activity goes against my account.

I have products of my own released that I pay using my own API key because

Lovely, I’m so proud of you.

I like your idea though. I wish there was more substance in your website. How are you ensuring coherency throughout the story?

That’s actually explained in a post on my insubstantial website:

My plan for managing continuity is to take all two scene combinations of one or more episodes and feed them to a prompt that looks for continuity problems. E.g., in one scene the room is on fire and in the next scene at that location, there’s no sign of damage.

I don’t intend to be demeaning or place myself above you. Nor am I looking for you to be proud.

It seems like you have set yourself on one path and won’t move unless shoved. I hope everything works out for you.

It’s okay mate, these things are not mutually exclusive

Small question: do you plan on commercializing the app itself or the stories you make with it?

You’re going to end up with zero users when OpenAI terminates all of the accounts with APIs used through your service, see: janitor.ai.

What have I done that makes you think I need to be shoved? Or that I’m on a path I shouldn’t be on? I’ve refactored my app to use my own API key. No one needs to shove me. WtF?

Small question: do you plan on commercializing the app itself or the stories you make with it?

Both.