Forem: UEDA Akira

Practical Guide to Developing a ChatGPT Plugin: A Case Study of Sakenowa

UEDA Akira — Mon, 29 May 2023 09:30:00 +0000

We've just released the Sakenowa ChatGPT plugin. It's a plugin that utilizes data from Sakenowa to provide detailed information about different brands of Japanese sake and offer recommendations.

This article shares the challenges, insights, and developer perspectives we encountered during the development of the ChatGPT plugin. We hope this can be of help to those planning to embark on their own development journey.

Local Development

During development, it's okay to deploy the API server in your local environment.

In a production environment, ChatGPT's server communicates with the API server as follows:

In a local environment, the browser communicates directly:

Because the browser communicates with the API server from the ChatGPT page (chat.openai.com), it is necessary to set up CORS on the API server.

Authentication

The authentication method for the API server is specified in the manifest file (ai-plugin.json). In the Sakenowa ChatGPT plugin, we used service_http. A pre-registered key is set as a Bearer token in the Authorization header, which you can confirm on the API side.

Example of an Authorization header:

Authorization: Bearer <API-KEY>

The key is registered during the plugin application process.

Manifest File

The manifest file (ai-plugin.json) needs to be deployed as /.well-known/ai-plugin.json on the public server.

There are people who have compiled various plugin manifest files and API specification files: https://github.com/sisbell/chatgpt-plugin-store

As can be seen here, most plugins are accessible to anyone. However, as long as the plugin can be accessed from the ChatGPT server, it's sufficient, and access can be restricted. The range of IP addresses used by ChatGPT's server is listed in the ChatGPT plugin documentation.

According to ChatGPT's Plugin devtools, the description_for_model value in the manifest file is embedded directly into the prompt, so there's little point in hiding it. There's no guarantee that other parts of the manifest file won't be embedded in the future. You should only include information in the manifest file that you are willing to make public.

By the way, the part embedded in the prompt can be answered by asking ChatGPT. The Sakenowa ChatGPT plugin doesn't publicly release its manifest file, but ChatGPT can provide the information.

API Specification File

According to ChatGPT Plugin devtools, the contents of the API specification file are converted to TypeScript and embedded into the prompt. For the Sakenowa ChatGPT plugin, the content is embedded as follows (slightly abbreviated):

namespace sakenowa {
// Search brands by query
type search__brands = (_: {
// query string that will match with brand name. Can be Japanese name (Kanji or Hiragana), English name and also part of them.
brand?: string,
// search by area. It should be official Japanese prefecture numbers
area?: number[],
)} => any;
} // namespace sakenowa

While the return type is defined in the API specification file and should be an essential piece of information for selecting the optimal endpoint, it is set to any here. Even though array length limitations are specified in the API specification file, they don't appear here. However, the description values seem to be output as comments, so it may be beneficial to write information here.

This format suggests that information like the API server's URL won't be embedded in the prompt. But, as the future is uncertain, you need to treat it as potentially public. Also, access can be restricted to only ChatGPT's server by specifying an IP address range.

Going Public! How to Get Users?

As of May 29, 2023, the review process is stated to be completed within seven days after application. The Sakenowa ChatGPT plugin took exactly seven days.

After going public, we issued a press release. Typically, for a smartphone app, we would provide the store's URL for users to access it directly. However, the ChatGPT plugin store does not have a URL. Additionally, since there is no search function, users will need to locate the plugin from a list that spans approximately 20 pages. We anticipate improvements in this area soon.

Re-verification

If you change the manifest file after the plugin has been approved and listed in the store, it will be removed from the store and re-verification will be required. From what I've heard, the current situation is as follows:

Even if the plugin is removed from the store, users who are already using it can continue to do so.
The time it takes for re-verification varies, sometimes it's three days, but other times it can take up to a week.

This issue is being discussed in OpenAI's forum, so I believe it will be improved eventually. However, for now, you need to understand that changing the manifest file after release is a challenging task.

Conclusion

The official documentation for ChatGPT plugin development is well-written, so you're unlikely to struggle due to a lack of information. However, there are difficulties that developers may encounter, such as the re-verification process after going public.

In this article, I've shared knowledge and experience gained during the development of the Sakenowa ChatGPT plugin. I hope this can serve as a supplement to the official documentation, and prove useful for those about to develop a ChatGPT plugin.

8 Tips for Creating a Native Look and Feel in Tauri Applications

UEDA Akira — Fri, 07 Oct 2022 11:31:25 +0000

I recently released Jomai, a Markdown-focused desktop search app made in Tauri.
Apps made with Tauri is, of course, native app. But its UI part runs on WebView, so its look and feel tend to be like a web app. I designed Jomai to behave as much as possible like a native app, so I will summarize that here.
Jomai is currently available only for macOS, so this article is also intended for macOS.

