Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#544 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 14 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
go
Bereich
api, backend-api-design, testing

Rechercherichtung

Beginne mit der Überprüfung von README.md's Image Requirements, RegisterUser, TestCanRegisterAdmin, TestServerNotices und TestRegistration, um jede aktuelle Verwendung von /_synapse zu erfassen. Der Vorschlag definiert die Ersatz-API nicht, daher ist die Arbeit nicht bereit, bis die server-notice-Schnittstelle und der Migrationsumfang vereinbart sind; abgeschlossen wäre sie, wenn unnötige Synapse-spezifische Annahmen entfernt werden und die Abdeckung von server-notice erhalten bleibt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Go
Sterne
101
Forks
72
Ø Merge
11 T. 5 Std.
Gemergte PRs (30 T.)
7

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus matrix-org/complement

Alle Issues in matrix-org/complement

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.