Posting room ID links or message links should have a via parameter #11

New Issue

Closed

opened 2023-10-15 22:44:02 +00:00 by cadence · 1 comment

cadence commented

2023-10-15 22:44:02 +00:00

Owner

Spec says:

When generating room links and permalinks, the application should pick servers which have a high probability of being in the room in the distant future. How these servers are picked is left as an implementation detail, however the current recommendation is to pick 3 unique servers based on the following criteria:

The first server should be the server of the highest power level user in the room, provided they are at least power level 50. If no user meets this criterion, pick the most popular server in the room (most joined users). The rationale for not picking users with power levels under 50 is that they are unlikely to be around into the distant future while higher ranking users (and therefore servers) are less likely to give up their power and move somewhere else. Most rooms in the public federation have a power level 100 user and have not deviated from the default structure where power level 50 users have moderator-style privileges.

We can get this from the power_levels event, then find a user who's joined to the room and isn't a sim or the bridge bot.

The second server should be the next highest server by population, or the first highest by population if the first server was based on a user’s power level. The rationale for picking popular servers is that the server is unlikely to be removed as the room naturally grows in membership due to that server joining users. The server could be refused participation in the future due to server ACLs or similar, however the chance of that happening to a server which is organically joining the room is unlikely.

We can get this from joined_members, I guess. The matrix-react-sdk uses the in-memory state, but we don't have that, so we'll have to call some API.

The third server should be the next highest server by population.

Servers which are blocked due to server ACLs should never be chosen.

Servers which are IP addresses should never be chosen. Servers which use a domain name are less likely to be unroutable in the future whereas IP addresses cannot be pointed to a different location and therefore higher risk options.

All 3 servers should be unique from each other. If the room does not have enough users to supply 3 servers, the application should only specify the servers it can. For example, a room with only 2 users in it would result in maximum 2 via parameters.

Also we should use the bridge bot's own homeserver as the first option. If the bridge bot's homeserver did go offline, we wouldn't have a bridge anymore, so it's unlikely people would stick around and keep using the room.

Spec says: > When generating room links and permalinks, the application should pick servers which have a high probability of being in the room in the distant future. How these servers are picked is left as an implementation detail, however the current recommendation is to pick 3 unique servers based on the following criteria: > > - The first server should be the server of the highest power level user in the room, provided they are at least power level 50. If no user meets this criterion, pick the most popular server in the room (most joined users). The rationale for not picking users with power levels under 50 is that they are unlikely to be around into the distant future while higher ranking users (and therefore servers) are less likely to give up their power and move somewhere else. Most rooms in the public federation have a power level 100 user and have not deviated from the default structure where power level 50 users have moderator-style privileges. We can get this from the power_levels event, then find a user who's joined to the room and isn't a sim or the bridge bot. > - The second server should be the next highest server by population, or the first highest by population if the first server was based on a user’s power level. The rationale for picking popular servers is that the server is unlikely to be removed as the room naturally grows in membership due to that server joining users. The server could be refused participation in the future due to server ACLs or similar, however the chance of that happening to a server which is organically joining the room is unlikely. We can get this from joined_members, I guess. The matrix-react-sdk uses the in-memory state, but we don't have that, so we'll have to call some API. > - The third server should be the next highest server by population. > - Servers which are blocked due to server ACLs should never be chosen. > - Servers which are IP addresses should never be chosen. Servers which use a domain name are less likely to be unroutable in the future whereas IP addresses cannot be pointed to a different location and therefore higher risk options. > - All 3 servers should be unique from each other. If the room does not have enough users to supply 3 servers, the application should only specify the servers it can. For example, a room with only 2 users in it would result in maximum 2 via parameters. Also we should use the bridge bot's own homeserver as the first option. If the bridge bot's homeserver did go offline, we wouldn't have a bridge anymore, so it's unlikely people would stick around and keep using the room.

cadence added this to the v2.0 milestone 2024-02-13 00:27:26 +00:00

cadence commented

2024-02-13 22:42:15 +00:00

Author

Owner

Done in fd11e3fd10 et al

Done in fd11e3fd10a69ad00ff82491b667a2ea7902b48a et al

cadence closed this issue

2024-02-13 22:42:15 +00:00

No Label

No Milestone

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cadence/out-of-your-element#11

No description provided.