[RIP00028] YAM Community API (Dev Competition)

LoganSulpizio

[Developer Competition] YAM Community API

🇫🇷 Version francophone en deuxième partie de message

Summary

I propose the development of a YAM Community API, an off-chain indexing service that will store and expose all past and present YAM events. This API will help the community developers, enabling them to easily retrieve transaction history for reporting, statistics, dashboards, and other applications.

Objective

Currently, there is no built-in way to access past transactions or historical data about offers on YAM. External solutions like The Graph exist but they are often not easily flexible and not always reliable. This project aims to solve that issue by creating a fully indexed API that records all YAM-related events and transactions, making them easily accessible to the community.

By providing this API, developers will no longer need to worry about how to retrieve historical YAM data. Instead, they can focus on building valuable applications such as analytics tools, portfolio trackers, automated reporting systems, and more.

How it works?

The YAM Community API will be a publicly available web service (access might be limited to developers that have requested a token like the existing realtokens community API). Developers and users will be able to query this YAM Community API to retrieve detailed information about past YAM transactions and events.

The API will continuously index and store all YAM transactions, ensuring a complete and accurate historical record.
It will be off-chain, meaning that it does not rely on the YAM smart contracts but instead maintains a dedicated database to store the indexed data.
Developers will be able to query the API via simple endpoints to retrieve transaction history, past/present offers, and other relevant YAM data.

Application Architecture

The application will be structured into three main components:

Transaction Indexing Module
A dedicated module responsible for tracking and indexing all YAM transactions and events. This ensures that past offers and historical transaction data remain accessible, unlike the YAM on-chain smart contract that only retains the current status of any offers.
Data Retrieval Engine
This module will process queries efficiently, allowing users to fetch historical YAM data based on filters such as wallet address, realtokens address, time range, and transaction type.
Public API
A set of well-documented API endpoints that developers can use to integrate YAM transaction history into their applications, dashboards, or reports.

Available Endpoints

The YAM Community API will provide the following endpoints to facilitate access to historical transaction data and offer-related events:

Note: The following endpoints provide an overview of the planned API functionality. Some adjustments may be made during development to account for technical considerations or community feedback from forum discussions.

Retrieve all events for a specific offer ID
Returns the complete event history (creation, purchases, updates, deletions) associated with a given offer ID.
Retrieve all events for a specific seller within a given time frame
Returns all recorded events for any offer linked to a seller over a specified period. Optionally, results can be filtered by event type (offer creation, modification, or deletion).
Retrieve all offer IDs associated with a specific seller within a given time frame
Returns the IDs list of all offers created by a seller during the specified period.
Retrieve all active offer IDs for a given seller
Returns the ID list of all currently active offers from a seller. Active offers are those that have not been sold out or deleted.
Retrieve all events (creation, modification, purchase, deletion) for active offers of a given seller
Returns the history of all modifications and status changes for currently active offers associated with a seller.
Retrieve all purchase events for a specific buyer within a given time frame
Returns a list of all transactions where a given buyer has purchased RealTokens during the specified period.
Retrieve all purchase events for a specific RealToken within a given time frame
Returns all purchase transactions related to a particular RealToken over the specified period.

Development timeline

The development timeline for this project aligns with the competition requirements, with an estimated completion time of 1 to 2 months. The initial version will focus on indexing transactions and exposing essential endpoints for data retrieval. Additional endpoints could be implemented based on community feedback and developer needs.

About Me

As a frequent RealToken investor passionate about blockchain and tech, I understand the challenges of tracking YAM transactions and historical data. This API is something that I wish existed, and I’m excited to build it for the community.

One of my previous projects includes developing the Telegram bot The YAMSaleNotifyBot, which has sent over 10,000 notifications to RealToken users keeping them informed whenever one of their YAM offers has been bought. I am committed to enhancing the RealToken and YAM ecosystem by building tools that improve transparency and usability.

