Das ist außerdem genau etwas was wir mit Clye anbieten können (whitelabels)
https://www.youtube.com/watch?v=4RORE0MpCccAktuell ist es noch nur eine App mit der man Chatten oder sprechen kann, aber langfristig wird OpenAI zum multiagent system das über die perönlichen devices zugänglich ist und dann im Nahmen des Nutzers handelt. Das geht von Reise planen, emails schreiben bis Finanzen verwalten, Versicherungen vorschlagen, ...
Dazu sind auch die CustomGPTs sinnig. Diese sind die Anbindung an andere APIs und versehen diese mit einer Sprachschnittstelle die natürlich nicht nur Menschen, sondern auch OpenAI selbst nutzen kann. Damit ist es für OpenAI möglich mit allen möglichen services zu interagieren basierend auf der ChatGPT gewohnten Schnittstelle.
Das Interface wird erweitert werden um grafische Anzeigemöglichkeiten die in den Voice chat itegriert sind. Damit wird es faktisch nicht nötig sein eine andere App zu benutzten da die KI einem das anzeigen wird was einen interessiert und man einfach mit ihr sprechen oder schreiben kann. Das UI wird wahrscheinlich auch in eine art Store Konzept integriert und teils automatisch generiert, teils in Form von web widgets geladen und kann so z.B. Wetter anzeigen, ... da Sprache nicht immer der effizienteste Weg ist.
In Konsequenz erlaubt es nur Unterhaltungsapps wie z.B. Speile die Koexsistenz und zu nahezu allem anderen wird es das Interface (über Custom GPTs und Custom Widgets). Entsprechend kann man sich nur langfristig behaupten wenn man Integrierte Systeme anbietet, UX optimiert, Plattformen betreibt oder offline Geschäffte macht (solange all das nicht von Robotern erledigt werden kann).
Disclaimer: Das sind alles nur meine Überlegungen und ich erhebe keinen Anspruch auf Richtigkeit
Um in deiner App Informationen zu erhalten wenn in Clye etwas passiert können Webhooks registriert werden. Das bedeutet diese URL werden von Clye mit den entsprechenden Daten aufgerufen. Somit können gezielt bestimmte Aktionen ausgelöst werden. Das schema ist auch in der swagger doku als SpaceEvent schema definiert. Sollten Webhooks nicht funktionieren, also diese einen anderen Status als 200 zurück geben, wird der webhook nach einer kurzen Verzögerung nochmal aufgerufen. Dieser Vorgang wird maximal 3 mal mit zunehmender Zeit wiederholt.
Webhooks können in den Einstellungen registriert und getestet werden.
Clye kann nicht nur unterscheiden ob eine Person online oder offline ist. Sondern es ist auch möglich z.B. die Präsenz an einem Ort oder andere Zustandsinformationen für ein Profil zu setzen. Dafür muss lediglich der Status des Profils gesetzt werden. Dafür gibt es einen in der swagger doku ein endpoint /profiles/{id}/status
Link der das Einmalige Anmelden und Beitreten in vorher ausgewählte spaces ermöglicht. Die unter diesem Link angezeigte Seite erlaubt je nach Zustand unterschiedliche Aktionen.
Nutzer können von jedem Admin eines Spaces aus dem Space entfernt werden. Dafür kann ein API key eines Admins des Spaces genutzt werden. Der endpoint DELETE /spaces/{id}/members/{memberId} ist in der swagger doku zu finden.
Neue Benutzer so wie Einladungen zu Spaces können über die API erzeugt werden. Dabei muss beim Aufruf angegeben werden in welche Spaces der neue Nutzer mit welcher Rolle beitreten soll. Daraufhin wird ein Einladungslink erzeugt der genau das ermöglicht.
Der Endpoint dafür ist POST /invites und die zurück gegebene URL kann noch mit Search parameter erweitert werden um Informationen über den Nutzer zu ergeänzen wie z.B. Name oder Email. Die resultierende URL ist dann https://clye.app/invites/TAOSDJFAOSDF?name=Simon+Vetter&email=simon.vetter@clye.app. Dieser link erlaubt dann für eine Person die Registrierung auf dieser Seite und verlinkt danach zu dieser Person.
Für die Clye Codebase haben wir kürzlich von MUI zu Tailwind umgestellt. Dabei sollten all sx properties zu tailwind klassen umgewandelt werden. Diese aufgabe ist zu kompliziert um sie mit regexp zu erledigen, aber auch nicht sehr schwierig da es ohne Verständnis der Codebase möglich ist. Da es aber über 500 Stellen in der Codebase gibt habe ich den Task mit einem kleinen script automatisiert und alle Zeilen die verändert werden müssen mittels OpenAI Chat api modifiziert. Leider sind die Ergebnisse ohne gute Beschreibung miserabel. Es weiß nicht das man z.B. Pixelwerte nicht einfach so setzen kann sonder brackets benutzen muss. Einiges davon ließ sich allerdings mit einem besseren prompt erledigen.
Darüber hinausgehen sind die Ergebnisse aber leider so unzuverlässig das man alles überprüfen muss. Außerdem braucht es ewig die Vorschläge zu erzeugen und verschachtelte Queries habe ich garnicht zuverlässig zum Laufen bekommen. Deshalb spart es nahezu keine Zeit und wenn man das schreiben und Verifizieren des Prompts mit einrechnet kostet es in diesem Scale mehr Zeit die AI zu nutzen als es von Hand und mit Find and replace zu machen.
Irgendwie war mein implizite anname das es schneller wäre einfach HTTP request zu machen als NATS zu benutzen. Ich habe komplett übersehen das ja auch bei HTTP requests in Kubernetes ein Load-Balencer dazwischen ist.
Um das zu testen habe ich ein kleines benchmark gemacht das jeweils 1000 request über nats und über http macht. Dabei ist der payload identisch. Das Resultat ist:
{"http":"2.319668433s","nats":"994.679073ms"}Daraus folgt das NATS sogar effizienter ist als es über HTTP zu machen und deshalb steht einer Nutzung von NATS für APIs nichts entgegen zumal das außerdem mit einer Reihe Vorteile kommt