De-emphasise and reduce the usage of `/_synapse` endpoints

Ouverte
  • Quelque chose ne va pas ?
#544 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 3 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
go
Domaine
api, backend-api-design, testing

Piste de recherche

Commencez par examiner Image Requirements, RegisterUser, TestCanRegisterAdmin, TestServerNotices et TestRegistration dans README.md afin de recenser chaque utilisation actuelle de /_synapse. La proposition ne définit pas l’API de remplacement ; le travail n’est donc pas prêt tant que l’interface server-notice et le périmètre de migration n’ont pas été définis d’un commun accord ; il sera considéré comme terminé lorsque les hypothèses spécifiques à Synapse inutiles auront été supprimées, tout en préservant la couverture de server-notice.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

This is something I noticed while working on conduit support (#513), where it seems that complement currently requires or emphasizes the usage of /_synapse endpoints.

Specifically, it uses them like so:

  • Under "Image Requirements" in README.md, it asks for /_synapse/admin/v1/register to be supported for "admin" registrations.
    • This is then used in RegisterUser where isAdmin is true, which is used by the following tests:
      • TestCanRegisterAdmin
      • TestServerNotices
  • TestRegistration, under some t.Runs

From a puritan perspective, these should not exist within complement, as they test Synapse-specific behaviour that other servers have to then copy uncritically, and without blessing or formalisation from the spec.

From such a perspective, the concept of "admins" is also dubious, as the spec (explicitly) makes no serious note of them, leaving server administration as an implementation detail. (See MSC3593 for some context reading on an attempt to broach/formalise this as well.)

For all of complement's current usage of this endpoint, there is one problem with a suggestion of removing all of them altogether; Server Notices are defined in the spec, and so the absence of a formal mechanism which empowers servers/users to send server notices is unfortunate, but this means complement has no "closed system" way of implementing this.

To make the rejection of a /_synapse specific API explicit, and to develop a better way of testing server notices, I'm suggesting to introduce a /_complement API space, which servers should enable only in their corresponding complement images, and (for now) be only used for sending server notices (exact API forthcoming), not to elevate individual users as a "server admin", as this concept does not properly exist from a matrix specification standpoint.

This API space should only perform individual elevated actions, such as sending a single server notice via a POST API.

Hopefully, this way, we can avoid biasing to a certain implementation, and help make complement more pure or agnostic when testing conformity.

Langage dominant
Go
Étoiles
101
Forks
73
Merge moyen
4 j 21 h
PR mergées (30 j)
5

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de matrix-org/complement

Toutes les issues de matrix-org/complement

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.