Vue.js Developer for AI Application Frontend
Budget: €12 – €18 EUR
We are seeking an experienced Vue.js developer to create a frontend for our propriatary AI Application API, which is similar in functionality to ChatGPT.
This application will serve as a foundational template for a wide array of custom AI solutions we create for our clients. As such, we place a strong emphasis on:
* Modularity: Ensuring components are reusable and easily adaptable for various client needs. Theming and multi-language support is required.
* Clean Code: Maintaining high standards of code quality, readability, and maintainability.
* Security: Implementing robust security measures, with a particular focus on XSS protection and other common web vulnerabilities.
----------
This project is split into multiple parts of which this is the first.
If our collaboration proofs to work, more tasks will follow.
The estimated budget for this task is 15 - 20 hours.
----------
Task 1: Chat Protocol View View Model
The application protocol (aka **chat history**) captures all interactions between a user and an application within a single session (chat). To accomodate for message editing, regeneration, and the ability
to follow up a conversations from any previous message version, the protocol is structured as a tree of nodes
rather than a simple sequence of messages. Each node in the tree represents either a UserMessage (originating
from the user) or an AssistantMessage (generated by the application). Every node contains a single message and
maintains a reference to its parent node, which represents the previous message in that particular conversation
thread. The tree structure allows for multiple conversation branches to coexist. Applications (aka *chat bots*) work with a particular conversation strain (thread) rather than the entire protocol tree.
The application that is to be build shall always show a single thread. A thread is determined by a single leave node (a message that has no successor). Each message provides the functionality to skip through its versions (nodes with the same parent). By choosing a version the entire upstream thread (messages older than the version choosen) is determied. For downstream nodes the respective newest version is choosen.
> see attached screenshot.
The view model shall provide functionality
* to access a thread from each node/message of the protocol.
* to add, modifym and remove nodes from the protocol. (removing nodes cascades to all downstream nodes).
The protocols API endpoint provides functionality to list, store, retrieve application protocols. For this task the protocol can be mocked with static dummy data.
Example Protocol
see attachment
Notes:
* citations, context, and progress can be ignored within the scope of this task.
* ids are always UUIDs (with the exception of application_id)
* timestamps are always in UTC
This application will serve as a foundational template for a wide array of custom AI solutions we create for our clients. As such, we place a strong emphasis on:
* Modularity: Ensuring components are reusable and easily adaptable for various client needs. Theming and multi-language support is required.
* Clean Code: Maintaining high standards of code quality, readability, and maintainability.
* Security: Implementing robust security measures, with a particular focus on XSS protection and other common web vulnerabilities.
----------
This project is split into multiple parts of which this is the first.
If our collaboration proofs to work, more tasks will follow.
The estimated budget for this task is 15 - 20 hours.
----------
Task 1: Chat Protocol View View Model
The application protocol (aka **chat history**) captures all interactions between a user and an application within a single session (chat). To accomodate for message editing, regeneration, and the ability
to follow up a conversations from any previous message version, the protocol is structured as a tree of nodes
rather than a simple sequence of messages. Each node in the tree represents either a UserMessage (originating
from the user) or an AssistantMessage (generated by the application). Every node contains a single message and
maintains a reference to its parent node, which represents the previous message in that particular conversation
thread. The tree structure allows for multiple conversation branches to coexist. Applications (aka *chat bots*) work with a particular conversation strain (thread) rather than the entire protocol tree.
The application that is to be build shall always show a single thread. A thread is determined by a single leave node (a message that has no successor). Each message provides the functionality to skip through its versions (nodes with the same parent). By choosing a version the entire upstream thread (messages older than the version choosen) is determied. For downstream nodes the respective newest version is choosen.
> see attached screenshot.
The view model shall provide functionality
* to access a thread from each node/message of the protocol.
* to add, modifym and remove nodes from the protocol. (removing nodes cascades to all downstream nodes).
The protocols API endpoint provides functionality to list, store, retrieve application protocols. For this task the protocol can be mocked with static dummy data.
Example Protocol
see attachment
Notes:
* citations, context, and progress can be ignored within the scope of this task.
* ids are always UUIDs (with the exception of application_id)
* timestamps are always in UTC