Grâce a l’input issuer de la requête transactions :
transactions(
paging: Paging!
issuer: String
state: DocumentState!
): Transactions
issuer est la clé publique en base58, ça te renverra toutes les tx qui ont cette clé publique dans leurs issuers.
L’input state te permet de choisir entre les tx inscrites en blockchain ou les tx en piscine, ou les deux 
La pagination est obligatoire avant d’éviter les abus et de limiter la surface d’attaque.
Je trouve qu’il y a déjà le minimum requis dans l’entrée transactions cités ci-dessus. La clé publique, la pagination, et l’état (écris, en piscine, ou tout).
Oui pourquoi pas
Que c’est dommage d’utiliser Int!, ça fait du typage très faible. Dans ce cas merci d’ajouter un type Timestamp :
type Timestamp {
timestamp: Int!
}
Aussi pour limiter les calculs coté serveur je préfère que les serveurs blockchain ne renvoient que le mediantTime. Chaque client étant libre dans sa façon de calculer ce qu’il considère être un temps “proche de la réalité” a partir du temps blockchain commun.
Je ne suit vraiment pas convaincu de la pertinence de cette formule.
De plus, les serveurs blockchain doivent faire référence dans les données qu’ils fournissent quel que soit “l’école” des uns et des autres.
Il y a un temps blockchain commun, c’est ce temps blockchain commun que doivent fournir les serveurs blockchain, c’est lui qui fait foi.
Oups c’est une erreur 
, Ce champ n’existe pas, il faut le supprimer du schéma. Les transactions sont forcémetn des TX. Les UD ne sont pas des transactions 
En Blockstamp qui est le terme utilisé partout dans le code des serveurs blockchain oui
Je déconseille BlockId car ce terme est parfois utilisé pour désigner le numéro du bloc.
@kimamila peut tu stp soumettre tes modif du schéma sur une branche tierce avec une demande de MR sur la branche de la rfc ? Je la relirai avec attention, merci beaucoup