Skip to content

Conversation

@fewerner
Copy link
Contributor

@fewerner fewerner commented Jan 6, 2026

What's new in this PR

This PR simplifies the way an mls_session is created and removes the inner session.
It also removes provideTransport() and transport will now be provided on mlsInit() since every mls session needs transport.
The database will be known by the CC instance and transaction context to avoid database usage through the mls session's crypto provider were it is not needed.


PR Submission Checklist for internal contributors
  • The PR Title
    • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
    • contains a reference JIRA issue number like SQPIT-764
    • answers the question: If merged, this PR will: ... ³
  1. https://sparkbox.com/foundry/semantic_commit_messages
  2. https://github.com/wireapp/.github#usage
  3. E.g. feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.

@github-actions
Copy link

github-actions bot commented Jan 6, 2026

🐰 Bencher Report

Branchfelix/refactor/mls-session
Testbedubuntu-latest

⚠️ WARNING: No Threshold found!

Without a Threshold, no Alerts will ever be generated.

Click here to create a new Threshold
For more information, see the Threshold documentation.
To only post results if a Threshold exists, set the --ci-only-thresholds flag.

Click to view all benchmark results
BenchmarkLatencymicroseconds (µs)
Commit add f(group size)/cs1/mem/1002📈 view plot
⚠️ NO THRESHOLD
18,083.00 µs
Commit add f(group size)/cs1/mem/2📈 view plot
⚠️ NO THRESHOLD
741.85 µs
Commit add f(group size)/cs1/mem/202📈 view plot
⚠️ NO THRESHOLD
4,440.50 µs
Commit add f(group size)/cs1/mem/402📈 view plot
⚠️ NO THRESHOLD
7,758.90 µs
Commit add f(group size)/cs1/mem/602📈 view plot
⚠️ NO THRESHOLD
11,688.00 µs
Commit add f(group size)/cs1/mem/802📈 view plot
⚠️ NO THRESHOLD
14,651.00 µs
Commit add f(number clients)/cs1/mem/1002📈 view plot
⚠️ NO THRESHOLD
984,670.00 µs
Commit add f(number clients)/cs1/mem/2📈 view plot
⚠️ NO THRESHOLD
715.14 µs
Commit add f(number clients)/cs1/mem/202📈 view plot
⚠️ NO THRESHOLD
79,310.00 µs
Commit add f(number clients)/cs1/mem/402📈 view plot
⚠️ NO THRESHOLD
216,690.00 µs
Commit add f(number clients)/cs1/mem/602📈 view plot
⚠️ NO THRESHOLD
426,550.00 µs
Commit add f(number clients)/cs1/mem/802📈 view plot
⚠️ NO THRESHOLD
674,420.00 µs
Commit pending proposals f(group size)/cs1/mem/1002📈 view plot
⚠️ NO THRESHOLD
116,210.00 µs
Commit pending proposals f(group size)/cs1/mem/2📈 view plot
⚠️ NO THRESHOLD
23,000.00 µs
Commit pending proposals f(group size)/cs1/mem/202📈 view plot
⚠️ NO THRESHOLD
41,550.00 µs
Commit pending proposals f(group size)/cs1/mem/402📈 view plot
⚠️ NO THRESHOLD
57,574.00 µs
Commit pending proposals f(group size)/cs1/mem/602📈 view plot
⚠️ NO THRESHOLD
77,360.00 µs
Commit pending proposals f(group size)/cs1/mem/802📈 view plot
⚠️ NO THRESHOLD
93,264.00 µs
Commit pending proposals f(pending size)/cs1/mem/1📈 view plot
⚠️ NO THRESHOLD
17,497.00 µs
Commit pending proposals f(pending size)/cs1/mem/101📈 view plot
⚠️ NO THRESHOLD
115,660.00 µs
Commit pending proposals f(pending size)/cs1/mem/21📈 view plot
⚠️ NO THRESHOLD
34,441.00 µs
Commit pending proposals f(pending size)/cs1/mem/41📈 view plot
⚠️ NO THRESHOLD
55,505.00 µs
Commit pending proposals f(pending size)/cs1/mem/61📈 view plot
⚠️ NO THRESHOLD
74,937.00 µs
Commit pending proposals f(pending size)/cs1/mem/81📈 view plot
⚠️ NO THRESHOLD
94,938.00 µs
Commit remove f(group size)/cs1/mem/1002📈 view plot
⚠️ NO THRESHOLD
11,144.00 µs
Commit remove f(group size)/cs1/mem/2📈 view plot
⚠️ NO THRESHOLD
573.94 µs
Commit remove f(group size)/cs1/mem/202📈 view plot
⚠️ NO THRESHOLD
2,573.20 µs
Commit remove f(group size)/cs1/mem/402📈 view plot
⚠️ NO THRESHOLD
4,109.70 µs
Commit remove f(group size)/cs1/mem/602📈 view plot
⚠️ NO THRESHOLD
6,093.70 µs
Commit remove f(group size)/cs1/mem/802📈 view plot
⚠️ NO THRESHOLD
8,153.10 µs
Commit remove f(number clients)/cs1/mem/1002📈 view plot
⚠️ NO THRESHOLD
13,444.00 µs
Commit remove f(number clients)/cs1/mem/2📈 view plot
⚠️ NO THRESHOLD
135,440.00 µs
Commit remove f(number clients)/cs1/mem/202📈 view plot
⚠️ NO THRESHOLD
110,720.00 µs
Commit remove f(number clients)/cs1/mem/402📈 view plot
⚠️ NO THRESHOLD
87,055.00 µs
Commit remove f(number clients)/cs1/mem/602📈 view plot
⚠️ NO THRESHOLD
62,619.00 µs
Commit remove f(number clients)/cs1/mem/802📈 view plot
⚠️ NO THRESHOLD
37,891.00 µs
Commit update f(group size)/cs1/mem/1002📈 view plot
⚠️ NO THRESHOLD
135,000.00 µs
Commit update f(group size)/cs1/mem/2📈 view plot
⚠️ NO THRESHOLD
744.99 µs
Commit update f(group size)/cs1/mem/202📈 view plot
⚠️ NO THRESHOLD
27,973.00 µs
Commit update f(group size)/cs1/mem/402📈 view plot
⚠️ NO THRESHOLD
55,078.00 µs
Commit update f(group size)/cs1/mem/602📈 view plot
⚠️ NO THRESHOLD
82,980.00 µs
Commit update f(group size)/cs1/mem/802📈 view plot
⚠️ NO THRESHOLD
108,920.00 µs
🐰 View full continuous benchmarking report in Bencher

