Rename package from FluffyChat to Twake Chat

[9clg6]

The project is a fork of FluffyChat that has been partially rebranded to "Twake Chat", but the package name and many internal identifiers still reference "FluffyChat". This should be fully updated for consistency.

What needs to happen
Rename the Dart package in pubspec.yaml from fluffychat to twake_chat (or equivalent) and update all import 'package:fluffychat/...' statements
Clean up remaining im.fluffychat.* and chat.fluffy.* internal identifiers

[coderabbitai]

🔗 Related PRs

#2802 - TW-2801: Align titles in group chat creation [merged]
#2829 - TW-2828: Update group chat creation screen [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[9clg6]

While this change could be dangerous, particularly for PRs currently in progress, we need to take steps to ensure that it is done properly:

• Merge PRs that are in progress/pending.
• Delete PRs that will not be merged because they are too old or have been forgotten. If they exist...
• Give a specific date for this refactoring, to give everyone time to merge their PRs. Once the date has passed, PRs must include the new package name in imports.

[9clg6]

1. Blatant brand inconsistency
   The rebranding to “Twake Chat” has already been largely implemented in the identifiers visible in production (Android/iOS/macOS bundle IDs in app.twake.*, URL scheme twake.chat://, push notifications, universal links, etc.), but the Dart package remains fluffychat. This creates an inconsistent hybrid identity where the outer layer says “Twake” and the core code says “FluffyChat.” This is confusing for any new developer joining the project.

2. Extent of technical debt: 5,331 imports in 1,014 files
   Each Dart file in the project contains ‘package:fluffychat/...’ imports. As time goes on, the number of files increases, and renaming becomes more costly. Postponing this task only makes the problem worse—it's better to do it now than in 6 months with even more files.

3. Confusion for contributors and the open-source community
   The project is public on GitHub under the name twake-on-matrix. An external contributor who clones the repo and sees name: fluffychat in pubspec.yaml may legitimately wonder if they are in the right project. This undermines the credibility of the fork and the clarity of its own identity vis-à-vis FluffyChat upstream.

4. Risk of user data loss if done too late
   19 user preference keys (chat.fluffy.* in setting_keys.dart) and 2 critical storage keys (im.fluffychat.store.clients, im.fluffychat.account_bundles) are persisted on the user side. The larger the user base grows, the more risky and complex the migration will be. It is better to perform this migration now, while the user base is still manageable.

5. Professionalism and product image
   A product marketed under the “Twake” brand whose logs, crash reports, process names, and system metadata display “fluffychat” gives an image of incompleteness. For enterprise customers (the target audience of Twake/Linagora), this may raise questions about the maturity of the product.

@tprudentova @hoangdat @pm-McFly @Crash--

[pm-McFly]

The point is valid indeed.
The road to fixing can be split between the DB names and the imports (other projects like LibreOffice still relies on config keys named after SunOffice, yeah the one superseded by OpenOffice...)

Anyway, renaming it all would induce a hard break of imports in stall branches (local and remotes)
That is IMO the biggest black spot to accomplish this.
As a developer I could be frustrated if I take weeks to fix a compex bug and be tricked by an import issue at delivery 🫠

I though believe we can act intelligently to make it as smooth as possible.
Maybe by setting a change date?

Though, the rest of the impact is minor, and the all name mixup trouble sound legitimate to me
Especially if fluffy or us start releasing deps to fetch remotely.

[9clg6]

As a developer I could be frustrated if I take weeks to fix a compex bug and be tricked by an import issue at delivery 🫠

It's the reason why I suggest to set a precise date for this refactoring, allowing everybody to merge his pending PR, to avoid future-changes on PR.

We need the opinion of the rest of the team about that.

If we want Twake Chat to improve, we need to be able to iterate quickly and efficiently on our deliverables and not just focus on ticket execution. This is because the product team is not aware of the code aspect.

Twake Chat is an open-source project, which means we must be willing to take the lead and implement new features that exceed the product team's expectations. We, the tech team, must have high standards for our scope. And that means accepting major projects at the risk of regression. This risk is covered by our tests and the use of a test and staging environment.

[tprudentova]

The point is totally valid, but, from what I understand (correct me if I'm wrong, I know very little about the code), we need to conduct this refactoring when we have 0 pending PRs, right? So we kinda stall the development for a bit -> do the refactoring -> after that start using 'twakechat' instead of 'fluffychat' eveywhere starting from that moment
How long do you think this refactoring will take? Like, can we automize it, or is it to be done manually in every specific case?

[9clg6]

we need to conduct this refactoring when we have 0 pending PRs, right?

Not necessarily. First, you would need to clean up pending PRs, delete those that will never be merged, merge those that should be merged, and then this refactoring can be done during a code freeze period. Or you could skip waiting for 0 PRs and ask everyone to make the changes. Conflicts should be fairly easy to fix. @pm-McFly

How long do you think this refactoring will take? Like, can we automize it, or is it to be done manually in every specific case?
Manually but it's very easy and fast with a script.

[tprudentova]

If the code freeze period will be like 1 day, then it's not a problem I think, but we need to understand how much preparation we need for it with the PRs.