Super fonctionnalité ! Cependant 
Je suis plus curieux au sujet du tri Top / Nouveau / Ancien que de la disposition imbriquée elle-même. J’ai déjà implémenté des contrôles de tri similaires dans mon application mobile (un client Discourse) et j’aimerais beaucoup prendre en charge cela nativement plutôt que de recourir à ma méthode actuelle, bien qu’elle fonctionne comme je le montre ci-dessous.
En examinant le code source, je vois que GET /n/{slug}/{topic_id}.json?sort={top|new|old}&page={n} renvoie le sujet en vue imbriquée trié selon le mode choisi. Ma question : y a-t-il un intérêt à exposer uniquement le tri via l’endpoint existant /t/{slug}/{topic_id}.json (par exemple ?sort=top) afin que les clients en vue plate puissent également en bénéficier ?
Si le tri était disponible en vue plate, les clients tiers pourraient opter pour cette fonctionnalité sans adopter le modèle de rendu en vue imbriquée.
Je comprends que la structure des données de la vue imbriquée (messages racines + enfants chargés à la demande) est ce qui rend le tri côté serveur réalisable, et que la vue plate utilise une pagination différente. Si un tri complet en vue plate n’est pas réaliste pour des raisons de performance, même un paramètre optionnel ?sort=top&limit=N suffirait pour alimenter une vue « points forts ».