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

MSC2063: Add "server information" public API proposal #2063

Open
wants to merge 7 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@grinapo
Copy link

commented May 31, 2019

rendered

@grinapo grinapo changed the title Add "server information" public API proposal MSC2063: Add "server information" public API proposal May 31, 2019

@grinapo

This comment has been minimized.

Copy link
Author

commented May 31, 2019

Mentioned in the text is #1929 .

@grinapo

This comment has been minimized.

Copy link
Author

commented May 31, 2019

Signed-off-by: Peter Gervai grin@grin.hu

@Atreatis

This comment has been minimized.

Copy link

commented May 31, 2019

I support this change because we need it!

@KitsuneRal
Copy link
Member

left a comment

That's a good idea; but to become a real proposal it needs elaboration. At the very least, please address comments below.

Show resolved Hide resolved proposals/2063-serverinfo.md
Show resolved Hide resolved proposals/2063-serverinfo.md Outdated
Show resolved Hide resolved proposals/2063-serverinfo.md Outdated
Show resolved Hide resolved proposals/2063-serverinfo.md

grinapo added some commits Jun 3, 2019

Remove from the actual proposal the MSC-1929 stuff.
Mention its existence but remove from the main body, these all shall be covered by pull#1929.

Also remove specifics from *server connectivity checking* which shall be covered by a separate proposal (as federation pin, traceroute, or else).
@KitsuneRal
Copy link
Member

left a comment

Nitpicking on one remaining thing, but otherwise this looks pretty good to me.

"server_data": {
"m.open_registrations": true,
"m.uptime": 63072000,
"m.registered_users": 4,

This comment has been minimized.

Copy link
@KitsuneRal

KitsuneRal Jun 4, 2019

Member

This is almost perfect; but it'd be probably better to further distinguish between statistics/status information (uptime and the number of users) and configuration/settings information (open registrations). I don't know if it's worth it to introduce a separate /server_config endpoint just for a single boolean value - probably overengineering here. It would be great to have other opinions on this.

This comment has been minimized.

Copy link
@grinapo

grinapo Jun 4, 2019

Author

How about

{
 "server_data": {
  "settings": {
    "m.open_registrations": true
  },
  "statistics" : {
    "m.uptime": 63072000,
    "m.registered_users": 4
  }
 }
}

Processing a json and ignoring unnecessary fields is probably painless enough that it doesn't justify creating any more complexity.

I guess someone shall come up with a real justification to separate them even this way though, or maybe it's good for "visibility" or "mental separation"?

This comment has been minimized.

Copy link
@KitsuneRal

KitsuneRal Jun 4, 2019

Member

I'd rather use two separate endpoints. The reason is that open registrations may (I can imagine that in theory at least) be configurable using some administration API. What I mean to say is that generally configuration is, at least in theory, read/write depending on your access credentials, while statistics are produced by the servers and cannot be tweaked even in theory. But probably let's validate it in the Matrix room.

This comment has been minimized.

Copy link
@Half-Shot

Half-Shot Jun 12, 2019

Contributor

Should be pointed out that open_registrations is not something federation should care about. It should be reported by a client API.

This comment has been minimized.

Copy link
@turt2live

turt2live Jun 12, 2019

Member

tbh I think it's fine to expose health/metadata/metrics at the federation level for this, mostly because there's a discovery function that server lists can use to query the data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.