Use the stable hierarcy endpoint from MSC2946

[clokep]

MSC2946 has completed FCP and Synapse is implementing the stable endpoint (see matrix-org/synapse#11329). It would be nice for Element iOS to implement the following so that the unstable endpoints can be deprecated:

• Start using the stable /_matrix/client/v1/rooms/{roomID}/hierarchy endpoint.
• Ensure that the room_id is not accessed via the list of children_state (this is nested under the room information and should be unnecesary).

This should most likely be implemented to attempt using the stable endpoint before falling back to the unstable endpoint. Please let me know if you have any questions.

[clokep]

The other thing to check is if the join_rules field (plural version) is being used instead of the proper join_rule field.

[gileluard]

@clokep I can do it I'm just wondering what you mean about:

Ensure that the room_id is not accessed via the list of children_state (this is nested under the room information and should be unnecesary).

Here is my use case:

To get the list of children for Matrix Community we call the /hierarchy endpoint with the room ID of the Matrix Community space. Then, if I tap Other Projects, the app takes the room ID of Other Projects from the result of the hierarchy previous request and perform a new /hierarchy request with the room ID of Other Projects. Is it fine from the API standpoint?

[clokep]

Is it fine from the API standpoint?

Yes, it should work, it might be inefficient, however. Are you calling the API with a max-depth? By default the API will paginate through the entire tree of spaces.

---

Ensure that the room_id is not accessed via the list of children_state (this is nested under the room information and should be unnecesary).

This is referencing a minor change to the API shape that gets returned. If we use the example from the spec, I've highlighted the field that was removed:

 {
   "next_batch": "next_batch_token",
   "rooms": [
     {
       "avatar_url": "mxc://example.org/abcdef",
       "canonical_alias": "#general:example.org",
       "children_state": [
         {
           "content": {
             "via": [
               "example.org"
             ]
           },
-          "room_id": "!space:example.org",
           "origin_server_ts": 1629413349153,
           "sender": "@alice:example.org",
           "state_key": "!a:example.org",
           "type": "m.space.child"
         }
       ],
       "guest_can_join": false,
       "join_rule": "public",
       "name": "The First Space",
       "num_joined_members": 42,
       "room_id": "!space:example.org",
       "room_type": "m.space",
       "topic": "No other spaces were created first, ever",
       "world_readable": true
     }
   ]
 }

[gileluard]

Thanks for your answer. We actually call the API with a max-depth=1 as we want a maximum of direct children for the current space.

[clokep]

Then yes, that should work fine!

[clokep]

It seems the room_id was still being used from the children_state, see #6547 for a crash due to this.