@fewerner fewerner force-pushed the felix/refactor/mls-session branch 5 times, most recently from a96ec22 to 805938d Compare January 7, 2026 07:44
@fewerner fewerner marked this pull request as ready for review January 7, 2026 08:01
@fewerner fewerner requested a review from a team January 7, 2026 08:01
@SimonThormeyer
Copy link
Member

Could you please mark the commits with breaking changes as such? Also, there is f96d144, looks like it is supposed to be autosquashed?

@typfel
Copy link
Member

typfel commented Jan 7, 2026

Regarding in c761fea:

I think there is a design flaw in the transaction context that we should
address later.
The transaction context never knows if it is a mls or proteus
transaction. There should probably be separate transaction contexts so
that a transaction context just uses its session instead of checking for
it's existence. It also doesn't need to know anything about the other
session.

This is also currently a feature since it allows clients to decrypt proteus and mls messages within a single transaction.

Copy link
Member

@typfel typfel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work!

Added some comments.

I think there's some clean up necessary on the commit messages. We are following the https://www.conventionalcommits.org/en/v1.0.0/ so you can't stack things like this:

test: ts: set transport on mlsInit()

it should instead be written as:

test(ts): set transport on mlsInit()

@fewerner
Copy link
Contributor Author

fewerner commented Jan 7, 2026

