We need a glossary to explain what this API does:

AC:

• start a docs folder
• include definitions for: threads, users, api keys, messages, files, tools, embeddings etc.
• include a link to these definitions in the readme

we need a way to send messages to GPT-4

AC:

• create an adapter under the adapter folders
• create the right configuration that reads an API key from env variables
• create a service that will send messages to GPT and accepts a response

You should get rid of those files from git repo.

Description:

In the readme file See the full Contributing guide here here link is not clickable

Validators shoud ping every minute or at a fixed interval each miner to understand the distance to them. This will help them know where to route a demand in order to be sure the subnet edge network is efficient in serving requests.

We need a way to allow users to upload documents. This issue is to research what is possible:

• Documents should be stored in a format that is retrievable by agents.
• Documents should have permissions associated with them. Think of a flexible permission system where users can move documents to different threads or lock it to a specific thread.
• Do we store documents + embeddings or just embeddings?

The subnet being now deployec has the capacity to run queries to llama 2 and mistral 7b. Connec them as a data source in the LLM choice of the akeru API

To be filled when #33 spike is done

The verification object in the layout's metadata helps to make the site have a proper indexing with web crawlers when people look for our website. We would need to obtain keys from google, yandex and yahoo to set this up in the codebase.

According to : https://nextjs.org/docs/app/api-reference/functions/generate-metadata#verification, https://medium.com/@davegray_86804/next-js-how-to-submit-your-sitemap-to-google-36a859c4d114

Problem Statement

1. Based on a previous PR #9, we have managed to introduce the concept of thread runs, where we await for a response based on the content of the thread.
2. We should have the option to stream the answer back to the consumer of the api to accommodate for the slow response time of LLMs.
3. While the adapters are currently generators, we have not supposed streaming over the internet connection yet.

Allowing the agents of the system to be able to get web connectivity to find information is one of the important features here.

We need a way to send messages to GPT-3.5

Acceptance Criteria:

• Create an adapter under the adapter folders.
• Create the right configuration that reads an API key from env variables.
• Create a service that will send messages to GPT and accepts a response.

Currently, only assistants can be created and creating a human user is made from an helper script. Create an endpoint that allows registering users:

AC:

• create a POST endpoint at /users
• Restrict the endpoint to a bearer token.
• restrict who can create a user, validate permissions
• the endpoint should save that user in the database (neo4j)
• the endpoint attaches the right role and permissions to a user (redis)
• the endpoint returns an API key for that user

notes: have a look at existing endpoints and scripts as there are established patterns for this

Description

The README is the first point of interaction for those interested in contributing to Akeru.ai. As the project evolves, ensuring that potential contributors can easily find and access the Contributing Guidelines is essential for fostering community involvement and clarifying contribution processes.

Objectives

• Enhance Navigation: Insert a direct link to the Contributing Guidelines to simplify access for new contributors.
• Clarify Contribution Process: Make it clear how new members can start contributing, emphasizing transparency and ease of access.
• Encourage Community Engagement: By providing clear directions and easy access to the guidelines, we aim to motivate more users to contribute.

Expected Outcomes

• A more navigable README that effectively guides potential contributors to the information they need.
• Increased contributor engagement due to improved clarity and accessibility of contribution resources.

Tags

• documentation
• community

Assignees

• @resourcefulmind

This update is a crucial step towards making our project more open and accessible to new contributors, thereby enhancing our community-driven development approach.

Since adding the subnet to the project, contributing can mean different things. We will start to have contributors to only the UI, only the API, only the subnet or even contributors who want to run the full project from end to end. We need better documentation and guides on how to get started contributing.

Acceptance Criteria:

• Build a contributing section for the UI.
• Build a contributing section for the API.
• Build a contributing section for validator and miner code.
• Host all sections on the contributing page.

We need a basic design for the landing page. We could try our hand at doing it ourselves or we could use some tweaked landing page from the figma community pages

AC:

• basic branding is respected with logo colours
• simple landing page design is done
• show and discuss design with team

As a left over from the subnet template, most configurations options are passed from command line arguments. For easier deployments and decoupling from the validator and miner classes, let's move them into env files instead.

Implement cosine similarity and add to weights to ensure a reputation system

The README file is the first point of interaction for potential users and contributors to Akeru.ai. As the project grows and incorporates more features, it's crucial that the README accurately reflects the capabilities and mission of Akeru.ai, providing clear and engaging content that facilitates understanding and involvement.

Expected Outcomes:

A comprehensive, well-structured README that serves as an effective entry point for engaging new users and contributors.
Enhanced clarity on technical aspects and project roadmap, facilitating easier onboarding and collaboration.

prevent any endpoints on the validator from coming outside the Akeru service layer

• read from authorization Bearer token

AC:

• a user can create a new assistant
• ensure bearer token is present
• create a user with permissions for the assistant (redis)
• create the assistant in neo4j

Context:

• for now don't create relations for files and tools. This will be implemented later

NIBittensorLLM is a decentralied LLM build on top of bittensor. It would be a great alternative to use on sprout to gpt-4 and other close source models.

AC:

• produce a plan to integrate NIBittensorLLM
• investigate the security needs to hold tokens to call the model. Are tokens needed? How can this be platformized
• investigate if we can create an adapter.

Notes:
docs for langchain here:
https://js.langchain.com/docs/integrations/llms/ni_bittensor

For some reason, certain ISPs do not allow the akeru.ai domain, probably because Vercel has been blacklisted. However this solution, by this person can prove to be a viable fix for this situation.

https://twitter.com/0x15f/status/1777762490941591740?t=G-LRnDmt_qxuvAHUixvU-A&s=19

We need a landing page package to host the future website and the dashboard.

Acceptance Criteria:

• Investigate a good Web framework to use. Current discussed options are Astro or Next.js.
• Create a basic package with the framework of choice.
• Get buy-in from team on the choice of framework.

Allow user agents to be able to upload documents and texts to serve as an alternative means to feed in information that the validator needs.

currently we hard code every assistant to use gpt-4. Eventually we want to allow mistral, llama claude and many more.

AC:

• create methods and endpoints to change the model used by an assistant
• modify the create assistant endpoints to allow passing in a specific model
• come up with a sustainable way to keep track of all available models

similar to the cloudflare miner, we should host the validator on a CI/CD pipeline and provider

AC:

• on push to main validator is redeployed
• select a provider,
• should rejoin the test subnet.

The .vscode folder has user-specific settings for VS Code which aren't needed, and by adding .vscode to the .gitignore, we make sure that these settings stay local and don't mess up our repo or cause problems between contributors' local dev environments.

Acceptance Critera:

• Remove the existing.vscode file.
• Make sure that file is not added again in the future.

We need to host a testnet of subtensor on digital ocean to connect our own local dev network and start running our edge network.

We need a way to let an assistant respond to a thread.

Blocked by #8 and #11.

Acceptance Criteria:

• The message endpoint currently is only accepting incoming messages, but does not return assistant messages.
• Call proper LLM adapter to send the old message and receive the answer. (Don't hard code GPT-4 only. Get the model of the thread from the DB and switch on the right adapter if necessary).
• Store the answer in the database.
• Send the answer to the client.
• Explore elysia streams to stream the answer back. Also request a stream from the GPT-4 API if it's not already one.

Description:

There are multiple mistral models available. Their advantage is that they are open source. Let's figure out a cost efficient one to use as an available LLM on sprout:

• figure out if we can self host at a reasonable cost during development
• create the adaptor to a mistral model

The reward function already exists and logic is present. However we need to connect it on a background task so that miners are rewarded

Context

1. We should standardise the role of Assistants with assistant instead of agent as it is what's commonly used in OpenAI's context. It also makes it easier to develop OpenAI Adapters.
2. Add in instructions to be part of Assistants to give Assistants more context on what they should do.
3. Add in model to be part of Assistants to allow for adaptive LLM model usage.

From the backend's codebase find a way of connecting to the hosted validator to make requests needed,

When on certain mobile screens, the background of the button has the same color as the gradient section of the page's background such that it fades in together and becomes unnoticeable. This is an accessibility issue:

Overview

We currently do not have a pull request template for our repository. Adding a template would help streamline the pull request process by ensuring key information is included.

Tasks

• Create .github/PULL_REQUEST_TEMPLATE.md file
• Add the following suggested sections:
  • Description of changes
  • Related issues
  • Testing done
  • Screenshots (if applicable)

As left overs from the subnet template we have inherited a lot of technical dept of a coding style that is far from our own. Let's clean up the OOP patterns. We can keep some of them but inheritance is overly done for our style and offuscates the real functionalities of the code. Let's move closer to a functional style

We will need soon to create dashboard UIs, a landing page etc. currently sprout is a backend only application. This issue is to move to a monorepo setup.

Acceptance Criteria:

• explore bun support for monorepos
• move the current code to a package under a mono repo
• update the readme properly
• create scripts at the top level to start the project quickly.

Currentl calling the chat endpoint on validators results in a 5-10 second delay since the LLM workload is slow. We should implement streaming methods that are equivalent in both the miner and the validator to let them act closer to the open AI API

Due to the most recent release, by the Elysiajs framework for our backend we have to refactor some of the backend code to cater to this:

elysiajs/elysia#513

Checkout Akeru Server: https://github.com/GuiBibeau/akeru/tree/main/packages/akeru-server

Create a miner similar to the cloudflare miner but one that let's people run their own models and provide them to the edge nertwork:

• new package is added called ollama-worker
• give a first option of what people can host that would be easy
• prorotype joining a network on a local test net

right now we allow communication using a bearer token. This works for a while but eventually we need to move away from hard coded secrets to instead use something more formal like an allow list mechanisms.

We need to setup the frontend scaffold for the entire application.

We already decided to setup a few things in the codebase like app router and tailwind, but we would be doing a few things with streaming and a few other stuff that I think @GuiBibeau will be positioned to handle.

As of now, we only have this design to get our landing page and get inspiration for our waitlist page:

https://www.figma.com/file/B8cYeNpdAvfezzrzm0AqEk/Sprout?type=design&node-id=0-1&mode=design&t=Y0Qgfc6PWy5iL9go-0

A few things to consider when scaffolding:

• Documentation
• i18n
• Performance
• Places where we'll need RSCs

I hope this issue write-up isn't too amateurish.

there should be an endpoint to send a message to an assistant.

AC:

• the endpoint should be protected by a bearer token
• Ensure the user has the right permissions to send a message to the conversation
• ensure the last message is not from a human user, the AI should have time to respond before another message is sent
• Save the message
• return from the endpoint a simple success message. This will be updated later.

We need to host a test digital ocean miner on a hosted platform.

AC:

• pipeline redeploys the code every time a commit to main is done
• the miner should restart on a new deployment
• select a proper hosting provider

Since a few merges, test are not passing. Fix those

From the server's codebase, functions that will call different LLMs need to start being implemented and worked on.