-
Notifications
You must be signed in to change notification settings - Fork 22
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
Add element for discovering instance staff #27
Comments
Yes I can see that. The usecases I see is to direct emergency requests and content moderation reports, so akin to domain whois. Question is, do we want internal identifiers here? My intuition says no and this should more likely be email addresses, akin to whois. Or have an option for both. Naming wise, keeping the above usecases in mind, I'd go in terms of Either way it should be an optional element. |
The identifiers should be profile URIs, as those are generic. |
That's just a statement, not an argument as for why. What use are internal profiles if an instance is down? |
If an instance is down, you cant pull the nodeinfo anyway. |
But it can be cached by monitoring sites like https://the-federation.info/ Also there's multiple levels of down, like "I can no longer sign in" down. |
Well, a URI can also be a |
this should really be added! its been open since 2018! |
I'll create two competing proposals via pull :) |
I would day vote with 👍 / 👎 on the pull requests ? |
Pleroma recently added
staff_accounts
to metadata, as a list of a staff accounts (profile URIs) who can do administrative/moderation actions concerning the instance.It would be nice to have an official element in the JSON for this that could be standardized.
The text was updated successfully, but these errors were encountered: