feat: configurable group v2 params with logos chat

[kaichaosun]

Why changes:

When testing with ferry, a create group process takes quite long, make other member not able to join the conversation fast enough.

Changes:

Add optional group_v2_config setting method on LogosConfig, so apps using it can customize as needed.

[jazzz]

Add optional group_v2_config setting method on LogosConfig, so apps using it can customize as needed.

I have no technical blocker with this change its clear and concise, but I want to understand more. Specifically:

• what does this allow apps to do and how does that fix things?
• Can it be fixed inside libchat:core so no one has to face this issue?

There is an open [Pebble] from this review - Tracked in #172 to remove any awareness of group_v2_config outside of groupV2.

That would mean that this function would need to be removed

[osmaczko]

Will clients with different groupv2 configs be interoperable?

[kaichaosun]

Will clients with different groupv2 configs be interoperable?

I think so, The steward syncs its timing to joiners, when joining someone else's group, the group's timing wins.

what does this allow apps to do and how does that fix things?

This allow apps using rust to create a test group with relative fast user experience, the conservative de-mls defaults makes a new member can wait up to a minute to be welcomed.

Can it be fixed inside libchat:core so no one has to face this issue?

It depends on group types, for example,

• for internal testing group, it can be configured pretty fast
• for small groups and not frequent to change, it can be aggressive
• for large public groups, maybe the conservative configure is more secure. (60s is still too slow even in this use case)

For #172, I believe this change is still useful, new change can just use another config to replace the old ones, since the config is always necessary in regarding to above use cases.

[jazzz]

This allow apps using rust to create a test group with relative fast user experience, the conservative de-mls defaults makes a new member can wait up to a minute to be welcomed.

The DeMLS team (cc: @seemenkina ) is working on optimizations for group startup and will be further optimizing this pathway going forward. So My hope is that this is a temporary issue - though you are right it is painful for developers now.

As background my concern with this approach is one of interop / and scalability. @kaichaosun is correct that the individual parameters are bound to each group, and don't pose a direct interop issue. However the interop issue stems from developers choosing correct appropriate values.

1. Values are not independent and particular relationships between values are required to avoid deadlocks.
2. Values chosen by one application may not work for other applications. It would be nearly impossible for an App Developer to choose these.

On scalability.

3. We are working on GroupV3. Will we also export these parameters? DirectV1
4. <General concerns about keeping a simple and easy interface for developers>

That said this is a real issue and needs to be addressed in the short & long term.

Proposed Path forward

Option 1:

• Expose the functionality as is, but add an immediate deprecation notice to tell developers that this is not a valid pathway for future use. Solves the problem now, but limits future issues.

Option 2:

• Use the WallclockService that @seemenkina was kind enough to add. It's an abstraction which provides custom control of DeMLS's wait timers. A TestTimer could exist that runs X times faster. This directly addresses (1,2,3).

Regardless:
It sounds like you are saying that a LocalTestChatClient would be helpful for developers that uses a generic_client configured with a test transport, fast wallclock service etc. Which directly addresses (4)

Which makes the most sense to you @kaichaosun ?

[kaichaosun]

Let's go with option 1 for now, and continue explorer other options.