Additionally, I am an application engineer working in a Belgian tech company, which allows me to bring professional expertise to the development of reliable and efficient solutions for the community.

=====================================================

🇫🇷 [Concours pour développeurs] API Communautaire YAM

Résumé

Je propose le développement d'une API Communautaire YAM, un service d'indexation off-chain qui stockera et exposera tous les événements passés du YAM. Cette API facilitera le travail des développeurs de la communauté en leur permettant de récupérer facilement l’historique des transactions pour des besoins de reporting, statistiques, tableaux de bord, et autres applications.

Objectif

Actuellement, il n’existe aucun moyen simple d’accéder aux données historiques aux actuelles du YAM. Des solutions externes comme The Graph existent, mais elles sont souvent peu flexibles et pas toujours fiables.

Ce projet vise à résoudre ce problème en créant une API qui enregistre tous les événements et transactions liés au YAM, les rendant facilement accessibles à la communauté.

Grâce à cette API, les développeurs n’auront plus à se soucier de la récupération des données du YAM (données historiques ou offres en cours). Ils pourront se concentrer sur la création d’outils utiles tels que des outils d’analyse, des trackers de portefeuille, des systèmes de reporting automatisés, etc.

Comment ça fonctionne ?

L’API Communautaire YAM sera un service web accessible publiquement (l’accès pourrait être limité aux développeurs ayant demandé un token, comme pour l’API communautaire de RealTokens). Les développeurs et utilisateurs pourront interroger cette API pour obtenir des informations détaillées sur les transactions et événements passés du YAM.

L’API indexera et stockera en continu toutes les transactions YAM, garantissant un enregistrement complet et précis de l’historique.
Elle fonctionnera hors-chaîne, c’est-à-dire sans dépendre directement des smart contracts YAM, en maintenant une base de données dédiée.
Les développeurs pourront interroger l’API via des endpoints simples pour récupérer l’historique des transactions, les offres passées/actuelles, et d’autres données pertinentes.

Architecture de l'application

L’application sera structurée autour de trois composants principaux :

Module d’indexation des transactions
Un module dédié au suivi et à l’indexation de toutes les transactions et événements YAM. Il garantit que les offres passées et les données historiques restent accessibles, contrairement au smart contract YAM on-chain qui ne conserve que l’état actuel.
Moteur de récupération des données
Ce module traitera les requêtes efficacement, permettant aux utilisateurs d’obtenir les données historiques en fonction de filtres (adresse de portefeuille, adresse RealToken, plage temporelle, type de transaction, etc.).
API publique
Une série d’endpoints bien documentés que les développeurs pourront utiliser pour intégrer l’historique YAM dans leurs applications, dashboards ou rapports.

Endpoints disponibles

L’API Communautaire YAM proposera les endpoints suivants pour faciliter l’accès aux données historiques de transactions et événements liés aux offres :

Remarque : ces endpoints donnent une vue d’ensemble des fonctionnalités prévues. Certains ajustements pourront être faits pendant le développement selon les contraintes techniques ou les retours de la communauté sur le forum.

Récupérer tous les événements pour un offer ID spécifique
Retourne l’historique complet (création, achats, modifications, suppressions) associé à un offer ID donné.
Récupérer tous les événements d’un vendeur donné sur une période donnée
Retourne tous les événements enregistrés liés à un vendeur sur une période spécifiée. Filtrage possible par type d’événement (création, modification, suppression).
Récupérer tous les offers ID associés à un vendeur sur une période donnée
Retourne la liste des offers ID créées par un vendeur pendant la période spécifiée.
Récupérer tous les offers ID actives d’un vendeur
Retourne la liste des offres actuellement actives (ni sold-out, ni supprimées) d’un vendeur.
Récupérer tous les événements pour les offres actives d’un vendeur
Retourne l’historique des modifications et changements de statut des offres actives d’un vendeur.
Récupérer tous les achats d’un acheteur sur une période donnée
Retourne la liste des transactions où un acheteur a acquis des RealTokens durant la période spécifiée.
Récupérer tous les achats d’un RealToken sur une période donnée
Retourne toutes les transactions d’achat concernant un RealToken donné sur une période définie.

