Application service room directories (and other third party network things) #1554
Conversation
Some information was missed when this was reviewed. This commit adds some additional documentation for how these objects interact with each other.
| ++++++++++++++++++++ | ||
|
|
||
| Application services may declare which protocols they support via their registration | ||
| file. These networks are generally for third party services such as IRC that the |
There was a problem hiding this comment.
registration files are an implementation specific quirk, i think? This should be "which protocols they support via their registration configuration at the homeserver"?
There was a problem hiding this comment.
registration files are currently in the spec (introduced when the self-registration API was removed), although +1 to making it more generic for future support.
There was a problem hiding this comment.
oh, right, of course. prolly best leave it talking about 'registration file' or 'registration config file'.
| application service is managing. Application services may populate a Matrix room | ||
| directory for their registered protocols, as defined in the Client-Server API Extensions. | ||
|
|
||
| Each protocol may have several "locations". A location within a protocol is a place |
There was a problem hiding this comment.
for consistency with Leo's nomenclature elsewhere we should probably say "aka 3rd party locations or 3PLs")
| get: | ||
| summary: Reverse-lookup third party locations given a Matrix room alias. | ||
| description: |- | ||
| Retreive an array of third party network locations from a Matrix room |
|
okay, so i had no idea that 3rd party directories actually got implemented in synapse (sorry Leo). Do any ASes actually implement them? |
|
(i guess this all looks okay, but i'm a bit worried about speccing stuff which might not have been used in anger) |
|
I believe the IRC bridge, Gitter, and Slack all use them (I think, at least going off of the riot room directory). Discord also makes use of them (I'm pretty sure). |
|
Hm. am I totally misreading this then? the API looks like it lets the HS query the AS for the list of rooms that the AS could expose - as opposed to just tagging which rooms happen to come from a given AS in the directory. I'm aware we do the latter in publicRooms, but is anything doing the former? |
|
Ah, right. This isn't HS->AS communication (it's AS->HS with the intent of the HS taking care of it), but it is used at least by IRC and Gitter: https://github.com/search?q=org%3Amatrix-org+org%3Avector-im+setRoomDirectoryVisibilityAppService&type=Code It also has sytests: https://github.com/matrix-org/sytest/blob/cab0f6b3a0ae8c8324f5c8ab609ac6286da178ca/tests/60app-services/06publicroomlist.pl#L53 |
|
Although a search across all of github doesn't yield more than that, which may be a result of it not being in the spec? |
| $ref: ../client-server/definitions/errors/error.yaml | ||
| "/_matrix/app/unstable/thirdparty/location/{protocol}": | ||
| get: | ||
| summary: Retreive Matrix-side portal rooms leading to a third party location. |
| get: | ||
| summary: Reverse-lookup third party users given a Matrix User ID. | ||
| description: |- | ||
| Retreive an array of third party users from a Matrix User ID. |
|
right, 5403296 mitigates my confusion nicely; thanks. lgtm! |
Rendered: see 'docs' status check.
This may be best to review commit by commit.
Move the third party network API to it's own section
Update third party network schemas
Some information was missed when this was reviewed. This commit adds some additional documentation for how these objects interact with each other.
Document third party network/protocol directories (for appservices)
Fixes #869