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

[WIP] MSC1956: Integrations API (base) #1956

Draft
wants to merge 8 commits into
base: old_master
Choose a base branch
from

Conversation

turt2live
Copy link
Member

@turt2live turt2live commented Apr 8, 2019

Rendered
See matrix-org/matrix-spec#296
Discussion room: #msc-integrations-api:t2bot.io

Note: Currently this proposal is not ready for review in its entirety. The actual contents of the Integrations API are not yet fully defined, and other proposals must get approved before this proposal can officially work through the process. This is being opened now to have a reference number for all things Integrations API though.

Feedback on whether the concept of an Integrations API makes sense is welcome though, even if the final contents are still well within the draft status.

Required proposals:


This is being contributed under the hat of "author of Dimension":

Signed-off-by: Travis Ralston <[email protected]>

@turt2live turt2live added the proposal A matrix spec change proposal label Apr 8, 2019
@turt2live turt2live changed the title [WIP] Integrations API (base) MSC1956: [WIP] Integrations API (base) Apr 8, 2019
@turt2live
Copy link
Member Author

note to self: it's a bit cross cutting, but a read of https://sandstorm.io/how-it-works is a good idea


A new Integrations API be introduced into Matrix which consists of the components listed in this proposal.

**Components**:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Include #2192 (if it stays relevant)


A new Integrations API be introduced into Matrix which consists of the components listed in this proposal.

**Components**:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add #2315

@@ -0,0 +1,260 @@
# MSC1956: Integrations API
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note to self: reference the following diagrams (if needed):

Also, the dances need better names. Currently we have:

  • OpenID dance - the dance to get a subject from the homeserver
  • OpenID exchange dance - the dance for a widget to get an OpenID subject/authentication token
  • Terms dance - the dance after an authentication token is acquired to check for unaccepted policies
  • Auth dance - the combination of the three dances, plus the integration manager's internal operations dance

@@ -0,0 +1,260 @@
# MSC1956: Integrations API
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: Add a ready state to widget postMessage API so that widgets don't have to rely on the capabilities request taking an amount of time.

@richvdh richvdh changed the title MSC1956: [WIP] Integrations API (base) [WIP] MSC1956: Integrations API (base) Apr 14, 2020
@turt2live turt2live added the kind:feature MSC for not-core and not-maintenance stuff label Apr 20, 2020
@turt2live turt2live mentioned this pull request Sep 2, 2020
6 tasks

All HTTP APIs in this specification must consume and produce JSON unless otherwise indicated. Errors emitted by
these APIs should follow the standard error responses defined by other APIs in Matrix. Some common error responses
implementations may encounter are:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From reading the code of https://github.com/matrix-org/matrix-widget-api, it seems like these errors have only a message field that contains human-readable text. This could be problematic since the error message is not defined in the spec, so it's impossible for a widget to know what the error is. For example, the string Invalid request - missing event type isn't standardized anywhere, so it can't be differentiated from Cannot send state events of this type unless the widget knows exactly what these strings will be ahead of time (which are specific to that particular library).

It may be helpful to define standard error types (like the error codes in the C2S API) to categorize these errors. Ex, M_WIDGET_MISSING_PARAM or M_WIDGET_DENIED for the above errors.

@turt2live turt2live marked this pull request as draft April 8, 2021 23:36
@turt2live turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021
@ghost
Copy link

ghost commented Oct 16, 2022

Hi @turt2live If this proposal is blocked because others need to be merged first, please if you don't mind, add the "blocked" label to organize things better.

@richvdh
Copy link
Member

richvdh commented May 2, 2023

I believe this is an attempt to fix matrix-org/matrix-spec#296, though I am somewhat confused.

(edit: oh, it is. It's linked from the description, though using a different link)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrations Integration (Manager) API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants