Sharing the data among various plugins was not a good idea in the first place. The security hole is as big as a black hole, and there is no easy way to deal with that. Even if there is a way technically, that would confuse an average user, who would share the sensitive data inadvertently. Take a look at the security risk I presented earlier.
Now, the GPTs have addressed all sorts of plugin problems (security, context, multimodality, code execution, external resources, etc.)
The only missing feature is that I haven’t got any time to jump for joy, because I have been glued to my computer screen to read/watch everything since the dev conference.
I think this is within the domain of a booking GPT. Let say we have a hypothetical GPT, FlyMeGPT. Its capabilities would include booking flights, recommending hotels, and suggesting itineraries based on a given location. It could also propose suitable dates for travel based on the desired activities, season, or weather conditions at the destination.
Now, if you ask it questions about the stock market, naturally it is out of the scope of its domain and I think it is fine not to be able to answer it.
Well Actions are supposed to be connected to an abstraction/interface API tailored to your GPT where your API action(s) do what you want it to do in one call instead of multiple action calls - it would increase latency massively because of the processing overhead of transforming inputs from previous results, then waiting for the task result, and then transforming that result again into output
I couldnt disagree more. The entire POINT of plugins and functions is to combine multiple external sources of data into one experience. If it was actually for security purposes, then they wouldn’t let you call multiple functions with the API.
You do realize that “Sharing data among various plugins” is literally happening with any GPT having access to the web right? lol.
Yes, your use case is legit, and the GPT supports that dearly. Take your FlyMeGPT as an example. It could use Weather1, Weather2, Weather3, …, Weather100. The obsolete plugin architecture could route your prompts according to its “best” judgment, say, Weather2 against your will (Weather3). Now, the GPT architecture delegates that decision to you (the GPT publisher.) That is a very good decision.
The users of your FlyMeGPT establish the explicit trust relationship with you and implicit trust relationship with the Weather3.
Even if the AGI is here now, you would still probably not want to use its free will to override your free will. The logic of that explicit/implicit trust relationship will remain until the end of the world, with or without AGI.
Don’t be misled by some conceptually wrong arguments here. “Sharing data” and “having access to the web” are two different concepts. Misunderstanding their distinction will be harmful for your design. Both “sharing” and “access to the web” are essential, but how to do them properly is the question. The GPT is the answer.
The plugin architecture isn’t obsolete. OpenAPI specs aren’t deprecated lol. Plus the background function calling is the still the exact same framework with the same response and input format.
Can you explain what you mean by “Against your will”? Any user that signs up for a plugin/action server is consenting to use the services offered.
Guys… no. ChatGPT has ALWAYS made the decision on what endpoints to call based on our manifests and endpoint descriptions. The GPT framework is no different, they simply host the OpenAPI spec. Plugins and actions have been and are just an external API that interfaces with ChatGPT’s API.
No one in this thread has conflated those terms. Again…GPTs haven’t ultimately changed much about the relationship between our back-ends and ChatGPT. This is mostly a coat of paint.
Back to that actual issue being discussed here: You actually cannot add multiple API servers into a OpenAPI Spec unless you handle all the routing on your back-end and change your spec. Previously we could have 3 different plugins at the same time, and didnt need to manage the routing at all.
So this appears to be one little step forward and one major step back for the plugin community. Sure they host the spec…but they took away the one-convo, multimodal plugin UX for third-party actions.
This is spot on! The issue is you no longer have that ability to use all of your separate “tools” together in a specific workflow. You depend on GPT developers to include all of the potential actions within a GPT that you might need for your use-case (which is going to result in a lot of bloated GPTs that don’t do any one thing well or try to do too much).
That said, I’m still pretty bullish on GPTs. I just wish they would keep plugins around or rebrand them as actions and integrate them by allowing you to create metaGPTs or something.
And agree the whole privacy argument is off. You explicitly consent to your data being used by the fact that you installed / enabled different plugins and use them together. Also there are now controls in place that specifically ask you if you are okay sending specific data.