How credentials are sealed

What we hold

To post for you, NioConnect keeps the access a platform gave it when you connected a channel. For most platforms that is an access token issued after you approved a consent screen on the platform itself. For three it is something you created and pasted in. Whatever its shape, it is the most sensitive thing in the system, so it is treated differently from everything else.

We are not going to claim we never hold a token. Publishing at the time you chose, while you are not in front of the screen, requires it. The honest claim is about how it is held.

What you hand over, platform by platform

The sign in platforms, such as X, Mastodon, Facebook, LinkedIn and the rest, send you to the platform's own consent screen. You never type a password into NioConnect for them. Three platforms work differently because they have no such screen for an app like this.

Sealed under a key of its own

Each credential is encrypted with AES-256-GCM, using an envelope scheme. The data key belongs to your workspace and is itself held in a key management service, never in plain text and never in a setting. Two workspaces are never protected by the same key.

That matters in the failure case that worries everyone: one place leaking. A leak of one workspace's stored data would not open another's, and a database copy on its own is not enough to read a credential without the key service.

Never returned, never logged

A stored credential is not sent back to the browser, by any screen or any API call. Fields that take a secret are masked while you type, and after you save, the value is not shown again to you, your teammates or anyone supporting you. If you lose a token, you generate a new one on the platform and reconnect.

Credentials are also kept out of logs. An automated scrubber redacts anything shaped like a token from logs and error reports, as a second line behind the habit of not logging them in the first place. If decrypting fails, the failure surfaces as a problem on our side and never as a leak.

Adapters use a credential at the moment of publishing, on the line that builds the request, and nowhere else. They cannot read the database or the media store directly, so a flaw in one platform's code has no route to another platform's secrets.

Your sign in is a different thing

The password and session you use to open NioConnect belong to a separate system from channel credentials, and the two are never mixed. Session cookies are not readable by scripts, and passwords are stored with a modern one way hash. A person who gets into your app session has not been handed your channel tokens, because those are never shown to anyone.

API keys follow the same idea. A key is shown once, only its hash is stored, and you can revoke it alone. That is the opposite of how a channel token is used, since a key comes into NioConnect and a token goes out to a platform.

The Nostr caveat, plainly

A Nostr private key is not a scoped credential. Whoever holds it is that identity: they can post, delete and change the profile, and there is no server where it can be revoked. We seal it with the same vault treatment as everything else, and that is the strongest handling we can offer, but it does not change what the key is.

The comfortable option is a dedicated key made for publishing, so that the identity you use for everything else is not the one you hand over. The Nostr guide goes through it, and the Telegram guide covers the bot token.

What our own people can and cannot see

Not being able to reveal a credential applies to us too. There is no screen where a stored token is displayed to a teammate, an administrator or a member of our staff, and no export that includes one. The operator console that deployment staff use answers how many, never which: it counts channels and their health without being able to point at one workspace's accounts.

Your data is scoped to your workspace on every read. Every query carries the workspace it belongs to, so a request made for one workspace cannot return another's rows even by mistake.

When access breaks or changes

If a platform revokes or expires access, the channel moves to needing reconnection, the workspace is told once, and posts to it wait instead of failing silently. Reconnecting is the same flow as connecting. Some platforms use single use refresh tokens; for those, refreshing is serialized so two processes can never race and break the connection.

The security page lists these protections in one place, with the path to ask for your data to be deleted.