MSC2787 Add support for splitting UPK IDs

[brianathere]

Add code coverage for SplitID. Create SplitIDWithSigil for future extension. Mark SplitID deprecated as callers should only pass ID with embedded sigals, letting SplitIDWithSigil parse the sigil.

Pull Request Checklist

• [X ] Pull request includes a sign off

Signed-off-by: Brian Meek <[email protected]>

[kegsay]

I have a few problems with this:

• the names of the functions are misleading and unclear. SplitIDWithSigil doesn't actually take a sigil and SplitID says the sigil is unused but it in fact is for validation.
• The newer now recommended function is less secure and less correct compared to the deprecated function. We use SplitID when we know what kind of ID we're supposed to have e.g. a user ID. Specifying the @ in the function signature as a sigil ensured that you can't send a room alias as a user ID for example. Now the newer "recommended" form doesn't do this critical check.

I don't think this overall improves things. You've been rather prescriptive about the API with insufficient justifications why this is better. I imagine you're doing this because GMSL auth code checks using SplitID for well-formed IDs which for this MSC you cannot know upfront what the sigil will be? The answer then isn't to make us do less validation: specify which sigils you expect to see and ensure that one of them is present. Furthermore, you need to be careful that this is only going to apply in room versions / other flags which enable this: we cannot have UPKs being treated as valid everywhere.

[brianathere]

I have a few problems with this:

• the names of the functions are misleading and unclear. SplitIDWithSigil doesn't actually take a sigil and SplitID says the sigil is unused but it in fact is for validation.
• The newer now recommended function is less secure and less correct compared to the deprecated function. We use SplitID when we know what kind of ID we're supposed to have e.g. a user ID. Specifying the @ in the function signature as a sigil ensured that you can't send a room alias as a user ID for example. Now the newer "recommended" form doesn't do this critical check.

I don't think this overall improves things. You've been rather prescriptive about the API with insufficient justifications why this is better. I imagine you're doing this because GMSL auth code checks using SplitID for well-formed IDs which for this MSC you cannot know upfront what the sigil will be? The answer then isn't to make us do less validation: specify which sigils you expect to see and ensure that one of them is present. Furthermore, you need to be careful that this is only going to apply in room versions / other flags which enable this: we cannot have UPKs being treated as valid everywhere.

Great feedback, I agree with it not accomplishing anything (this was setting up for a change in the Dendrite server using UPK), and that it weakens the contract for the caller not declaring what type of ID. I'll revise for the latter.

As for talking this over, is there a forum you'd suggest other than in Github comments?

[kegsay]

#dendrite:matrix.org or #dendrite-dev:matrix.org are good candidates. We can support your changes more there.