Environment:

Tauri: 1.1.1
Platform: macOS

Get rid of the beep sound on keystrokes for non-input
Make text in UI not selectable
Set mouse cursor to default
Do not scroll the entire screen
Suppress bounce scrolling across the screen
Prepare your own menu
Prepare your own keyboard shortcuts
Support dark mode

Get rid of the beep sound on keystrokes for non-input fields

A beep sounds when keystrokes are made while the focus is on a non-input item other than <input> or <textarea>. This issue occurs in WebView on macOS and has a GitHub issue, which has not been resolved as of October 6, 2022.
https://github.com/tauri-apps/tauri/issues/2626

You can suppress the beep sound by calling preventDefault() on keydown event, but this will also disable all input to <input>, etc., so it is necessary to suppress it selectively.

Jomai uses the following code.

export const useKey = (callback: UseKeyCallback) => {
  const onKeydown = useCallback(
    (event: KeyboardEvent) => {
　　　 // callback should return true if processed
      const consumed = callback(event.code, {
        ctrl: event.ctrlKey,
        shift: event.shiftKey,
      });

      const e = event.composedPath()[0];
      if (
        !(e instanceof HTMLInputElement || e instanceof HTMLAreaElement)
        || consumed
      ) {
        // preventDefault() if it is not an input item
        // also preventDefault() if it was handled by a callback
        applyBeepSoundWorkaround(event);
      }
    },
    [callback],
  );

  useEffect(() => {
    window.addEventListener('keydown', onKeydown);
    return () => {
      window.removeEventListener('keydown', onKeydown);
    };
  }, [onKeydown]);
};

It solves most cases of the problem to call preventDefault() if the event source is not an HTMLInputElement or HTMLAreaEelement. However, when the focus is on one of these input items and the keyboard shortcut is used to move the focus to a non-input item (yes, it isn't very easy), there will be the sound. So I've done more to fix the problem.

Make text in UI not selectable

While it is normal to be able to select text on a web page, this is generally not the case in native apps. To avoid unintentional text selection when trying to manipulate the UI, use user-select: none at the base of DOM elements such as <body>.

body {
  user-select: none;
}

Set mouse cursor to `default`

Since the previous section has limited the operation of UI elements to button pressing, etc., let's express it that way for the mouse cursor as well.

body {
  cursor: default;
}

cursor: default prevents I-beam when hovering text, for example. The cursor attribute should be explicitly specified if the UI element is manipulatable, such as a button.

button {
  cursor: pointer;
}

Do not scroll the entire screen

When content is larger than the size of the screen, it's usual for web pages to scroll the entire screen. In native apps, it is natural to display fixed UI components and make only some scrollable.

In Jomai, tabs and forms at the top of the screen are always visible, and only the content part at the bottom is scrollable.

See it in action.

To achieve this, set overflow: hidden for the entire screen, and set overflow: scroll and height for the scrollable area.

.page {
  overflow: hidden;
}

.contents {
  overflow: scroll;
  height: calc(100vh - 40px)
}

Suppress bounce scrolling across the screen

Bounce scrolling is that thing that makes a spring-like motion when scrolling to the edge of the screen. By default, the entire screen is scrollable with the bounce motion. See this video.

Bounce scrolling is associated with scrollability, so it should be suppressed if the entire screen should not be scrollable.

body {
  overflow: hidden;
}

Prepare your own menu

Tauri provides a basic menu by default.

If you need customization, you will need to build these menus yourself, which is a bit tedious. See tauri::Menu::os_default for reference.

Prepare your own keyboard shortcuts

Be careful when using your own keyboard shortcuts on web pages, as they can confuse users, but be proactive about introducing them in native apps.

Support dark mode

I am a fan of dark mode and would like to see dark mode support in apps I use regularly.
Tauri has appWindow.theme() to get the current theme and appWindow.onThemeChanged() to monitor change events. Using these, you can change the app to match the OS theme settings.

Here is an example implementation in React.

import { appWindow, Theme } from '@tauri-apps/api/window';

export const useTheme = () => {
  const [theme, setTheme] = useState<'light' | 'dark'>('light');

  useEffect(() => {
    let unlisten: UnlistenFn | undefined;

    (async () => {
      setTheme(await appWindow.theme());

      unlisten = await appWindow.onThemeChanged(({ payload: theme }) => {
        console.log(`theme changed to ${theme}`);
        setTheme(theme);
      });
    })();

    return () => {
      if (unlisten != null) {
        unlisten();
      }
    };
  }, []);

  return theme;
};

Summary

In this article, I have introduced some tips to make Tauri-made apps more native-like. A little effort will improve the usability of your apps. I hope you find them helpful.

Overall, developing with Tauri has been a great experience, and I look forward to creating many more apps with Tauri.

Please also check out Jomai, which I'm developing using these techniques.