Calendrier de développement

Le calendrier de développement respecte les exigences du concours, avec une durée estimée de 1 à 2 mois. La version initiale se concentrera sur l’indexation des transactions et la mise à disposition des endpoints essentiels. Des endpoints supplémentaires pourraient être ajoutés selon les retours de la communauté et les besoins des développeurs.

À propos de moi

En tant qu’investisseur régulier dans l’écosystème RealT et passionné par la blockchain et la tech, je comprends les difficultés pour suivre les transactions YAM et accéder à des données historiques fiables. Cette API est un outil que j’aurais aimé avoir, et je suis enthousiaste à l’idée de la construire pour la communauté.

L’un de mes projets précédents est le développement du bot Telegram The YAMSaleNotifyBot, qui a envoyé plus de 10 000 notifications aux utilisateurs de RealToken pour les informer quand une de leurs offres YAM avait été achetée.

Je suis également ingénieur d’application dans une entreprise tech en Belgique, ce qui me permet d’apporter une expertise professionnelle au développement de solutions fiables et efficaces pour la communauté.

PhilP

Bonne idée !
Pour mémoire, les projets du concours doivent revenir à la communauté : que ce soit pour le code (sur le Github communautaire), mais ce sera aussi pour l'exploitation (à terme)....
Pour faciliter l'exploitation de ta solution, il serait peut être préférable que la solution d'API que tu vas utiliser soit convergente avec celle existante de l'API communautaire ...
Pourrais tu te rapprocher de @Sigri, qui gère l'exploitation communautaire, pour partager sur ce point.
Merci par avance.

LoganSulpizio

PhilP
Hello PhilP,
Merci pour ton retour !

PhilP il serait peut être préférable que la solution d'API que tu vas utiliser soit convergente avec celle existante de l'API communautaire ...

Peux-tu préciser ce que tu entends par là ?
Comme l’API communautaire actuelle pour les Realtokens ne couvre pas le même périmètre que celle que je propose ici, il me semblerait cohérent de les traiter comme deux API autonomes, accessibles séparément via deux urls distinctes.

Ceci dit, je prévois bien sûr de développer cette API de manière claire et maintenable : code structuré, commenté, documenté — avec l’objectif qu’elle puisse être reprise facilement par la DAO pour l’exploitation à terme.

Sigri

LoganSulpizio Hello, ça peut être un nouveau endpoint afin de ne pas perdre tous les users.

Egalement selon le format de sortie (REST, GraphQL, ...) il peut y'avoir une gateway entre les deux (nous avions déjà testé FastAPI (dispo sur la V2), ainsi qu'Apollo).

PhilP

LoganSulpizio
En fait je ne sais pas trop comment on développe un service d'API, mais j'imagine qu'il y a plein de façons de faire (architectures, options techniques, choix d'open source...).
J'anticipais juste le moment d'exploitation de ta solution, alors qu'il y a déjà une API en exploitation par la communauté.
Si les deux API pouvaient avoir des architectures assez semblables ou convergente (celle de l'API communautaire, pouvant aussi évoluer), ce serait certainement plus simple pour l'exploitant...
Et, il est préférable de penser à la solution technique avant de développer, plutôt qu'au moment d'exploiter ;-)

Le contact avec @Sigri me semble établi, je vous laisse voir cela ensemble...

LoganSulpizio

Sigri
Je pense partir sur une API REST.
Si j'ai bien compris, je pourrais donc développer l’API avec la technologie de mon choix, car on pourrait ensuite ajouter une API Gateway pour exposer les nouveaux endpoints au sein de l'interface de l’API communautaire existante?
En revanche, si l’objectif est que les nouveaux endpoints soient directement intégrés au sein de l’API communautaire actuelle, avec les mêmes outils et frameworks, j'ai peur de ne pas maîtriser la technologie en question...