Could you please mark the commits with breaking changes as such? Also, there is f96d144, looks like it is supposed to be autosquashed?

Sure. The commit changes one of your commits, so I decided to it as a fixup, I will autosquash it before merge.

@fewerner fewerner force-pushed the felix/refactor/mls-session branch 2 times, most recently from 51810f1 to 7ad1cb3 Compare January 7, 2026 14:49
The idea here is to create an "empty" CoreCrypto client first that holds
no session and no pki environment. We create the mls Session on mls init
which allows us to get rid of the inner session and provide transport as
part of mls_init.
The keystore should live in CoreCrypto since it is shared between
proteus and mls. Proteus should not need to know anything about the mls
session.
This removes the anti pattern where the session had to be instantiated
in order to call `.init()`. Instead, we prepare the constructor
arguments beforehand. All we need is the keystore database which we have
here which will be the session's crypto_provider's keystore after
instantiation.
Getting the client id is no longer async and is a simple `clone()`.
We provide a dummy implementation to the transport argument here.
Since the history client is a very special case this should be ok.
The general use case of a session always needs transport, so we rather
not make it optional.
This should not be needed anymore as we use CoreCrypto::new() and then
provide the database on session initialization
We already have a client id and empty identities, so we just create the
session directly.
We change the order here to have a mls session before setting up the pki
to make the existing tests that call this still pass. Otherwise every
call to this method would result in an MlsNotInitialized Error.
proteus should not depend on the mls crypto provider's keystore which is
part of a mls session. Instead just use the CC's keystore.
proteus transactions should not rely on the the mls crypto provider to
access the keystore.

mls members are only available when the mls session exists, so lets
access them through the mls session.

I think there is a design flaw in the transaction context that we should
address later.
The transaction context never knows if it is a mls or proteus
transaction. There should probably be separate transaction contexts so
that a transaction context just uses its session instead of checking for
it's existence. It also doesn't need to know anything about the other
session.

However, for now we keep it like that.

Also setting transport on an already initialized session is no longer
possible. It only existed for tests which we will have to adjust.
A session always has transport
We no longer have an inner session. A session is always initialized and
can't be reset or replaced without droping the session and creating a
new one.
Identities used to be locked through the inner session. We still need
some kind of lock here to avoid larger refactoring or locking the whole
mls session.
fewerner and others added 27 commits January 8, 2026 15:24
We don't need to test behavior of uninitialized MLS sessions, because
e2ei can now only be initialized when mls is (this is to change in the
future, but not yet).
We can't reinit the inner anymore so the SessionContext has to reinit
the entire session.
Since the transaction context knows the database, we should get it
directly.
Note that this test won't actually work and we will have to ignore it
until the pki environment api has been refactored. However, we adjust it
to the refactoring already.
These tests initialize the pki without a session which is fine and must
be working.
However, with the current session refactoring does not support this so
we disable the tests for now.
The tests have to be enabled and working again with WPB-19578.
These logs should not have been merged previously.
This test assumes that the pki environment can be used before
initializing the mls session. This will be the case again with WPB-19578
which should revert this commit.
previously this used the session to access the keystore. Since we didn't
initialize it this doesn't work anymore. We can use the transaction
which knows the keystore.
This is a design flaw overall. We have to discuss the best practice
here. It would make sense to move getters to the CC instance which is
how it is in the FFI layer.
@fewerner fewerner force-pushed the felix/refactor/mls-session branch from 7ad1cb3 to d78584b Compare January 8, 2026 14:24
@fewerner fewerner merged commit d78584b into main Jan 8, 2026
1 check passed
@fewerner fewerner deleted the felix/refactor/mls-session branch January 8, 2026 14:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants