Application Services

[turt2live]

Currently this is under phase 4 for dendrite, however I'd certainly like to see it in an earlier phase. This includes:

• Loading application service configurations
• The application service API
• Supporting application services on the various client endpoints

An incredibly nice to have feature of this would also be documentation on how this API works.

[anoadragon453]

To break the tasks down a bit further:

• Allow application services to register users in their namepsaces defined in the config files.
• Look at each event and figure out if it should be sent to the AS, if so do that (with ability to batch requests up while doing so).
• Make the APIs support the way that AS's interact with the API, which is use their master access_token and specify a user_id= param.

Application Services API docs

[anoadragon453]

In terms of users, Application Services specifically:

• Register for a namespace which is a regex pattern which their user's usernames matches. They can say whether they have exclusive rights to their namespace or not.
• They can register a password-less user as long as the username lies within their namespace.
• They can then call any API endpoint masquerading as that user with /path?access_token=$token&user_id=$userid.

[turt2live]

Just for tracking purposes, here's the PR progress so far:

• Load Application Service Configuration Files #377 - Parse and load the config files
• Application Service Registration #390 - Appservice users can be registered
• Prevent AS user check if no AS registered #392 - Fix a bug related to registrations on homeservers with no appservices

If I'm not mistaken, what's left to do is:

• Support the ?user_id query parameter for appservice access tokens
• Support changing the origin_server_ts value of events through the ?ts query parameter
• Sending events to the appservice (/transactions route)
• Sending room alias query requests to the appservice (PR Implement GET /rooms/{roomAlias} #494)
• Sending user query requests to the appservice (PR Make use of /users/{userID} in relevant APIs #522)
• 3pid support (although for the purposes of the bounty, I'm okay with ignoring this part) (PR Third Party Lookup Support #561)
• Testing the whole thing to see if it works :)

Thanks for your amazing progress so far on this @anoadragon453! It's looking pretty good, and I'm really excited to see it implemented.

Edit: Update with current progress - @anoadragon453

[anoadragon453]

@turt2live Thanks for summing it all up! I plan to add AS support to endpoints next (hopefully in some transparent fashion that future endpoints can use without hassle), then work on communicating directly the AS's.

And tests, need to start writing those :)

[turt2live]

More for tracking purposes:

• Milestone: https://github.com/matrix-org/dendrite/milestone/3
• Send events: AppServices: PUT /transactions/{txnId} #450 (PR: Send Application Service Events #477)
• AppServices: GET /rooms/{roomAlias} #452 - GET /rooms/alias
• AppServices: GET /users/{userId} #453 - GET /users/userId
• AppServices: Add ability to perform Timestamp Massaging #456 - Timestamp massaging
• AppServices: GET /_matrix/app/r0/user?uri={url_encoded_uri} #457 - GET /app/r0/user?uri=encoded (I think this is 3pid related?)
• AppServices: GET /_matrix/app/r0/alias?uri={url_encoded_uri} #460 - GET /app/r0/alias?uri=encoded (I think this is 3pid related?)
• AppServices: Ensure users cannot create a room alias that an Application Service manages #451 - Validation on exclusive rooms (PR: Prevent alias registration in AS exclusive namespace  #480)
• FInd more efficient way to check room memberships for appservices #468 - Validation to ensure the appservice is actually in the room
• AppServices: Identity Assertion aka ?user_id={user_id} #469 - Identity masquerading
• AppServices: Implement Synapse-supported registration config options #471 - Misc additional registration options

[anoadragon453]

I'm also tracking progress in the spreadsheet fwiw.

[Half-Shot]

Modulo #468 being verified as fixed, I don't know if this issue is very useful going forwards. All the basic AS features have landed and we can track the thirdparty endpoints / misc things as issues.

Any votes for keeping this open?

[anoadragon453]

Ah memories...

I'm fine with closing it now that basic support is there. @turt2live?

[turt2live]

yea, I think this is done enough. Is there someone who is able to accept the bounty or should I get it moved to another issue? (not sure how many people are involved, and whether it would count as conflict of interest/non-compete)

[Half-Shot]

I think the PRs have come over several years, some of which have since been broken and unbroken. Suggest you move the bounty, unless I am forgetting someone (please ping loudly).