Sigri

LoganSulpizio Actuellement c'est en PHP/Symfony pour la V1, et Python/FastAPI pour la V2.

Sinon effectivement via une gateway on pourra imbriquer plusieurs choses, si le projet se précise on pourra rentrer en contact pour voir les détails

Michael-RealT

Je comprend plus ou moins se que la proposition veux proposer, je me demande sur la première partie quelles serais la différence avec TheGraph qui fais exactement se qui est proposer, indexer des données de la blockchain.

Il es vrais qu'il y as des instabilités, comme tout projet novateur qui tente de décentraliser le fonctionnement cela apporte des complexité et defis.
Centraliser élimine ses contrainte et defis de décentralisation mais amène d'autre problématique, comme la maintenance, les cout de serveur, le stockage, la bande passante.....

Personnellement je verrais plus quelque chose d’hybride, qui utilise les data de TheGraph pour la partie indexation des données, et une BDD communautaire pour un préformatage des données pour des cas d'usages spécifique avec la possibilité d'étendre le système.
ainsi l'api pourrais fournir des données retravailler, ne stockant que se qui es utile pour l'usage de l'api, la charge lier a la collecte de toutes les données restant coté TheGraph, cela permettrais d'avori des logique de purge des données coté api si une donnée n'es pas demander après un certain temps sans la rendre indisponible car toujours possible d'aller la chercher sur thegraph si demander après avoir été purgé.

cela fonctionnerais un peux comme un cache sur de plus longue période

LoganSulpizio

Michael-RealT
Bonjour Michael,

Merci pour le feedback.

Michael-RealT je me demande sur la première partie quelles serais la différence avec TheGraph qui fais exactement se qui est proposer, indexer des données de la blockchain.

En effet, il n'y a pas vraiment de différence. L'idée était surtout d'écouter les feedbacks de la communitauté qui se plaint souvent de l'instabilité de TheGraph en propasant une méthode d'indexation alternative. Mais bien entendu, l'intérêt d'avoir une API qui retraivaille les data qu'elle expose reste le même peu importe la méthode d'indexation. Et je suis tout a fait ouvert à modifier la proposition si la communauté ou ton expertise juge préférable d'utiliser TheGraph.

Michael-RealT si une donnée n'es pas demander après un certain temps sans la rendre indisponible car toujours possible d'aller la chercher sur thegraph si demander après avoir été purgé. cela fonctionnerais un peux comme un cache sur de plus longue période

Je comprends le principe mais pourquoi vouloir absolument purger les données rarement utilisées et ne pas garder tout? Par example, j'estime l'indexation de tous les events YAM pour 2024 à une DB de moins de 80 MB (avec indexation des tables comprises). Même avec un volume YAM qui viendrait à tripler dans les prochaines années, je ne trouve pas ça exagéré et je serai donc en faveur d'indexer tous les events YAM sans les purger.

LoganSulpizio

Project Title: YAM Community API

🔍 Summary:
This project will deliver a public, off-chain API indexing all past and present YAM events. It will empower developers to easily retrieve transaction history for reporting, dashboards, stats, and more.

✅ Features of the project:
📦 Index and store all YAM events (offers, buys, modifications, deletions) in a dedicated database.
🔍 Allow precise queries via clean API endpoints: by wallet, by offer, by token, by event type, and time range.
📑 Offer complete historical insight — not only current offers
🔓 Public API access for developers (optionally token-restricted like existing RealTokens community API).
📘 Clear documentation so devs can plug the API into tools, analytics, and dashboards.

More details here: https://forum.realtoken.community/d/60-dev-competition-yam-community-api-/

PhilP

Cette proposition n'a pas obtenu assez de vote, afin d'être primée au concours.
Elle pourra néanmoins être réalisée et récompensée au travers d'autres budgets (Communautaire, NFT,..).
Merci pour votre participation et votre engagement au sein de la DAO.