Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spec appropriate admin APIs #328

Open
turt2live opened this issue Jul 12, 2018 · 6 comments
Open

Spec appropriate admin APIs #328

turt2live opened this issue Jul 12, 2018 · 6 comments
Labels
A-Client-Server Issues affecting the CS API feature Suggestion for a significant extension which needs considerable consideration

Comments

@turt2live
Copy link
Member

Synapse has a number of admin APIs, some of which are useful outside of synapse. The whole lot needs to be gone through to figure out what is useful and what isn't.

This is to support things like matrix-org/matrix-python-sdk#247 which wish to actually use these APIs.

@turt2live turt2live added spec-omission implemented but not currently specified feature Suggestion for a significant extension which needs considerable consideration and removed spec-omission implemented but not currently specified labels Jul 12, 2018
@turt2live turt2live added the A-Client-Server Issues affecting the CS API label Sep 6, 2018
@turt2live
Copy link
Member Author

worth noting that Synapse has moved its APIs out of the /_matrix namespace, so it's a matter of creating a MSC to add them.

@ara4n
Copy link
Member

ara4n commented May 1, 2021

The only reasons that synapse's admin APIs were never part of the Matrix spec were:

  • we were worried the spec was already growing too big
  • we feared they might end up quite tied to Synapse's implementation.

In practice, both of these concerns were bogus - admin APIs would be tiny relative to the spec as it stands today; the features they provide aren't Synapse specific; and it's sabotaging our ability to expose sensible administration functions in Matrix (c.f. discussions like element-hq/element-meta#466). It's got even worse since Synapse decided to move its admin features to /_synapse, which typically isn't exposed to the public.

So: we should fix this.

@ShadowJonathan
Copy link
Contributor

ShadowJonathan commented May 2, 2021

I suggest to slowly expand the "circle" of admin apis that'll be out there, though, and to have the conversation with existing homeserver developers on which apis would be the best to implement (beyond the delete/remove/purge room API suggested above), i'm personally still thinking the latter case is true in some shape or form, but lets be cautious.

@richvdh
Copy link
Member

richvdh commented May 4, 2021

+1 to what @ShadowJonathan said. Let's consider which admin APIs we need in the Matrix protocol, and specify them appropriately with MSCs.

If you try to standardise the whole of the Synapse-specific admin API at once, then it'll get massively bogged down.

This isn't really a job for the spec team - it's for application developers to create MSCs proposing the admin apis they would like to see. Accordingly, I'm removing the P1 label here.

@richvdh richvdh removed the p1 label May 4, 2021
@richvdh
Copy link
Member

richvdh commented May 4, 2021

Incidentally, there's already a "Server admin" section in the spec: https://matrix.org/docs/spec/client_server/r0.6.1#id129. It just needs expanding a bit...

@melroy89
Copy link

Incidentally, there's already a "Server admin" section in the spec: https://matrix.org/docs/spec/client_server/r0.6.1#id129. It just needs expanding a bit...

I fully agree. Any process on that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API feature Suggestion for a significant extension which needs considerable consideration
Projects
None yet
Development

No branches or pull requests

5 participants