Identité : utilisateurs anonymes et connectés

L'identité est portée par AppwinCore, pas par les produits. Un appareil, une session, un utilisateur : les modules Community, Support et Notifications lisent tous la même. C'est ce qui fait qu'une personne identifiée dans ton app est le même interlocuteur partout, sans que tu aies rien à recopier d'un produit à l'autre.

Trois états, dans cet ordre. Chacun est utilisable seul : tu peux t'arrêter au premier et avoir une intégration qui fonctionne.

1. Anonyme - rien à faire

Dès configure, le SDK reconnaît l'appareil : il génère un identifiant, le persiste, et ouvre une session authentifiée en tâche de fond. L'end-user peut lire et écrire sans inscription.

AppwinCore.configure(projectAppId: "ton-app-id")
print(AppwinCore.deviceId ?? "-")   // stable d'un lancement à l'autre

Ce que voit cet end-user dépend du produit. Côté Community, son profil naît avec un pseudo généré stable (« Curious Otter 417 »), dérivé de son identifiant : s'il réinstalle l'app, il retrouve le même pseudo plutôt que de repartir avec une nouvelle identité aux yeux des autres. Côté Support, il ouvre une conversation comme visiteur.

2. Connecté - rattacher à ton utilisateur

Quand ton app sait qui est la personne, pousse ton identifiant, celui de ta base. Appwin ne l'interprète pas : il sert à reconnaître la même personne d'un appareil à l'autre et d'un produit à l'autre.

try await AppwinCore.identify(
  externalId: user.id,
  attributes: AppwinUserAttributes(email: user.email, name: user.name)
)

À appeler une fois, à la connexion. Le SDK garde l'externalId sur l'appareil et le réutilise à chaque lancement : rien à rappeler au démarrage suivant. attributes est optionnel ; tu peux aussi les pousser plus tard avec updateUser.

identify est la seule porte d'entrée : Support, Community et Notifications n'ont plus de fonction de login à eux. Core les prévient, et ils reprennent la nouvelle personne d'eux-mêmes.

C'est là que se joue le partage : après ce rattachement, cette personne est la même pour Support et pour Community. Ses conversations et son profil appartiennent au même individu, et ton équipe le voit comme un seul interlocuteur. L'historique anonyme de l'appareil (une conversation ouverte avant la connexion, par exemple) est fusionné dans cette personne.

Déconnexion

await AppwinCore.logout()

logout révoque la session côté serveur, oublie l'externalId gardé et repasse en profil anonyme ; le token push de l'appareil est réenregistré sur cette nouvelle session. À appeler quand l'utilisateur se déconnecte de ton app - sinon la personne suivante sur le même appareil hériterait de son identité.

3. Enrichi - pousser les attributs

Ton app connaît souvent déjà un nom, une photo, un email, un abonnement. Les pousser épargne une saisie et permet de cibler. Il y a deux passerelles, parce que les attributs ne sont pas les mêmes : un profil communautaire n'est pas une fiche client.

try await AppwinCore.updateUser(AppwinUserAttributes(plan: "pro", language: "fr"))

try await AppwinCommunity.setUser(
  nickname: user.displayName,
  avatarUrl: user.photoURL?.absoluteString
)

Deux règles :

• Tous les champs sont optionnels. Un champ omis n'est pas écrasé : une app qui ne connaît que l'abonnement n'efface pas l'email, une app qui ne connaît qu'un pseudo n'efface pas la bio saisie dans le SDK.
• Fournir un nickname sort le profil communautaire de l'anonymat. C'est l'acte qui donne une identité visible. Le membre peut y revenir explicitement depuis son profil.

Ces méthodes ne changent pas l'identité : elles enrichissent le profil. Pour rattacher à ton utilisateur, c'est l'étape 2.

Quand appeler quoi

Démarrage de l'app        → AppwinCore.configure(...)          toujours
Connexion dans TON app    → AppwinCore.identify(...)           une fois, gardé
Un attribut change        → AppwinCore.updateUser(...)         plan, langue...
Profil communautaire      → AppwinCommunity.setUser(...)       pseudo, bio
Déconnexion dans TON app  → AppwinCore.logout()                retour anonyme

Des attributs poussés avant identify ne sont pas perdus : ils partent sur le profil anonyme, fusionné dans la personne à la connexion. Les passer directement à identify économise un appel.

Ce qui est partagé, et ce qui ne l'est pas

Modération

Trois sanctions existent côté Community, décidées depuis le dashboard : avertissement, ban en lecture seule, et shadow ban - le membre continue de publier et voit ses propres contenus, personne d'autre ne les voit, et il n'en est jamais informé, ni par l'UI ni par une réponse d'API. Le SDK est conçu pour ne rien en laisser filtrer. Le détail est dans Piloter Community.

Vie privée

Ce que le SDK envoie, et rien de plus :

• un identifiant d'appareil généré par le SDK - pas l'IDFA, pas l'IDFV, pas l'ID de publicité Android
• la plateforme, le modèle, la version d'OS et d'app
• la langue de l'appareil, pour la traduction des contenus
• l'externalId que tu fournis, si tu en fournis un

Le SDK ne lit ni le carnet d'adresses, ni la localisation, ni les identifiants publicitaires. L'externalId étant choisi par toi, tu peux y mettre un identifiant opaque plutôt qu'un email si tu préfères.

Suite

• Installation - dépendances, initialisation, API locale
• Community - afficher le fil et le personnaliser