CommunityGlows: What Stays on Your Device and What Syncs

Lire cet article en français

When an app works across several devices, the word “sync” can make it sound as though everything is sent to the cloud. That is not how CommunityGlows works.

We separate two needs that may look similar but have very different implications: recovering your workspace organization and transferring an active social network sign-in. CommunityGlows syncs selected data that helps organize your work. Social network sessions remain tied to the device where they were created.

That boundary is intentional. It lets you recover profiles and workspaces without pretending that an Instagram, LinkedIn, or Gmail session can be moved silently from a computer to a phone.

The short answer

When you are signed in to CommunityGlows with lifetime access, sync can cover:

• your CommunityGlows profiles;
• a selected set of app preferences;
• custom links and the networks associated with profiles;
• selected organizational data for social accounts and filters;
• contacts and the Kanban board.

The following stay local to each device:

• active social network sessions;
• cookies and other web data that maintain those sessions;
• the current cockpit draft for each profile;
• local copies of contextual tasks, pending successful cloud synchronization;
• engine- or system-specific data outside the sync contract.

During the trial, cloud synchronization is not active: contacts and the Kanban board stay on this device.

In practice, you can recover the structure of your workspace on another device while still needing to sign in to the networks on that device.

A CommunityGlows profile is not a social network account

A CommunityGlows profile organizes a context—for example, “Personal,” “Studio,” or a client name. It can include a name, appearance, network selection, and custom links.

That profile can sync. It does not therefore contain your LinkedIn password or a universal copy of your Instagram login.

The distinction matters:

Synced CommunityGlows profile
        ≠
Transferred social network session

When you open the same profile on a new device, CommunityGlows can rebuild its organization. The local web engine still has to establish its own sessions with each platform.

Why do sessions stay local?

A modern web login is more than a username and password. It may depend on cookies, localStorage, IndexedDB, caches, service workers, the web engine in use, and protections chosen by the platform itself.

Those mechanisms also differ between WebView2 on Windows, Android System WebView, and a regular browser. Copying part of that state therefore guarantees neither a complete restoration nor acceptance of the session by the service concerned.

CommunityGlows keeps sessions in the local spaces assigned to its profiles and networks, and isolates them per profile and network. On Windows, each pair gets its own WebView2 data folder. On Android, each pair gets its own native Android WebView profile where the device supports it; on some devices, a fallback covers less storage. The browser extension has no session storage of its own: its sites use your browser’s cookies and storage. Two copies of the same network inside the same profile share that profile’s session, by design, and isolation is not an operating-system sandbox.

To see how that boundary works day to day with several accounts, read the guide to running several accounts from one device. Passwords follow the same principle: your chosen password manager keeps the vault.

What sync actually helps you recover

Sync is designed to reduce reconstruction work, not clone a device. It is part of lifetime access, not of the 30-day trial, and may be unavailable in some builds.

Profiles

Profiles give CommunityGlows a shared structure. Recovering them means you do not have to recreate every context and network selection by hand.

Supported preferences

Settings such as language, theme, selected display options, shortcuts, or the active profile are among the preferences the app can transmit. The exact set can evolve with the product: “synced settings” does not mean every internal value or system preference leaves the device.

Links and social organization

Custom links attached to profiles, along with selected data used to organize accounts and filters, are part of the synced model. This helps recover a coherent workspace without syncing the private contents of open pages.

Bento cockpit Scenes

Scenes are in preparation: this section describes their planned behavior, not a feature that is available yet.

A Scene stores a named layout: which panels make up the cockpit and how they are arranged. Scenes are saved locally first, then placed in the workspace sync queue. They can therefore follow their profile to compatible connected devices.

A Scene restores an organization, not a signed-in state. If it contains three networks side by side, a new device can rebuild those three positions, but each network may require a local sign-in.

The current draft is different. It represents the profile’s unsaved working state on that device and stays local.

What about tasks?

The contextual task manager can store an intention, note, people, links, tags, priority, or due date. The implemented board uses versioned local storage and sends its snapshot through workspace cloud synchronization when a CommunityGlows account with lifetime access is connected.

A local save does not prove that another device has received it. Confirm synchronization and use a compatible app version before relying on tasks elsewhere. This transfers task data, not the social sessions attached to their links. For using Tasks to follow up prospects, see that guide.

Sync can keep working through an unreliable connection

CommunityGlows records useful changes locally first and uses a queue for cloud operations. This helps the interface remain usable when a connection is temporarily unavailable.

It does not turn offline use into a guarantee of immediate replication. Until an operation reaches the sync service, a second device cannot receive it. Size limits and validation also protect workspace data from excessive or malformed states.

A backup is not sync

CommunityGlows also offers an encrypted local backup, created deliberately by the user and available in the Windows app and in the Android app (see the Android guide for the steps), not in the browser extension. It can include app data and, depending on the platform, snapshots of compatible local sessions.

That backup serves a different purpose: explicitly moving or restoring a state. It is not continuous cloud replication. Even after a restore, you may need to sign in again because some storage and security controls belong to the web engine, operating system, or social network.

Encrypting an export protects its contents according to the app’s backup mechanism; it does not make every third-party session portable or replace the social account’s own protections. Where backups fit in a broader security routine for client accounts is covered in how to keep client social accounts secure.

What “in the cloud” does not mean

The CommunityGlows cloud is not a copy of everything displayed inside its WebViews. Sync does not mean the app reads the messages, posts, forms, or passwords shown by social networks.

Those sites remain third-party services with their own rules, storage, and sign-in lifecycles. CommunityGlows organizes access to them in a workspace; it does not replace their servers or bypass their controls.

This separation also leads to a few simple expectations:

• deleting a Scene does not close a social account;
• syncing a profile does not automatically sign in a new device;
• signing out of CommunityGlows and signing out of a network are different actions;
• restoring a backup may require some sessions to be confirmed again.

One rule to remember

Your organization can follow you; your sign-ins stay where they were created.

This rule does not erase every difference between Windows, Android, and browser extensions. It does set an honest expectation: CommunityGlows syncs the data that helps rebuild your workspace, while sensitive sessions and web-engine-specific state remain local unless you explicitly move a compatible backup.

That architecture requires more nuance than a single “sync everything” switch. Most importantly, it avoids confusing organizational convenience with portable sign-ins—two very different promises.